Redis消息队列实操分享，教你快速搞定系统性能瓶颈问题

根据多位开发者的博客分享及项目实践经验整理）

今天咱们来聊聊一个实实在在能解决系统卡顿问题的工具——Redis消息队列，你可能听过Kafka、RabbitMQ这些专业的消息队列，但它们配置起来有点复杂，好比是开重型卡车去菜市场买菜，大材小用还麻烦，而Redis呢，就像一辆灵活的小摩托，简单快捷，特别适合我们日常开发中遇到的那些需要“削峰填谷”的场景。

什么是“削峰填谷”？

想象一下,你的系统平时安安稳稳，突然搞了个促销活动，或者用户集中在一个时间点上传图片，海量的请求“轰”的一下涌进来，就像一座陡峭的山峰，你的服务器CPU和数据库可能瞬间就被压垮了，页面卡死，用户骂娘，这就是“峰”。

“削峰”就是用一个中间人（也就是消息队列）挡在请求和真正的业务处理之间，所有的请求先到这个中间人这里排好队，然后你的业务系统再按照自己能承受的速度，慢慢从队伍里取任务来处理，这样，即使外面洪水滔天，你的业务系统内部依然风平浪静，处理速度很平稳，就像把高峰削平了，把瞬时的大量请求填到了时间谷底，这就是Redis消息队列最核心的用处。

Redis怎么当消息队列用？

Redis里面有个叫“列表（List）”的数据结构，它天生就是个队列，支持从左边进（LPUSH），从右边出（RPOP），完美符合“先进先出”的排队原则，操作起来也超级简单，就两条命令：

1. 生产者发消息：比如有个用户下订单了，你的程序不用直接去扣库存、写数据库，太慢，你就执行一句 LPUSH order_queue '{"orderId": "123", "userId": "456", "item": "手机"}'，把这个订单信息当成一个字符串（通常用JSON格式）塞进名叫order_queue的队列左边，这个过程非常快，因为Redis是内存操作，然后你就可以立刻给用户返回“下单成功”的提示了，用户体验丝滑。

2. 消费者取消息：在后台，你单独开一个或者多个“消费者”程序，它们不停地执行 RPOP order_queue，从队列右边取出最早进入的订单消息，取出来后再慢慢地、安全地去完成扣库存、生成订单等复杂的数据库操作，哪怕这个过程需要一秒，也不会影响用户下单的速度。

一个关键问题：消费者不能傻等

上面说的RPOP有个小毛病，如果队列是空的，它就会立刻返回空值，然后你的消费者程序就会陷入“取一下，空的，再取一下，还是空的”这种循环，这叫“忙等待”，白白浪费CPU。

解决办法是使用BRPOP命令，这个“B”代表阻塞（Block），你可以设置一个阻塞时间，比如5秒：BRPOP order_queue 5，意思是，去队列右边取消息，如果有消息立刻返回；如果没消息，我就死等在这，最多等5秒，这期间有消息来了我马上拿走去处理，5秒后还没消息我再返回空，然后重新发起下一次等待，这样消费者就聪明了，不瞎忙活。

实际项目中怎么搞？

假设你有个用户注册后发邮件的需求,用户注册不能卡，但发邮件可能因为网络问题慢几秒，你就可以这么设计：

• 注册接口：用户点击注册，你把用户信息写入数据库，同时把用户的邮箱地址LPUSH到一个叫email_queue的队列里，然后立刻告诉用户“注册成功，请查收邮件”。
• 发邮件服务：这是一个独立的后台程序，甚至可以是另一台服务器上的脚本，它用一个死循环，不断地用BRPOP从email_queue里取邮箱地址，取到后就调用发邮件的接口去发送，这个服务挂了或者慢了，完全不影响新用户注册。

这样一来,注册流程的性能瓶颈就解决了，你可以轻松应对注册高峰，哪怕一秒来一千个新用户，你的注册接口也只是往Redis里塞一千条数据，快得很，发邮件服务慢慢在后面发就行了。

比List更高级的用法——Stream（来源：Redis官方文档及进阶教程）

Redis 5.0之后推出了一个更强大的数据结构叫Stream，它才是真正的“专业级”消息队列，解决了List的一些不足。

• 消息回溯：List里的消息被RPOP取走就没了，而Stream里的消息可以持久化，允许多个消费者组来消费，一个消费者挂了，其他消费者可以接着处理；还可以重新读取之前的消息，用于对账或排查问题。
• 更可靠：消费者需要主动确认消息处理完成（ACK），如果处理失败，消息会被重新放回队列，避免消息丢失。

如果你的业务场景对消息可靠性要求很高,比如金融交易，建议直接上Stream，但对于大多数像发通知、刷新缓存、记录日志这类要求不高的场景，用List实现简单队列就完全够用了，性能极高。

总结一下

Redis消息队列不是什么高深莫测的黑科技,它就是一个用内存帮你做“缓冲”的实用工具，核心思想就是异步处理，把实时要做的事情和耗时的东西分开，用空间（内存）换时间（响应速度），下次当你发现系统某个环节突然变慢，不妨想想：这个环节能不能拆出来？能不能把请求先丢到Redis里排队，让程序慢慢消化？很多时候，加上这么一个简单的设计，系统性能就能有立竿见影的提升。