用Redis消息队列玩转高效访问，性能提升还真不是吹的

综合自多个技术社区博客及Redis官方文档的应用案例分享）

记得我们那个项目吗？就是那个一到搞活动、发优惠券的时候，服务器就跟喘不过气来似的项目，用户一点“领取”，页面就转圈圈，转个十几秒，最后要么告诉你“系统繁忙”，要么干脆给你来个白屏，技术群里都快炸锅了，数据库的压力曲线眼看着就往天花板冲，DBA同事的脸都快绿了。

后来我们琢磨,问题的根子就在于，高峰期的请求太集中了，像千军万马同时过独木桥，每个领取请求，都要马上连着数据库，又是查库存又是写记录，数据库哪受得了这个，这时候，有个哥们儿提了个想法：“咱们用Redis的消息队列试试？”

说实话,一开始我心里也打鼓，Redis不就是个缓存吗？还能管这个？但死马当活马医，我们就动手试了试，这一试，效果还真不是吹的。

我们是怎么做的呢？

就是把“马上要做”的事情，变成“等会儿按顺序慢慢做”。

以前是：用户点击 -> 服务器 -> 立刻处理业务（查数据库、减库存、写记录）-> 返回结果给用户，这个过程里，最耗时的就是跟数据库打交道的那几步，而且必须等所有步骤都做完，用户才能收到反馈。

现在是：用户点击 -> 服务器 -> 把领取任务（比如用户ID、优惠券ID）飞快地扔进Redis的一个列表（List）里 -> 立刻告诉用户“请求已提交，正在处理中”，我们背后偷偷开了一堆“工人”（Worker进程），这些工人啥也不干，就不停地从那个Redis列表里挨个取出任务，再慢慢地、一个一个地去跟数据库打交道，完成最终的库存检查和记录写入。

这么一搞，神奇的事情发生了：

1. 用户感觉“飞”起来了：页面响应速度发生了质变，以前要等十几秒，现在几乎就是“秒回”，因为服务器不用再去死磕数据库了，它只需要把任务信息往Redis里一存，这个操作对于Redis来说就是小菜一碟，速度极快，用户马上就能看到“领取请求已提交”的友好提示，体验感直线上升。

   

2. 数据库压力“泄洪”了：高峰期的请求不再是同时冲击数据库的“海啸”，而是被Redis这个消息队列给“缓冲”了一下，变成了一条平滑的“小溪流”，那些后台工人按照自己的节奏，匀速地从队列里取任务处理，数据库的压力曲线瞬间变得平缓可爱，DBA同事的脸上也终于见到了笑容。

3. 系统变得更“结实”了：就算突然间又来了一波超级流量，比如某个大V突然转发了我们的活动链接，瞬间涌进来十倍的请求也没关系，消息队列就像一个巨大的蓄水池，把请求都先存起来，系统能处理多少，后台工人就取多少，避免了因为瞬时压力过大而导致整个系统崩溃的惨剧，万一某个后台工人处理任务时突然挂掉了，也没事，这个任务还在队列里放着呢，其他在线的工人可以接着处理，保证了任务不会丢失。 来源：其中关于削峰填谷和异步处理的思想，参考了《Redis实战》一书中的相关章节）

我们也不是简单地用Redis的List的LPUSH和RPOP就完事了,我们还考虑了更多情况，比如要防止多个工人同时抢到同一个任务，我们用了更可靠的BRPOP命令；还有，我们设置了重试机制，如果一个任务处理失败了，会把它放到另一个“重试队列”里，过会儿再试几次，实在不行再记录日志告警，人工介入看看是啥问题。

说白了,用上Redis消息队列这一招，就像是给系统请了一个超级能干的“前台”和“调度员”，这个“前台”反应极快，能瞬间接待所有来的客人（用户请求），并给他们一个安心的答复；而真正的重活、累活（操作数据库），则交给了后院的“工人们”有条不紊地去完成，前后端彻底分开，谁也不耽误谁。

自从用了这个方案,我们再也没为这种高并发秒杀类的场景头疼过，性能提升是实实在在看得见的，运维的麻烦也少了一大半，所以我说，用Redis消息队列玩转高效访问，这效果，还真不是吹出来的，它用一种相对简单的方式，就解决了我们的大麻烦，让技术真正为业务顺畅跑了保驾护航。