企业官网建设流程全解析

前言

接下来我们来到了发布与订阅内容，请继续跟随我的学习笔记的思路，一起学习吧

提示：以下是本篇文章正文内容，下面案例可供参考

一、什么是发布订阅模式？

Redis 发布订阅（publish/subscribe）是一种经典的消息通信模式，核心逻辑就是发布者发送消息到频道，订阅者通过订阅频道接收消息。发布者和订阅者不需要直接交互，完全通过中间的频道解耦。

打个很形象的比方：频道就像校园里的广播台，发布者是对着麦克风讲话的播音员，所有订阅了这个频道的同学，都能同步听到广播内容。不用一个个单独传话，效率拉满。

整个模式里有三个核心角色：

• 发布者（Publisher）：负责往指定频道里写入消息
• 频道（Channel）：消息的中间载体，一个频道可以同时被无数个订阅者监听
• 订阅者（Subscriber）：订阅自己感兴趣的频道，实时接收频道内的新消息

二、上手实操：两条命令跑通完整流程

这个功能上手真的超简单，我当时开了两个终端就测通了，步骤给大家整理好了：

步骤1：启动订阅者，监听频道

打开第一个Redis客户端，执行subscribe命令订阅一个名为channel1的频道：

127.0.0.1:6379>subscribe channel1 Reading messages...(press Ctrl-C to quit)1)"subscribe"2)"channel1"3)(integer)1

执行之后客户端就会进入阻塞监听状态，此时它就是一个订阅者，会一直等待接收频道里的新消息。

步骤2：启动发布者，发送消息

再开一个Redis客户端，作为发布者，用publish命令往channel1频道里发消息：

127.0.0.1:6379>publish channel1 hello(integer)1

返回的数字1代表当前有 1 个订阅者成功收到了这条消息。

步骤3：查看订阅端接收效果

切回第一个订阅者客户端，就能看到实时收到的消息了：

1)"message"2)"channel1"3)"hello"

当时我试的时候还挺有成就感的，就像实现了一个极简版的实时聊天室，一发一收几乎没有延迟。

三、深入:它的底层逻辑是什么？

Redis的发布订阅实现其实不算复杂，核心就是维护了一张频道-订阅者的映射表。

每个频道都会对应一个订阅者链表，当有发布者往频道里发送消息时，Redis会遍历这个链表，把消息依次推送给链表上的所有订阅者。
也正因为是这种简单的链表遍历+即时推送，它的性能很高，但也注定了它没有复杂的消息存储、确认、重试机制。

四、应用场景

学技术最终还是要落地，Redis发布订阅更适合这些轻量级的实时广播场景：

1. 全站系统通知：比如网站的公告推送、后台管理系统的操作提醒，发一条消息所有在线用户都能同步收到。
2. 简易实时聊天：小型课程项目、个人 demo 里做即时通讯，不用额外搭建消息中间件，直接用Redis就能实现基础群聊。
3. 集群配置更新：分布式服务集群里，修改配置后通过频道广播，所有服务节点能实时更新本地配置，不用重启。
4. 业务解耦：比如用户注册成功后，发一条消息到频道，积分服务、邮件服务、短信服务各自订阅处理，不用串行调用。

五、踩坑预警：别把它当专业消息队列用！

这是我学习时最容易踩的误区：一开始以为它能替代RabbitMQ，后来才发现完全不是一回事。Redis发布订阅有很明显的短板，用错场景会出大问题：

1. 消息不持久化，发完即消
   消息是即时推送的，不会在Redis里存储。如果订阅者掉线了，没收到的消息就彻底丢失了，重连之后也收不到历史消息。

2. 没有消息确认机制
   发布者只管发送，不关心订阅者有没有收到、有没有处理成功。如果订阅者处理消息时程序崩溃，这条消息就直接丢了，没有重试机制。

3. 不支持消息堆积
   如果订阅者处理速度慢，消息不会堆积在Redis里等待消费，新消息过来还是直接推送，很容易导致消息丢失。

4. 缺少高级MQ特性
   像死信队列、消费组、消息持久化、顺序消费这些专业消息队列的核心功能，它统统没有。

一句话总结：它是个轻量级的广播工具，不是消息队列。核心业务的消息流转，还是老老实实用RabbitMQ、Kafka。

六、学习总结

最后把知识点串一下，方便大家快速回顾：

核心优势

• 上手成本极低：Redis原生自带，不用额外部署中间件
• 实时性强：纯内存操作，消息推送延迟极低
• 解耦能力：发布者和订阅者完全无感知，通过频道交互

明显短板

• 消息不持久化，不保证可靠送达
• 无消息确认、无消息堆积能力
• 功能单一，仅支持简单的广播场景

适用场景
对消息可靠性要求不高的实时通知、简单广播场景；核心业务、需要保证消息不丢的场景不建议使用。