本文主要是用通俗易懂的话解释Redis Pub/Sub。
我发现公司的老项目 把这个订阅发布机制当成MQ来用了，这样想来也真是降本增效啊。习惯了使用火箭MQ的我，又得从头研究下订阅发布消息通讯。
我们暂且按照MQ的生产者 和消费者对应Redis中的 发布 和订阅。我记得之前面试过程中也有问过让你自己实现一个MQ 怎么实现。这种面试题考查的就是你对底层原理是否清晰。
Redis 是一个“中转站”：
订阅者把自己挂在频道上，Redis 帮你记住谁订阅了什么；
发布者只需要往频道发消息，Redis 就把这条消息“群发”给所有挂在这个频道上的订阅者。
Redis 用了什么数据结构实现？
Redis 的底层是用 字典（哈希表）+ 列表 实现的：
- 一个大字典
channel -> list of clients - 每个键是一个频道名，值是订阅该频道的客户端列表
- 每当有客户端订阅、取消订阅，Redis 就增删这个列表
- 发布消息时，Redis 遍历这个列表，直接写到客户端连接中
举个例子🌰zz：
你可以把 Redis Pub/Sub 类比成一个微信群（频道）：
- 加群 = 订阅频道（
SUBSCRIBE） - 群发消息 = 发布（
PUBLISH） - 在线就能看到消息，退群/没加群就收不到
- 群消息不保存历史记录，只能看直播
Redis “广播站”，它的工作大致流程如下：
订阅时：登记在广播站
- 每个频道（channel）就像一个广播频率，比如“新闻频道”。
- 当你用
SUBSCRIBE news命令订阅时，Redis 把你这个客户端登记在 news 频道的订阅列表里。 - Redis 在内存里维护了一个结构，类似这样：
{"news": [客户端1, 客户端2],"sports": [客户端3]
}
发布时：广播给订阅者
- 当另一个客户端用
PUBLISH news "今天有大新闻"发送消息时：- Redis 会查一下：“谁订阅了 news 频道？”
- 然后把
"今天有大新闻"这条消息推送给所有订阅了这个频道的客户端（像群发短信一样）。
推送过程：不存消息，谁在线谁能收
- Redis 是“推送+广播”机制，不是“存储+拉取”。
- 如果你在发布那一刻不在线，或者没订阅这个频道，你就永远收不到那条消息了。