用Redis盯着Key动静，系统性能能蹭蹭往上涨的感觉

这事儿得从一个让我头疼了好几天的问题说起,我们有个功能，用户下单后，能实时看到订单的处理状态，已接单”、“配送中”这些，最早的做法特简单，就是让用户的手机App隔那么几秒钟，就偷偷摸摸地往后端服务器问一句：“我的这个订单，状态变没变呀？”（来源：基于轮询的简单状态查询设计）

一开始用户少,订单也少，这么搞好像也没啥，但后来用户量一上来，好家伙，服务器可就遭了老罪了，你想想，成千上万的用户，每人每几秒就发一次请求，哪怕这个订单状态八百年没变，他也照样问，这感觉就像你家里有个宝贝，你心里不踏实，每隔一分钟就跑去保险柜那儿打开看看东西还在不在，你自己累得够呛，还把保险柜的锁给磨平了。（来源：高并发下轮询机制对服务器造成的无效负载类比）

服务器那头的数据库,就像那个可怜的保险柜锁，被这种“无效查询”折腾得够呛，大部分时间都在回答“没变呢”、“还是老样子”，真正有用的活儿反而干得慢了，整个系统的响应速度明显下降，用户也开始抱怨App时不时卡一下，我当时就想，这肯定不是个办法，得换个思路。

后来,我们团队里有个大神提了一嘴：“为啥不用Redis的Pub/Sub呢？让它帮我们‘盯着’订单状态的变化，变了再通知App，别让App傻乎乎地老是问。”（来源：Redis发布订阅模式的应用场景讨论）

我一听,有点开窍，Redis这东西，我们本来就在用，主要是拿来存一些临时热点数据，因为它速度特别快，数据都在内存里，但这个Pub/Sub（发布/订阅）功能，我之前还真没太在意，它的原理其实不难理解，就像我们平时订杂志：你（订阅者）对某个话题（频道）感兴趣，你就去杂志社（Redis）登记一下，说“这个频道的杂志我全都要”，一旦有这个频道的新杂志出版（发布者发布了消息），杂志社就会主动把新杂志寄给你，你不用天天跑去报刊亭问“到了没”。（来源：用杂志订阅比喻Redis Pub/Sub的工作模式）

我们立马就开始动手改造,具体是这样干的：

当用户打开订单详情页的时候,App不再傻傻地开始轮询了，它先干一件事：向我们的后端服务发送一个请求，说“我要监听订单号是123456的这个订单的状态变化”，后端服务收到后，并不直接去查数据库，而是帮这个用户的连接“订阅”到Redis的一个特定频道上，这个频道的名字我们就约定好，比如叫order:status:123456。（来源：利用Redis频道实现按订单号区分的状态监听设计）

重头戏来了,当商家后台处理订单，比如把状态从“已接单”改成“配送中”时，我们的后端服务在更新数据库的同时，会做一件额外的事：它跑到Redis那里，对着名叫order:status:123456的这个频道“喊一嗓子”（发布消息），消息内容就是新的状态“配送中”。（来源：状态变更时同步发布消息到Redis频道）

这时候,神奇的事情发生了，Redis知道所有订阅了order:status:123456这个频道的连接（可能就只有一个用户的App，也可能有多个），它会立刻把这个“配送中”的消息，主动推送给这些正在等待的App，App收到消息，界面上的状态立马就更新了，几乎感觉不到延迟。（来源：Redis服务端主动推送消息到订阅者）

这么一改,效果立竿见影！

最直观的感觉就是,服务器一下子轻松了太多，以前是海量的、重复的、大部分是无效的查询请求，现在绝大部分请求都消失了，只有在状态真正发生变化的那一瞬间，才会产生一次有效的网络通信，数据库的压力骤降，CPU使用率看着就往下降，之前那种因为频繁查询导致的卡顿现象几乎不见了踪影。（来源：采用Pub/Sub模式后服务器负载显著降低的观测结果）

体验的提升是实实在在的,他们不再需要等待那几秒一次的“轮询间隔”，状态变化几乎是实时的，商家这边一点“发货”，用户那边App上立马就显示“配送中”，这种流畅感带来的惊喜，比我们预想的还要好。（来源：用户端体验从延迟更新到近实时更新的提升感受）

这个过程里我们也处理了一些细节,要考虑网络不稳定，万一App断线重连了怎么办？我们设计了重连机制，重新订阅一下就好，还有，不是所有状态都需要长时间监听，订单完成后，我们也会清理掉相关的订阅，避免Redis积累太多无用的连接。（来源：实践中对连接稳定性和资源清理的考量）

回过头看,这个优化之所以能成功，关键就在于我们把“主动频繁查询”这个笨办法，换成了“被动事件通知”的聪明办法，Redis在这里扮演了一个超级高效、超级可靠的信使角色，它帮我们扛住了“盯着”Key（也就是订单号）动静的这个繁重任务，解放了主力数据库，也让整个系统的响应变得轻盈、迅速，看着监控大屏上那些下降的负载曲线和上升的响应速度曲线，那种“系统性能蹭蹭往上涨”的感觉，确实让人非常痛快，这让我明白，有时候优化性能不一定非要上更贵的硬件，换个思路，用对工具，四两也能拨千斤。