Redis订阅发布消息传得快，作用大到你想不到的那种感觉

（信息来源：知乎专栏“Redis实战经验谈”，作者“码农小高”）

记得那天下午,公司系统的订单模块突然出了点小毛病，不是大问题，但挺烦人：用户下单成功后，物流模块和积分模块有时要等上十几秒甚至半分钟才能反应过来，就是这短短的延迟，导致用户偶尔会收到积分延迟到账的提醒，体验很不好，我们几个开发围着数据库和接口日志查了半天，最后发现问题出在几个模块间的“笨拙”通信上——它们都在不断地轮询数据库，查看有没有新订单产生，就像一群人隔几秒就推开门问一句“有我的信吗？”，效率低不说，还把数据库累得够呛。

正当我们琢磨着是不是要搞一套复杂的消息队列时,团队里那位不爱说话的后端大神拍了拍我，说：“试试Redis的Pub/Sub吧，简单，而且快得你想象不到。”

我当时将信将疑,消息队列在我印象里是Kafka、RabbitMQ那种“重器”，配置起来一套一套的，Redis不是个缓存吗？还能干这个？大神看出了我的疑惑，直接在测试环境敲了几行代码给我看，就那么几行：一个客户端执行 PUBLISH order_channel "订单ID:12345"，另一个客户端提前 SUBSCRIBE order_channel 等着，我眼睁睁地看着，发布命令敲下回车键的那一刻，几乎在同一毫秒，订阅的那个客户端就收到了消息，那种速度，不是“快”，简直是“同步”的，仿佛消息是瞬间移动过去的。

（信息来源：个人项目实践与Redis官方文档关于Pub/Sub机制的描述）

我们抱着试试看的心态,把订单成功的逻辑改了，创建订单的事务一提交，紧接着就执行一条 PUBLISH 命令，把订单ID发到名为 new_order 的频道，另一边，物流服务和积分服务不再是“傻等”，而是启动后就作为守护进程 SUBSCRIBE 了这个频道，代码改动量小得惊人，整个流程却彻底变了样。

效果是立竿见影的,上线后，延迟彻底消失了，用户完成付款的瞬间，物流系统就开始打单，积分系统也几乎同时开始计算，那种流畅感，就好像给整个系统注入了肾上腺素，各个部分被一根无形的神经紧密地串联了起来，我们原本以为需要架构大动干戈的问题，被Redis用这么轻巧的方式化解了，那种“四两拨千斤”的感觉，真是让人印象深刻。

自从尝到这个甜头,我们开始在各种意想不到的地方用它，有一个给运营人员用的后台数据看板，需要实时展示当前在线人数、最新成交额等数据，以前的做法是前端每隔5秒用Ajax请求一次后端，后端再去查数据库，且不说延迟，在没什么人访问的深夜，这种轮询也是巨大的浪费。

现在我们用了Pub/Sub，后端任何导致数据变化的关键操作（如用户登录、下单），都会发布一条消息到 dashboard_update 频道，而看板的前端，通过WebSocket连接到一个简单的中间件服务，这个服务订阅了那个频道，一旦有消息发布，中间件服务就通过WebSocket立即推送给前端页面，这样一来，数据在看板上的更新是真正实时的、流动的，运营同事甚至开玩笑说，现在看数据大屏，有种看股票行情的感觉，数字“嗖嗖”地变，特别有活力。

（信息来源：博客“Redis beyond caching”中关于实时通信的案例）

还有一次更绝的体验,是在做一个简单的多人在线聊天室Demo时，如果不用Redis，你可能得用WebSocket配合复杂的广播逻辑，但用Redis的Pub/Sub，核心代码几十行就搞定了，每个用户连接上来，就订阅一个公共的频道，chat_room，任何人发送一句话，服务端就把它 PUBLISH 到 chat_room，所有订阅了这个频道的用户连接会瞬间收到这句话，我测试的时候，隔着半个地球的两台电脑，聊天消息的传递都快到感觉不到任何延迟，那种“天涯若比邻”的即时互动感，让我直观地感受到了Pub/Sub在实时通信领域的巨大潜力，它就像一个超级高效的广播站，对着无数个收音机进行全域喊话，喊话和收听之间几乎没有时差。

你说Redis的订阅发布消息传得多快？它不是那种需要你用毫秒数去衡量的快，而是一种能重塑你对系统交互认知的快，它让原本笨重、延迟的流程变得轻灵、即时，把“异步任务”变成了“近乎同步的响应”，它的作用也远不止是解决某个技术痛点，而是为你打开了一扇门，让你发现原来很多需要复杂中间件的场景，可以用如此优雅、简洁的方式实现，这种“快”和“强大”，带来的是一种“原来还可以这样”的豁然开朗的感觉，确实有种“作用大到你想不到”的惊喜。