Redis Pub/Sub 与 Redis Streams：选择正确的解决方案

在为我们的产品 LiveAPI（超级便捷的 API 文档生成工具）构建 Go 二进制工具（“Runner”）时，我们需要在 LiveAPI 的后端和 Runner 之间建立通信。我们最初尝试了 Redis 发布/订阅机制，但后来意识到它不足以满足我们的用例。

**Redis Pub/Sub 的问题**

Redis Pub/Sub 遵循传统的发布-订阅模型：发布者向频道发送消息，订阅者从其订阅的频道接收消息。

这给 LiveAPI 带来了几个问题：

：如果用户在多台设备上运行同一个Runner，那么pub/sub的订阅行为会导致同样的操作在多台设备上运行，造成重复，浪费资源。

：发布/订阅不会保留或持久保存消息，因此如果服务器崩溃或由于恐慌导致作业失败，则无法重新启动操作。

：LiveAPI 后端没有迹象表明来自消费者的工作请求已经到达订阅者。

**Redis Streams 作为解决方案**

Redis Streams 提供更强大、功能更丰富的消息传递系统。它们本质上是仅附加日志，生产者添加消息，消费者读取消息。

Redis Streams 解决了我们在 Pub/Sub 中遇到的问题：

：即使同一个 Runner 在多台设备上运行，也只有一个实例可以读取并确认消息，从而避免了发布/订阅时发生的重复操作。

：Redis Streams 会持久保存消息。如果服务器崩溃，可以使用相同的消息重新启动操作。

：Redis Streams 提供消息确认，向 LiveAPI 后端保证作业请求到达预期的订阅者。

**了解你的用例**

Redis Streams 因其消息持久性、保证传递、消息确认以及防止重复操作的能力而被选为 LiveAPI 的解决方案。

虽然 Pub/Sub 是一种更简单的解决方案，更适合实时消息传递，但 Streams 提供了更多的功能和保证，使其成为数据持久性和可靠性至关重要的用例的理想选择。