redis 的订阅发布机制允许客户端通过 publish、subscribe 等命令实现实时消息传递，适用于解耦组件和事件驱动架构。1. 发布消息使用 publish 命令向指定频道发送消息；2. 订阅频道使用 subscribe 命令监听一个或多个频道；3. 取消订阅使用 unsubscribe 命令停止接收特定频道消息；4. 模式匹配订阅使用 psubscribe 命令按模式订阅多个频道。构建简单聊天室可让用户连接 redis 后订阅频道并发布消息，但存在消息丢失、无持久化等局限。相比 redis streams，pub/sub 更适合实时性高但可靠性要求低的场景，而 streams 支持持久化和消费者组，适用于需可靠传递的场景。
redis 的订阅发布（Pub/Sub）机制允许你构建消息队列和事件驱动的应用程序。它提供了一种发布者（publisher）向多个订阅者（subscriber）发送消息的方式，而无需知道具体的订阅者是谁。这对于解耦应用程序组件非常有用。
Redis 订阅发布模式的完整实现教程
实现 Redis 的订阅发布，大致可以分为以下几个步骤：发布消息、订阅频道、取消订阅、模式匹配订阅。
发布消息
发布消息很简单，使用 PUBLISH 命令即可。
PUBLISH channel "Hello, Redis Pub/Sub!"
这会将消息 “Hello, Redis Pub/Sub!” 发布到名为 “channel” 的频道。任何订阅了该频道的客户端都会收到这条消息。要注意的是，Redis 不会存储发布的消息，如果客户端在消息发布时没有订阅，那么消息就会丢失。
订阅频道
客户端使用 SUBSCRIBE 命令订阅一个或多个频道。
SUBSCRIBE channel1 channel2
订阅之后，客户端会进入订阅状态，只能接收订阅相关的命令（如 SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE、PUNSUBSCRIBE）和接收发布到已订阅频道的消息。 如果尝试执行其他命令，Redis 会返回错误。
收到消息后，客户端会收到一个包含三个元素的数组：消息类型（”message”），频道名称，以及消息内容。
取消订阅
使用 UNSUBSCRIBE 命令可以取消订阅。
UNSUBSCRIBE channel1
如果不指定频道，则取消订阅所有已订阅的频道。
模式匹配订阅
除了订阅特定频道，还可以使用模式匹配订阅，使用 PSUBSCRIBE 命令。
PSUBSCRIBE news.*
这会订阅所有以 “news.” 开头的频道，例如 “news.sports”、”news.politics” 等。 取消模式匹配订阅使用 PUNSUBSCRIBE 命令。
PUNSUBSCRIBE news.*
与 UNSUBSCRIBE 类似，如果不指定模式，则取消订阅所有已订阅的模式。
如何使用 Redis Pub/Sub 构建一个简单的聊天室？
构建一个简单的聊天室，可以分为以下几个步骤：
- 客户端连接 Redis： 每个用户连接到 Redis 服务器。
- 用户订阅聊天频道： 用户使用 SUBSCRIBE 命令订阅一个特定的聊天频道（例如 “chat:room1″）。
- 用户发送消息： 用户输入消息后，客户端使用 PUBLISH 命令将消息发布到聊天频道。
- 所有订阅者接收消息： 所有订阅了该聊天频道的用户都会收到消息，并在客户端显示。
这个方案很简单，但存在一些问题，例如没有消息持久化，如果用户离线，则无法收到消息。 此外，也没有用户身份验证和权限管理。 可以考虑使用 Redis Streams 来解决消息持久化问题，并使用其他机制来实现用户身份验证和权限管理。
Redis Pub/Sub 的局限性是什么？
Redis Pub/Sub 虽然简单易用，但也存在一些局限性：
- 消息丢失： 如前所述，Redis 不会存储发布的消息，如果客户端离线或未订阅，消息就会丢失。
- 不可靠性： Redis Pub/Sub 是一种“fire and forget”的机制，不保证消息传递的可靠性。如果 Redis 服务器崩溃，消息可能会丢失。
- 缺乏消息确认： 发布者无法知道消息是否成功发送给所有订阅者。
- 不支持消息持久化： 消息不会被持久化到磁盘，因此无法在服务器重启后恢复。
对于需要可靠消息传递的场景，建议使用 Redis Streams 或其他消息队列系统，例如 rabbitmq 或 kafka。 Redis Streams 提供了消息持久化、消费者组和消息确认等功能，可以更好地满足可靠消息传递的需求。
Redis Pub/Sub 与 Redis Streams 有什么区别？
Redis Pub/Sub 和 Redis Streams 都是 Redis 提供的消息传递机制，但它们的设计目标和适用场景有所不同。
- Redis Pub/Sub： 是一种简单的发布订阅模式，适用于实时性要求高，但可靠性要求不高的场景，例如实时聊天、实时通知等。
- Redis Streams： 是一种更复杂的消息队列，提供了消息持久化、消费者组和消息确认等功能，适用于需要可靠消息传递的场景，例如订单处理、日志收集等。
可以简单地理解为，Pub/Sub 更像是一个广播系统，而 Streams 更像是一个消息队列。 选择哪种机制取决于具体的应用场景和需求。 如果只需要简单的实时消息传递，Pub/Sub 可能更合适。 如果需要可靠的消息传递和消息持久化，Streams 则是更好的选择。 也可以将两者结合使用，例如使用 Pub/Sub 进行实时通知，使用 Streams 进行消息持久化和处理。
实际上，在某些场景下，选择消息队列（如 Kafka、RabbitMQ）可能比 Redis Streams 更合适，因为它们在消息可靠性、吞吐量和可扩展性方面通常更具优势。 选择哪种技术取决于具体的业务需求和技术栈。
