死信队列
当一条消息初次消费失败,消息队列RocketMQ会自动进行消息重试;达到最大重试次数后,若消费依然失败,则表明消费者在正常情况下无法正确地消费该消息,此时,消息队列RocketMQ不会立刻将消息丢弃,而是将其发送到该消费者对应的特殊队列中。
在消息队列RocketMQ中,这种正常情况下无法被消费的消息称为死信消息(Dead-Letter Message),存储死信消息的特殊队列称为死信队列(Dead-Letter Queue)。
死信特性
死信消息具有以下特性
- 不会再被消费者正常消费
- 有效期与正常消息相同,均为3天,3天后会被自动删除。因此,请在死信消息产生后的3天内即时处理。
死信队列具有以下特性:
- 一个死信队列对应一个Group ID,而不是对应单个消费者实例
- 如果一个Group ID未产生死信消息,消息队列RocketMQ 不会为其撞见相应的死信队列
- 一个死信队列包含了对应Group ID产生的所有死信消息,不论该消息属于哪个Topic
消费幂等
消息队列RocketMQ 消费者在接受到消息以后,有必要根据业务上的唯一Key对消息做幂等处理的必要性
消费幂等的必要性
在互联网应用中,尤其在网络不稳定的情况下,消费队列RocketMQ的消息有可能会出现重复,这个重复简单可以概括为以下情况:
- 发送时消息重复
当一条消息已被成功发送到服务端并完成持久化,此时出现了网络闪断或者客户端宕机,导致服务端对客户端应答失败。如果此时生产者意识到消息发送失败并尝试再次发送消息,消费者后续会收到两条内容相同并且Message ID 也相同的消息 - 投递时消息重复
消息消费的场景下,消息已投递到消费者并完成业务处理,当客户端给服务端反馈应答的时候网络闪断,为了保证消息至少被消费一次,消息队列RocketMQ的服务端将在网络恢复后再次尝试投递之前已经被处理过的消息,消费者后续会收到两条内容相同并且Message ID呀相同的消息 - 负载均衡时消息重复(包含但不限于网络抖动,Broker重启以及订阅方应用重启)
当消息队列RocketMq 的Broker或客户端重启,扩容或缩容时,会触发Rebalance,此时消费者可能会收到重复消息
处理方式
因为Message ID 有可能出现冲突(重复)的情况,所以真正安全的幂等处理,不建议以Message ID 作为处理依据,最好的方式是以业务唯一表示作为幂等处理的关键依据,而业务的唯一标识可以通过消息key进行设置
订阅放收到消息时可以根据消息的key进行幂等处理