当前位置：首页 > 问答 > 正文

redis消费失败了咋整？聊聊那些解决办法和实操经验分享

第一，尽量别摔跤（预防）；第二，万一摔了，得知道怎么收拾烂摊子，并且保证客人最终能吃到菜（恢复与保证）。

下面我就结合一些大家常说的办法和我自己踩过的坑,聊聊具体咋整。

最基本的招儿：失败了重试几次

这是人的第一反应，菜撒了，如果只是掉在干净的托盘里，可能捡起来赶紧再端上去也行（食品行业不提倡，但我们处理数据可以这么干）。

实操是啥样？ 在你的消费代码里，用个 try-catch 把处理逻辑包起来，一旦报错，别急着宣布失败，先打个日志，然后让它原地重试个两三次，比如网络抖动了一下,可能第二次重试就成功了。
坑在哪？
- 无限重试：如果这个错误是因为你的代码bug导致的，那重试一万次也成功不了，反而会把你的服务器资源耗尽，所以一定要设置一个最大重试次数,比如3次。
- 立即重试：如果是因为下游服务压力太大导致的短暂失败，你一秒内连续重试三次，等于在人家喘不过气的时候又上去捶了三拳，最好能有个重试间隔，比如第一次失败等1秒，第二次等3秒，这叫“指数退避”（名字听起来专业，但意思就是等的时间越来越长）。

小结：重试是必须的，但要给它加上“理智”的枷锁：限次数、加延迟。

这是非常实用的一招，就像小吃店设了个“问题菜品区”，服务员摔跤的菜（失败的消息）先放到这个特定区域，不影响他继续去端其他的菜，后厨正常运转，客人大部分能及时吃上，等有空了，你再专门来研究“问题菜品区”里的这些菜到底怎么了。

实操是啥样？ 你可以准备两个Redis的List（列表），一个叫 main_queue（主队列），一个叫 dead_letter_queue（死信队列），消费者从主队列取消息：
1. 处理成功：万事大吉,从主队列移除。
2. 达到最大重试次数后依然失败：把这条消息从一个“主队列”搬运到“死信队列”里。
好处是啥？
- 主流程不阻塞：不会因为一条“毒消息”卡住整个消费进程。
- 问题消息不丢失：所有处理不了的消息都安静地躺在死信队列里,等着你后续处理。
后续怎么处理死信队列？ 这就需要人工干预或者更高级的自动化脚本了，你可以写个监控，定时检查死信队列是否堆积，然后人工去排查日志，看看这条消息内容是什么，为什么失败，是数据格式不对？还是依赖的服务挂了很久？修复问题后,再把死信队列里的消息重新投递回主队列执行。

小结：死信队列是保证系统韧性的“安全阀”，把即时失败和后续处理解耦开。

Redis的List有个特性，用 LPOP 命令取消息，消息立马就没了，这就像服务员从厨房窗口一把抓起菜，还没转身，手一滑菜就掉了，而且厨房已经把这道菜从菜单上划掉了——彻底没了。

为了避免这种悲剧，我们可以用更稳妥的方式，比如用 BRPOPLPUSH 命令（来源：Redis官方文档提供的命令），这个命令有点绕，但原理很巧妙：它从一个列表取消息，同时把这条消息备份到另一个“进行中列表”里，等消费者真正处理完这条消息后，再手动去把“进行中列表”里的这条消息删除。

实操是啥样？
1. 消费者使用 BRPOPLPUSH main_queue processing_queue 命令。
2. 这条消息会从 main_queue 移动到 processing_queue。
3. 消费者开始处理消息。
4. 处理成功后，再用 LREM 命令把 processing_queue 里的这条消息删掉。
万一消费者中途崩溃了咋办？ 如果消费者服务器在处理消息时突然宕机，这条消息会永远留在 processing_queue 里，不会丢，你可以另起一个“补偿”进程，定时扫描 processing_queue 里滞留时间过长的消息，认为它们处理失败了，再把它们重新放回 main_queue 的开头,让其他健康的消费者重新处理。

小结：确认式消费虽然麻烦一点，但能最大程度防止消息因为消费者意外崩溃而丢失，适合对数据一致性要求高的场景。

如果你用的Redis版本比较高（5.0以上），强烈建议别再用简单的List了，直接用Redis Stream这个专门为消息流设计的数据结构（来源：Redis官方文档对Stream数据类型的介绍）,它原生就支持了我们上面费老大劲实现的很多功能。

它好在哪？
- 消息持久化与回溯：每个消息都有唯一的ID，消息不会因为被读取而消失,你可以随时根据ID重新读取。
- 消费者组：这是Stream的王牌功能，你可以创建多个消费者组成一个组，来共同消费一个Stream，消息会自动在组内进行负载均衡，Stream会跟踪每个消费者最后处理成功的消息ID，如果某个消费者挂掉，它没处理完的消息会被自动分配给组内其他消费者继续处理,实现了高可用和负载均衡。
- ACK机制：消费者处理完消息后，需要显式地发送一个ACK（确认）命令，Stream才会把这条消息标记为已处理，这完美实现了我们上面说的“确认式消费”。

小结：如果你的项目是新的，或者有条件升级，直接用Redis Stream能让你省掉很多自己造轮子的麻烦，它是更成熟的消息队列解决方案。