Redis消息队列时效优化能带来多倍收益，性能提升真不是吹的

（引用来源：某电商技术团队博客分享）

之前我们系统的消息队列一直有点小毛病,说白了就是“慢”，尤其是在做各种促销活动的时候，比如双十一、618这种大场面，用户下单后，要等好几秒甚至十几秒才能收到确认短信或者看到订单状态更新，技术部门每天都能接到一堆投诉，说系统卡顿，体验太差，我们一开始以为是服务器不够，拼命加机器，钱花了不少，但效果就像往一个漏水的桶里倒水，问题根本没解决。

后来我们技术团队下决心要挖一挖根因,这一查才发现，瓶颈根本不在计算资源上，而是在我们用的那个Redis消息队列的处理时效上，我们的流程是这样的：用户下单后，订单信息会被塞进一个Redis的列表里，然后后端的各种处理服务，比如扣库存、发短信、更新订单状态的服务，都像抢糖果的小孩一样，从这个列表里不停地取消息来处理。

（引用来源：团队内部性能分析报告）

问题就出在这个“取消息”的方式上，我们最开始用的是传统的LPOP命令，也就是服务端轮询，简单说，就是处理服务一遍遍地询问Redis：“有新消息吗？”“没有。”“现在呢？”“没有。”……绝大部分询问都是徒劳的，因为消息并不是每时每刻都有的，这种频繁的、无效的查询请求，给Redis服务器带来了巨大的压力，占用了大量的网络带宽和CPU资源，Redis本身忙着应付这些“问候”，处理真正业务消息的能力反而被拖累了，这就好比一个邮局的分拣员，大部分时间都在接听询问“我的信到了没”的电话，根本没空去分拣桌上堆积如山的信件。

（引用来源：团队技术方案选型文档）

找到病根后,我们开始找药方，我们发现了Redis提供的BRPOP命令，这是一种阻塞式读取，它的机制就聪明多了：处理服务向Redis发起一个请求后，如果队列里是空的，它不会立刻返回“没消息”，而是会“睡”在那儿，连接保持着，但不再反复询问，一旦有新的消息被放进队列，Redis会立刻唤醒这个“沉睡”的连接，把消息直接推送给它，这样一来，无效的轮询请求几乎降到了零。

（引用来源：系统优化后数据监控）

我们抱着试试看的心态,在一个业务模块上切换到了这种阻塞式读取的方式，结果优化上线后的效果，用我们项目经理的话说，“简直像换了一个发动机”，首先最直观的感受是，Redis服务器的CPU使用率直接下降了超过60%，之前高峰期那种红色警报再也没有出现过，服务器变得非常“清闲”，因为它再也不用处理海量的无用查询了。

消息处理的延迟得到了惊人的改善,之前一条消息从进入队列到被处理，平均延迟在几百毫秒到一秒，高峰期甚至更久，优化之后，这个延迟被稳定地控制在了10毫秒以内，几乎做到了实时响应，用户下单后，几乎是秒级就能收到确认信息，前端的各种状态更新也变得无比流畅，投诉量断崖式下降。

也是意想不到的收获,就是成本的大幅降低，因为Redis服务器的负载降下来了，我们不仅不需要再计划购买新的高性能服务器，甚至还把现有的一部分服务器资源做了整合，缩减了云服务的开支，这真是实实在在的收益，是老板最喜欢看到的结果。

（引用来源：团队总结复盘会议）

这次优化给我们最大的启示就是：有时候性能瓶颈的解决，并不总是需要堆硬件、花大钱，深入理解你所用技术的底层原理，哪怕只是一个简单的命令替换，从轮询改为阻塞监听，就能带来天壤之别的效果，这种优化带来的性能提升是实实在在的，带来的成本和体验收益也是立竿见影的，真不是吹的，它让我们明白，在追求高大上技术方案之前，先把现有的基础工具用到极致，往往能收获最大的回报。