Redis发布订阅怎么灵活用，多频道消息通信其实没那么难

（引用来源：Redis官方文档关于PUB/SUB的章节，以及《Redis实战》一书中对发布订阅模式的用例探讨）

Redis的发布订阅，说白了就是一种简单的消息通知机制，你可以把它想象成一个广播站或者一个布告栏系统，有些人负责贴通知（发布者），有些人负责看通知（订阅者），它的核心就三个命令：SUBSCRIBE（订阅）、PUBLISH（发布）、UNSUBSCRIBE（退订）。

基础玩法：一个频道就够了

最直接的用法就是只用一个频道，我有一个在线聊天室，所有用户都订阅了一个叫 chat:general 的频道，当任何一个用户发送一条消息时，程序就用 PUBLISH 命令把消息内容发到这个频道里，所有订阅了 chat:general 频道的用户都会立刻收到这条消息。

这种单频道的模式非常适合这种广播场景，

• 实时通知： 网站上有重要公告,需要立刻让所有在线用户看到弹窗。
• 简单的进度同步： 比如一个后台任务完成了,通知所有前端页面刷新状态。

但只有一个频道，就像学校里只有一个大喇叭，所有消息都混在一起，如果想聊点私密话题，或者只关心某个球队的新闻,这个大喇叭就显得很吵了。

进阶玩法：按主题分频道，让消息各走各的路

Redis发布订阅的强大之处在于，频道名是可以任意设置的，这意味着我们可以创建无数个频道,让消息根据不同的主题进行路由。

还拿聊天室举例，我们可以为每个房间创建一个独立的频道，chat:room:music（音乐闲聊室）、chat:room:programming（编程技术室），用户喜欢哪个话题，就订阅哪个频道，在音乐室聊天的用户，永远不会收到编程室里的技术讨论,整个世界就清静了。

这个思路可以扩展到很多地方：

• 新闻App： 创建 news:sports、news:tech、news:finance 等频道，用户根据兴趣订阅,只接收自己关心的新闻推送。
• 多用户协作编辑： 比如一个在线文档工具，每个文档都有一个独立的频道，如 doc:12345，当用户A编辑了文档，系统将操作信息发布到这个文档的专属频道，那么正在编辑同一个文档的用户B和C就能实时看到A的改动,而其他文档的用户完全不受影响。
• 系统日志分类： 将不同级别的日志（log:error, log:warning, log:info）或者不同服务的日志发布到不同频道,方便监控系统按需订阅和处理。

更灵活的玩法：用通配符订阅多个频道

如果一个用户既喜欢音乐又关心科技新闻，难道要他手动一个一个地去订阅 chat:room:music 和 news:tech 吗？Redis提供了一个更聪明的办法：通配符订阅。

通配符有两个：

• （星号）：匹配任意数量的任意字符（除了小数点）。
• （问号）：匹配一个任意字符。

我用 PSUBSCRIBE news:* 命令，意思是“我订阅所有以 news: 开头的频道”，无论之后新增加了 news:travel 还是 news:food，我都能自动收到这些频道的消息,而不需要重新订阅。

这个功能非常强大：

• 监控一类事件： 想象一个电商平台，订单状态会变化，订单频道可以设计为 order:123:status，如果后台有一个管理系统想监控所有订单的状态变化，它不需要知道具体有哪些订单ID，只需要一句 PSUBSCRIBE order:*:status 就能一网打尽。
• 简化客户端逻辑： 客户端不需要维护一个长长的频道列表,只需要用一个模式就能关注一组相关的信息。

重要提醒：理解发布订阅的“瞬间”特性

使用Redis发布订阅有一个至关重要的点必须清楚：它是非持久化的，这意味着消息就像一阵风,吹过就没了。

• 消息只在连接的订阅者间传递： 如果一个客户端在消息发布的那一刻没有订阅那个频道，那么它就永远错过了这条消息,Redis不会为它保存。
• 消息不会堆积： 它不像消息队列（如RabbitMQ、Kafka），消息发出来如果没有消费者，会留在队列里等着，Redis的发布订阅是“现场直播”，观众没到场,节目就过去了。

它最适合用在对实时性要求高，但允许少量消息丢失的场景，比如实时聊天、状态更新、触发实时刷新，如果你需要确保每一条消息都必须被处理，比如扣款、下单这类业务，就应该用Redis的列表（List）结构模拟消息队列,或者使用专业的消息队列中间件。

总结一下

Redis的发布订阅一点都不神秘，它的灵活就在于你对“频道”这个名字的理解和设计上，你可以把它当成一个大喇叭，也可以把它打造成一个拥有无数个专业频道的有线电视系统,关键是：

1. 用好频道命名： 像设计文件夹路径一样设计你的频道名（服务名:模块名:操作名）,让它们有规律。
2. 善用通配符： 用模式订阅来批量管理频道,减少客户端的负担。
3. 认清它的脾气： 知道它是“瞬间”的、非持久化的,把它用在正确的业务场景里。

这样，你就能轻松地用这个简单的工具,构建出非常灵活高效的多频道消息通信系统了。