用Redis订阅通道搞定实时通讯那些事儿，效率杠杠的

（来源：博客园某开发者分享）这事儿得从我们项目里那个头疼的实时消息说起，早先，我们为了做个简单的在线聊天室，用的是最“朴素”的法子：前端JavaScript傻乎乎地每隔几秒就轮询一次后端服务器，问：“有新消息没？”大部分时候，服务器都回答：“没有。”这就搞得非常浪费，服务器压力大，用户收到消息还有延迟，体验就跟用老年机似的，一卡一卡的。

后来团队里有个大哥说：“别轮询了，咱们用WebSocket吧，这才是真正的实时双向通信。”WebSocket确实厉害，一旦连接建立，服务器有消息可以直接“推”给浏览器，又快又省资源，但我们马上遇到了新问题：咱们的服务器不是单打独斗的啊，背后有好几个服务节点，用Nginx做着负载均衡，用户A可能连在服务器1上，用户B连在服务器2上，当A发消息时，消息只到了服务器1，服务器2上的B根本收不到，这就尴尬了，总不能指望他们俩每次都运气好连到同一台服务器上吧？

（来源：Redis官方文档关于Pub/Sub的章节）就在我们琢磨着是不是要搞个更复杂的消息队列时，Redis的Pub/Sub（发布/订阅）模式进入了视线，这玩意儿的概念简单到让人拍大腿！它就像个巨大的公共留言板（这个留言板就是Redis服务器），或者想象成一个广播电台。

• 频道（Channel）：就是电台的频率，比如我们聊天室就叫“room:chat”频道。
• 发布者（Publisher）：负责说话的人，用户A发送消息，他所在的服务器1就扮演这个角色，它对着Redis大喊一声：“喂，‘room:chat’频道的小伙伴们，我这儿有条消息，内容是‘你好啊！’”
• 订阅者（Subscriber）：负责听广播的人，我们所有的服务器节点（服务器1、服务器2、服务器N）在启动时，都提前向Redis订阅（Subscribe）了“room:chat”这个频道，它们就跟戴上了耳机，时刻监听着这个频道。

妙就妙在这里！当服务器1发布消息到“room:chat”频道时，Redis这个中央广播站会立刻把这条消息，原封不动地传递给所有订阅了这个频道的服务器（包括服务器1自己），这样，服务器2也同时收到了这条消息，服务器2再通过它和用户B之间已经建立好的WebSocket连接，把消息瞬间推送给B的浏览器。

这么一来,完美解决了分布式环境下的消息同步问题！无论用户连接到哪台服务器，都能实时收到所有消息，Redis在这里扮演了一个超级高效、可靠的消息中转站角色。

（来源：某技术社区关于Redis Pub/Sub优缺点的讨论）用上这套组合拳（WebSocket + Redis Pub/Sub）之后，效果是立竿见影的，首先就是快，因为Redis是基于内存的，速度没得说，消息几乎是瞬间完成广播，其次就是解耦，我们的业务服务器（发布者）完全不需要关心到底有多少个服务器在监听，它只管对着Redis喊一嗓子就行，剩下的脏活累活Redis都包了，服务器之间也互相不认识，大大简化了系统架构。

天下没有完美的方案,我们也摸到了一些需要注意的地方，Redis的Pub/Sub模式是“发后即忘”的，如果某个服务器节点在消息广播的那一刻刚好断线了，重连之后，它是收不到断线期间错过的消息的，因为它只是一个简单的消息通道，不像专业的消息队列（比如Kafka、RabbitMQ）那样会持久化消息，所以它特别适合在线聊天、实时通知这种“丢了就丢了”的场景，但不能用来做重要的、必须保证送达的任务队列。

如果订阅者（我们的服务器节点）处理消息的速度太慢，Redis会堆积数据导致输出缓冲区变大，可能引发问题，所以我们在服务器端处理Redis过来的消息时，一定要快，最好别在里面做太复杂的计算。

（来源：项目实践总结）对于搞定实时通讯这件“事儿”，用Redis订阅通道这招，在合适的场景下效率确实是杠杠的，它用最简单的模型，解决了分布式系统中最棘手的实时消息广播问题，让我们的聊天室实现了真正的“秒回”，你得清楚它的脾气，知道它擅长什么、不擅长什么，别把它用在它不该用的地方，这套方案对于我们这种量级的项目来说，成本低、见效快，可以说是非常划算的选择了。