目录
一、场景
二、使用 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会将该消息转移到另一个预设的死信队列中。
- 在死信队列中的消息不会影响正常消息的流转，同时可以被单独的消费者或流程监控来处理，用于分析失败原因、修复问题或者采取特殊处理（如人工介入）。
- 此方法允许对失败消息进行二次处理或至少保留失败记录以供追溯，相比于直接丢弃更能保证系统的健壮性和容错性。
四、两种区别
- 两者的核心区别在于对待处理失败消息的态度：一个是直接放弃，另一个则是保留下来进行后续处理或分析。在实际应用中，通常推荐使用死信队列机制来保证重要消息的安全性和完整性。
