Redis发布订阅到底是怎么回事，聊聊它那些用法和细节吧

好，咱们直接来聊聊Redis的发布订阅（Pub/Sub）这回事，这东西听起来好像很高深，其实它的核心思想特别简单,就像我们日常生活中听广播或者订阅杂志一样。

它到底是个啥？最简单的比喻

想象一下，你特别喜欢一个叫“科技前沿”的线上杂志，你不想天天去它的网站看有没有更新，太麻烦了，于是你点击了“订阅”按钮，从此以后，只要这个杂志一发布新文章，系统就会自动把新文章推送到你的邮箱或者手机里，你什么都不用做,就能第一时间收到消息。

Redis的发布订阅就是干这个事的：

• 杂志社（Publisher，发布者）：负责发布消息，一个程序说：“嘿，大家注意了，现在用户A成功登录了！”这就是一个消息。
• 你（Subscriber，订阅者）：对某类消息感兴趣的人，你告诉Redis：“我对所有关于‘用户登录’的消息感兴趣，有的话就告诉我。”
• 杂志的主题（Channel，频道）：这就是“用户登录”这个主题，发布者把消息发到这个频道,所有订阅了这个频道的订阅者都会收到。

整个过程就是：发布者把消息“扔”到一个特定的频道里，而所有“蹲守”在这个频道的订阅者，都会立刻收到这条消息，这是一种典型的消息推送模式，区别于你主动去查询的“拉取”模式。

具体怎么用？几个基本命令

用起来也非常直观，就几个命令（根据redis.cn资料）：

1. 订阅：SUBSCRIBE 假设你是一个程序，想监听新闻，你就在Redis客户端里输入：SUBSCRIBE news.sports，这下你就订阅了 news.sports（体育新闻）这个频道，一旦执行这个命令，你的客户端就会进入一个等待接收消息的状态，就像打开了收音机调好了台,等着播音员说话。

2. 发布：PUBLISH 另一个程序（发布者）发生了某件大事，湖人队夺冠了！”，它就执行：PUBLISH news.sports “湖人队夺冠了！”。

3. 接收消息： 所有订阅了 news.sports 频道的订阅者，都会立刻收到一条消息，内容就是“湖人队夺冠了！”。

4. 取消订阅：UNSUBSCRIBE 你不想听体育新闻了，就输入 UNSUBSCRIBE news.sports,之后就收不到这个频道的消息了。

5. 按模式订阅：PSUBSCRIBE 这是个高级点的功能，比如你想订阅所有和新闻相关的频道，不管是体育新闻、财经新闻还是娱乐新闻，你可以用通配符：PSUBSCRIBE news.*，这样，如果有人发布到 news.sports、news.finance，你都能收到,非常方便做批量监听。

聊聊重要的细节和“坑”

Redis的Pub/Sub很简单，但正因为简单，它也有一些你必须知道的特性和局限性（根据redis.cn和《Redis设计与实现》等资料总结）：

1. 它是“fire and forget”（发了就忘）的 这是最重要的一点，消息发出后，Redis不会存储它，如果一个订阅者在发布者发送消息的那一刻没有在线（比如网络断了，或者程序重启了），那么这条消息它就永远收不到了，它就像电台广播，你没打开收音机，就错过了那段节目，它不保证消息的可靠性，适合用于对丢失少量消息不敏感的场景，比如实时推送在线用户数、简单的聊天室消息、状态通知等。

2. 没有持久化 跟上一条相关，因为消息不发完就存，所以Redis服务器如果重启，所有的频道和订阅关系都会消失，这跟Redis的列表（List）、流（Stream）等能持久化数据的结构完全不同。

3. 它是广播性质的 一条消息会被发送给当前频道下的每一个订阅者，如果你有100个订阅者，Redis就会把这同一条消息发送100次，这有时候是你想要的（比如群发通知），但有时候可能不是（比如任务只希望被一个消费者处理）。

4. 消息格式 当你订阅一个频道后，收到的不是简单的字符串，而是一个包含三条信息的数组，订阅时你会收到 1) "subscribe" 2) "channel_name" 3) (integer) 1；收到消息时是 1) "message" 2) "channel_name" 3) "actual_message_content",你的程序需要能解析这种格式。

5. 性能特点 因为消息是直接推送的，所以Pub/Sub的延迟极低，速度非常快，如果订阅者非常多，或者消息体非常大,会对Redis服务器和网络带宽造成压力。

那什么时候该用它呢？

了解了它的特性,就能明白它的用武之地了：

• 实时聊天室/群聊系统：一个用户发言（发布），房间里所有其他人（订阅）实时看到。
• 实时数据看板：后台数据有更新（比如销售额变化），立即发布消息,前端页面订阅并实时刷新图表。
• 微服务间的简单事件通知：服务A完成了一个任务，发个消息通知服务B，但即使B没收到,也不影响核心流程。
• 服务器内部进程间通信。

你可以把Redis Pub/Sub看作一个非常轻量级、快速、但“不靠谱”的实时消息广播系统，它用起来简单直接，但不能指望它像专业的消息队列（如RabbitMQ、Kafka）那样保证消息不丢、严格有序、持久化，用它之前，一定要想清楚你的场景是否能接受“丢了就丢了”这种特性，如果能,那它就是一把又快又顺手的瑞士军刀。