文章目录前言一、什么是发布订阅模式二、上手实操两条命令跑通完整流程步骤1启动订阅者监听频道步骤2启动发布者发送消息步骤3查看订阅端接收效果三、深入:它的底层逻辑是什么四、应用场景五、踩坑预警别把它当专业消息队列用六、学习总结前言接下来我们来到了发布与订阅内容请继续跟随我的学习笔记的思路一起学习吧提示以下是本篇文章正文内容下面案例可供参考一、什么是发布订阅模式Redis 发布订阅publish/subscribe是一种经典的消息通信模式核心逻辑就是发布者发送消息到频道订阅者通过订阅频道接收消息。发布者和订阅者不需要直接交互完全通过中间的频道解耦。打个很形象的比方频道就像校园里的广播台发布者是对着麦克风讲话的播音员所有订阅了这个频道的同学都能同步听到广播内容。不用一个个单独传话效率拉满。整个模式里有三个核心角色发布者Publisher负责往指定频道里写入消息频道Channel消息的中间载体一个频道可以同时被无数个订阅者监听订阅者Subscriber订阅自己感兴趣的频道实时接收频道内的新消息二、上手实操两条命令跑通完整流程这个功能上手真的超简单我当时开了两个终端就测通了步骤给大家整理好了步骤1启动订阅者监听频道打开第一个Redis客户端执行subscribe命令订阅一个名为channel1的频道127.0.0.1:6379subscribe channel1 Reading messages...(press Ctrl-C to quit)1)subscribe2)channel13)(integer)1执行之后客户端就会进入阻塞监听状态此时它就是一个订阅者会一直等待接收频道里的新消息。步骤2启动发布者发送消息再开一个Redis客户端作为发布者用publish命令往channel1频道里发消息127.0.0.1:6379publish channel1 hello(integer)1返回的数字1代表当前有 1 个订阅者成功收到了这条消息。步骤3查看订阅端接收效果切回第一个订阅者客户端就能看到实时收到的消息了1)message2)channel13)hello当时我试的时候还挺有成就感的就像实现了一个极简版的实时聊天室一发一收几乎没有延迟。三、深入:它的底层逻辑是什么Redis的发布订阅实现其实不算复杂核心就是维护了一张频道-订阅者的映射表。每个频道都会对应一个订阅者链表当有发布者往频道里发送消息时Redis会遍历这个链表把消息依次推送给链表上的所有订阅者。也正因为是这种简单的链表遍历即时推送它的性能很高但也注定了它没有复杂的消息存储、确认、重试机制。四、应用场景学技术最终还是要落地Redis发布订阅更适合这些轻量级的实时广播场景全站系统通知比如网站的公告推送、后台管理系统的操作提醒发一条消息所有在线用户都能同步收到。简易实时聊天小型课程项目、个人 demo 里做即时通讯不用额外搭建消息中间件直接用Redis就能实现基础群聊。集群配置更新分布式服务集群里修改配置后通过频道广播所有服务节点能实时更新本地配置不用重启。业务解耦比如用户注册成功后发一条消息到频道积分服务、邮件服务、短信服务各自订阅处理不用串行调用。五、踩坑预警别把它当专业消息队列用这是我学习时最容易踩的误区一开始以为它能替代RabbitMQ后来才发现完全不是一回事。Redis发布订阅有很明显的短板用错场景会出大问题消息不持久化发完即消消息是即时推送的不会在Redis里存储。如果订阅者掉线了没收到的消息就彻底丢失了重连之后也收不到历史消息。没有消息确认机制发布者只管发送不关心订阅者有没有收到、有没有处理成功。如果订阅者处理消息时程序崩溃这条消息就直接丢了没有重试机制。不支持消息堆积如果订阅者处理速度慢消息不会堆积在Redis里等待消费新消息过来还是直接推送很容易导致消息丢失。缺少高级MQ特性像死信队列、消费组、消息持久化、顺序消费这些专业消息队列的核心功能它统统没有。一句话总结它是个轻量级的广播工具不是消息队列。核心业务的消息流转还是老老实实用RabbitMQ、Kafka。六、学习总结最后把知识点串一下方便大家快速回顾核心优势上手成本极低Redis原生自带不用额外部署中间件实时性强纯内存操作消息推送延迟极低解耦能力发布者和订阅者完全无感知通过频道交互明显短板消息不持久化不保证可靠送达无消息确认、无消息堆积能力功能单一仅支持简单的广播场景适用场景对消息可靠性要求不高的实时通知、简单广播场景核心业务、需要保证消息不丢的场景不建议使用。
)
