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