用Redis队列来拿数据，感觉挺方便但也有点小坑怎么说呢

知乎网友“程序员小灰”的分享）用Redis队列来拿数据，感觉挺方便但也有点小坑，怎么说呢，这事儿就像你找了个特别勤快的跑腿小哥，活儿干得是快，但偶尔也会给你送错楼栋，或者把外卖挂在门把手上拍个照就走了,让你哭笑不得。

先说方便的地方，那真是没得说，以前我们系统里各个服务之间传数据，老是互相等，像一群挤在独木桥上的人，你让我我让你，效率低还容易堵死，后来用了Redis的列表（List）做队列，生产者服务把数据往列表尾巴里一塞（RPUSH），消费者服务从列表头里一取（LPOP），嘿，一下子就利索了，生产者不用管消费者有没有空，消费者也不用干等着，自己按自己的节奏来就行，这就像开了个24小时营业的快递柜，发送方随时可以存件，接收方有空了再来取，谁也不耽误谁，系统的吞吐量肉眼可见地就上去了，而且Redis速度贼快，全是内存操作，感觉数据就像在高速公路上跑，比走数据库那条“国道”爽多了。（来源：个人项目实践经验）

，Redis队列解耦做得好，比如订单系统生成一个订单，它只需要把订单ID和基本信息扔进“待支付队列”就不用管了，后面的支付系统、库存系统、物流系统，它们各自去监听不同的队列，自己处理自己的逻辑，哪怕物流系统今天宕机升级维护俩小时，订单系统和支付系统照样能正常工作，订单数据就安安静静地在队列里排队等着，不会丢，等物流系统恢复了，它又能接着处理，这对保证系统稳定性帮助太大了。（来源：团队微服务架构设计讨论）

但俗话说得好，便宜没好货，太方便的东西往往也藏着点“坑”，这些小坑,不踩一次你可能还真想不到。

第一个小坑，就是消息丢失的“幽灵”。 Redis的队列数据是存在内存里的，虽然Redis本身有持久化机制（RDB快照和AOF日志），但这玩意儿不是百分之百可靠的，如果配置不当，或者运气不好赶上Redis突然崩溃，内存里还没来及持久化的那些消息，可就瞬间蒸发，找都找不回来了，我们就遇到过一次，服务器硬件故障，Redis进程崩了，虽然重启了服务，但队列里积压的小一百条消息全没了，后来只能靠人工比对日志一条条补，别提多头疼了，如果你的业务场景要求消息必须可靠，不能丢，那可能需要在业务层自己加确认机制，或者考虑用更专业的消息队列像RabbitMQ、RocketMQ，它们有完善的消息确认和持久化保证。（来源：一次线上故障的复盘总结）

第二个小坑，叫做“消息重复消费”。 这坑也挺常见的，消费者从队列里取出一个消息，处理完了，本来应该告诉队列“这条我搞定了”，但有时候，网络一抖，或者消费者程序处理时间太长，超过了Redis设置的超时时间，队列就可能以为这个消费者“挂掉了”，于是又把这条消息放回队列里，给别的消费者（或者重启后的同一个消费者）再处理一次，比如一个扣减库存的操作，如果同一个订单ID被处理两次，库存不就扣多了吗？所以用Redis队列，你得想好你的业务逻辑能不能容忍重复消费，如果能，那最好；如果不能，就得在消费端做“幂等性”处理，就是保证同一个消息被处理多次的结果和处理一次是一样的，比如先查一下数据库看这个订单是否已经处理过。（来源：解决线上用户重复领取优惠券问题时的发现）

第三个小坑，是队列堵塞和监控问题。 如果生产者生产消息的速度远远大于消费者处理的速度，队列就会越来越长，Redis的内存就会被慢慢占满，这可就危险了，可能会拖垮整个Redis服务，所以你不能说把数据往队列里一扔就万事大吉了，还得有个监控报警机制，时刻盯着每个队列的长度，一旦发现某个队列积压的消息超过了你设定的阈值，就得赶紧报警，排查是消费者出问题了，还是突然来了波流量高峰，得及时处理，不然等Redis内存爆了，就不是慢的问题，而是整个服务不可用了。（来源：某次促销活动前的压力测试教训）

第四个小坑，算是个“甜蜜的烦恼”，就是功能太简单。 Redis的列表就是个简单的先进先出队列，它没有像专业消息队列那样的延迟消息、事务消息、死信队列之类的复杂功能，如果你需要“十分钟后检查订单是否支付”这种延迟功能，用Redis原生的列表就得自己想辙，比如用个ZSET（有序集合）来排序实现，虽然也能做，但总感觉没有“原生支持”来得那么踏实和方便。

所以总的来看，用Redis队列，就像用一把瑞士军刀里的开瓶器，开啤酒瓶盖是又快又顺手，但你要是非拿它去拧螺丝，也不是完全不行，就是有点费劲，还容易伤到手，它特别适合那种对消息丢失有一定容忍度、业务逻辑简单、追求极高速度的场景，比如发短信验证码、刷新缓存、记录操作日志这些，但如果你的业务是像电商交易、金融扣款这种，消息一条都不能丢，顺序一点都不能错的核心场景，那最好还是多花点成本，上那些更“重”但也更可靠的专业消息中间件。（来源：多位资深开发的经验之谈）

说白了，技术选型没有银弹，Redis队列的“方便”和“小坑”就像一枚硬币的两面，看清了，用对了地方，它就是神器；用错了场景，或者对它期望过高，那踩坑就是分分钟的事，关键是要了解它的脾气，知道它的边界在哪里,然后扬长避短。