redis--发布订阅
redis的发布和订阅
在Redis中，发布-订阅（Publish-Subscribe，简称Pub/Sub）是一种消息传递模式，用于在不同的客户端之间传递消息，允许一个消息发布者将消息发送给多个订阅者。这种模式适用于解耦消息发送者和接收者之间的关系，使得消息的发送者不需要关心消息是由哪些订阅者接收。
介绍
发布者（Publisher）：发布者负责将消息发送到指定的频道。频道可以看作是消息的主题，订阅者可以选择订阅感兴趣的频道来接收相应的消息。
订阅者（Subscriber）：订阅者通过订阅一个或多个频道来接收发布者发送的消息。一旦订阅了某个频道，订阅者就会收到该频道上的所有消息。
频道（Channel）：频道是消息的通道，发布者将消息发送到特定的频道，而订阅者可以选择订阅感兴趣的频道。
消息（Message）：消息是发布者发送给订阅者的数据。一条消息可以是任意类型的数据，例如文本、JSON等。
常见命令
| 命令 | 描述 | 示例 |
|---|---|---|
| PUBLISH | 将消息发布到指定的频道 | PUBLISH news_channel “新闻：Redis 发布订阅” |
| SUBSCRIBE | 订阅一个或多个频道，以接收发布者发送的消息 | SUBSCRIBE news_channel |
| UNSUBSCRIBE | 取消订阅一个或多个频道，停止接收消息 | UNSUBSCRIBE news_channel |
| PSUBSCRIBE | 使用模式匹配订阅一个或多个频道，接收匹配的消息 | PSUBSCRIBE news_* |
| PUNSUBSCRIBE | 取消模式订阅，停止接收通过模式匹配的消息 | PUNSUBSCRIBE news_* |
发布订阅流程
假设我们有一个简单的消息系统，其中有一个发布者（Publisher）和两个订阅者（Subscriber_A和Subscriber_B）。发布者将消息发布到一个名为“news_channel”的频道，两个订阅者分别订阅了这个频道，以接收发布的新闻消息。
- 发布者发布消息
发布者将一条新闻消息发布到名为“news_channel”的频道。使用PUBLISH命令可以完成这个操作：
PUBLISH news_channel "新闻：该吃瓜了！" - 订阅者A订阅频道
订阅者A通过使用SUBSCRIBE命令来订阅“news_channel”频道，以便接收来自发布者的消息：
SUBSCRIBE news_channel - 订阅者B订阅频道
同样地，订阅者B也通过SUBSCRIBE命令来订阅“news_channel”频道：
SUBSCRIBE news_channel - 发布者发布更多消息
发布者可以继续发布更多的消息到“news_channel”频道：
PUBLISH news_channel "震惊：cxk塌房啦！" - 订阅者接收消息
订阅者A和订阅者B都将在接收到消息后显示消息内容。他们都能看到发布者发布的消息。 - 取消订阅
如果订阅者不再想接收消息，可以通过使用UNSUBSCRIBE命令取消订阅：
UNSUBSCRIBE news_channel
发布订阅的优缺点
优点：
| 优点 | 描述 |
|---|---|
| 简单的实时通信 | 适用于需要实时传递消息的场景，如实时监控、聊天应用等 |
| 解耦发布者和订阅者 | 发布者和订阅者之间的解耦降低了系统复杂性 |
| 广播消息 | 一条消息可以同时传递给所有订阅了相应频道的订阅者 |
| 简单的模式订阅 | 支持通过通配符订阅多个频道，方便实现特定模式下的消息订阅 |
| 低延迟 | Redis的内存数据库特性使得发布-订阅模式具有低延迟 |
缺点：
| 缺点 | 描述 |
|---|---|
| 消息的可靠性和持久性 | 不保证消息的可靠传递和持久性存储，需要额外的机制 |
| 顺序性问题 | 无法保证消息的传递顺序，订阅者接收消息的顺序可能不一致 |
| 消息堆积和延迟 | 订阅者处理消息速度不足时，可能导致消息堆积和延迟 |
| 扩展性问题 | 随着订阅者数量增加，Redis服务器负载可能增加，需要考虑扩展性 |
| 单一服务器限制 | 仅在单个Redis服务器内工作，不适用于分布式消息队列 |
| 无法重播历史消息 | 订阅者只能接收自订阅后发布的消息，无法获取历史消息 |