RabbitMQ中重试机制的坑

最新推荐文章于 2024-08-07 23:25:58 发布

黄国攀

最新推荐文章于 2024-08-07 23:25:58 发布

阅读量6.4k

点赞数 3

分类专栏：消息队列文章标签： rabbitmq

本文链接：https://blog.csdn.net/u010857795/article/details/113192636

版权

本文探讨了在RabbitMQ中使用SpringAMQP的重试机制遇到的问题。当消息消费失败时，重试机制在处理业务代码异常和网络抖动等问题上存在局限。配置重试机制时，若代码中使用try/catch，会导致重试失效。若消息自动确认，多次重试失败后消息丢失；若手动确认，消息将保持unacked状态，造成积压。为解决此问题，提出了手动确认并在catch中抛异常触发重试，结合错误计数器控制何时将消息nack并发送到死信队列进行后续处理的策略。

摘要由CSDN通过智能技术生成

当我们消息消费失败的时候，可以进行重试，虽然SpringAMQP集成了retry机制，但是发现使用过程有点坑，等会细说
重试机制使用场景：
1.如果是业务代码，比如空指针之类的异常那重试机制其实没什么用
2.如果是调用第三方系统，网络抖动之类的那重试机制就有用

配置使用重试机制

spring.rabbitmq.listener.simple.retry.enabled=true 是否开启消费者重试（为false时重试不生效）
spring.rabbitmq.listener.simple.retry.max-attempts=3  最大重试次数（包含本身消费的1次）
spring.rabbitmq.listener.simple.retry.initial-interval=5000 重试间隔时间（单位毫秒）
spring.rabbitmq.listener.simple.default-requeue-rejected=false 重试次数超过上面的设置之后是否丢弃（false不丢弃时需要写相应代码将该消息加入死信队列）

坑的地方来了：
不管消息被消费了之后是手动确认还是自动确认，代码中不能使用try/catch捕获异常，否则重试机制失效
所以这里要使用重试机制就有2种情况了：
1.如果消息是自动确认，由于异常，多次重试还是失败，消息被自动确认，那消息就丢失了
2.如果消息是手动确认，由于异常，多次重试还是失败，消息没被确认，也无法nack，就一直是unacked状态ÿ