Redis消息队列那些事儿，聊聊它到底怎么帮我们解决问题的

说到Redis消息队列,咱们得先聊聊为啥需要它，想象一下你开了一家特别火的网红餐厅（来源：常见的电商秒杀场景类比），客人点单（用户请求）蜂拥而至，后厨（服务器核心业务逻辑）就一个师傅在炒菜，如果每个客人点单，服务员都站在灶台旁边等着师傅做完，再把菜端出去，那后边排队的客人非得急疯了不可，整个餐厅的效率会低得可怕。

这时候,聪明的主管想了个办法，他设置了一个“订单台”（这就是消息队列），服务员接到客人点单后，不直接去后厨等着，而是飞快地把订单写在一张纸条上（这就是一条消息），然后扔进订单台的一个盒子里，接着马上回去接待下一位客人，后厨的师傅呢，就不停地从盒子里按顺序拿出订单，专心致志地炒菜，炒好之后按铃通知服务员来端走。

你看,这个“订单台”就解决了大问题，它解耦了服务员和后厨（来源：系统设计中的解耦概念），服务员不用关心师傅炒菜是快是慢，师傅也不用被服务员不停地催问“好了没”，他们各干各的，通过纸条（消息）来通信，整个流程就顺畅了，对应到系统里，就是不同的服务模块（如下单服务、库存服务、积分服务）不需要直接调用对方，只需要往队列里扔消息或从队列取消息，谁临时挂了也不会直接影响别人。

它消峰填谷（来源：应对流量高峰的常见策略），中午12点，订单像洪水一样涌来（流量高峰），后厨肯定处理不过来，但没关系，订单盒可以暂时堆积很多纸条（消息），师傅还是按照自己的最大能力，一张一张地处理，到了下午3点没什么客人的时候（流量低谷），师傅还能继续处理之前积压的订单，这样，系统就不会被瞬间的高流量冲垮，保证了核心服务的稳定。

它实现了异步处理（来源：提升用户体验和系统吞吐量的关键），客人点完单，拿到小票，就可以先去玩手机了，不用傻傻地等着菜做好，因为服务员告诉他：“单子已经下了，您稍坐，好了叫您。” 这对用户体验来说是极大的提升，系统也一样，用户点击“下单”按钮后，web服务器只需要把订单消息成功塞进Redis队列，就可以立刻返回“下单成功”的提示给用户，而后续那些耗时的操作，比如扣减库存、生成订单、给你加积分、发短信通知等等，都交给后台的多个“后厨师傅”（消费者程序）去异步处理，这样，web服务器能快速响应下一个请求，系统的整体吞吐量就上去了。

Redis是怎么扮演这个“订单台”角色的呢？它主要靠两个非常简单的数据结构：List（列表）和Pub/Sub（发布/订阅）。

List就像是一个简单的先进先出的管道,一方用LPUSH命令从左边推进去消息，另一方用RPOP命令从右边取出消息进行处理，非常简单直接，但这里有个小问题：如果队列是空的，消费者程序会不停地用RPOP去问“有消息吗？有消息吗？”，这叫做“忙等待”，很浪费资源，所以Redis提供了一个阻塞版本的命令BRPOP，消费者可以“睡”在队列旁边，一旦有消息进来，它才会被唤醒取走消息，这样就很高效。

Pub/Sub模式则像是餐厅里的广播，今天龙虾特价（这是一个主题Topic），对龙虾感兴趣的服务员（订阅者）都会竖起耳朵听，当主管广播“一份蒜蓉龙虾”（消息）时，所有订阅了这个频道的服务员都能同时收到，这种模式适合那种“一个消息需要被多个不同服务同时处理”的场景，比如一个订单成功，需要同时通知日志服务、推荐服务和大数据服务。

Redis消息队列也不是万能的,它像个轻量级的敏捷选手（来源：对比RabbitMQ, Kafka等专业消息中间件），它速度快、部署简单，对于很多不那么复杂的场景够用了，但它也有一些“短板”，比如它没有像专业队列那样的消息持久化保证（虽然可以配置，但默认情况下重启Redis内存数据会丢失），它不支持高级的消息路由规则，也没有消息确认（Ack）机制来保证消息绝对不被丢失（如果消费者拿到消息还没处理就崩溃了，这条消息可能就永远消失了）。

总结一下（来源：根据上述分析得出的结论），Redis消息队列就像是我们技术工具箱里的一把瑞士军刀，它可能不如专业的砍刀（Kafka）或者扳手（RabbitMQ）功能强大专一，但它小巧、灵活、速度快，当你需要快速实现服务解耦、应对突发流量、将耗时操作异步化，并且对消息的极高可靠性要求不是那么严苛的时候，用它来临时顶上是再合适不过了，它用最简单的办法，帮我们解决了系统架构中非常核心的流畅性问题。