spring.rabbitmq.listener.simple.default-requeue-rejected = false 和放入死信队列的区别_rabbitmq default-requeue-rejected

目录

一、场景

二、使用 spring.rabbitmq.listener.simple.default-requeue-rejected = false 

2.1 特点

三、 放入死信队列

四、两种区别

---

一、场景

 当我们使用RabbitMq的时候，我们如果业务中有异常，很有可能造成死循环，因为

•     在RabbitMQ和Spring AMQP的默认配置下，如果消费者（即这里的receiveMessage方法）在处理消息时抛出了未捕获的异常，RabbitMQ会认为该消息没有被正确地处理，因此会将消息重新放回队列（可能会设置延迟后重新投递，或者立即重新投递，具体行为取决于RabbitMQ的 nack/requeue 策略配置）。
•     如果您的应用没有配置任何错误处理策略（如死信交换机、最大重试次数等），那么每当此异常发生时，RabbitMQ都会不断尝试重新投递该消息，从而形成了所谓的“死循环”。

例如在监听队列消息的时候，出现异常，造成了死循环。

 

二、使用 spring.rabbitmq.listener.simple.default-requeue-rejected = false 

2.1 特点

• 当设置为 false 时，消费者在处理消息时如果抛出异常或者主动拒绝（reject）消息，RabbitMQ 不会将该消息重新放回原队列，而是直接丢弃。
• 这样做的优点是可以立即停止对某个无法正确处理的消息的重试，防止死循环，缺点是可能会导致消息永久丢失，除非有额外的备份机制或者监控措施。

三、 放入死信队列

• 使用死信队列是一种更复杂的错误处理策略。当消息在一个队列中达到重试上限或者其他触发条件（如TTL过期）时，RabbitMQ会将该消息转移到另一个预设的死信队列中。
• 在死信队列中的消息不会影响正常消息的流转，同时可以被单独的消费者或流程监控来处理，用于分析失败原因、修复问题或者采取特殊处理（如人工介入）。
• 此方法允许对失败消息进行二次处理或至少保留失败记录以供追溯，相比于直接丢弃更能保证系统的健壮性和容错性。

四、两种区别

•  两者的核心区别在于对待处理失败消息的态度：一个是直接放弃，另一个则是保留下来进行后续处理或分析。在实际应用中，通常推荐使用死信队列机制来保证重要消息的安全性和完整性。