本文共 1651 字,大约阅读时间需要 5 分钟。
当一条消息消费失败时,RocketMQ会进行一定次数的重试。重试的结果也很简单,无非就是在第N次重试时,被成功消费。或者就是经过M次重试后,仍然没有被消息。这通常是由于消费者在正常情况下无法正确地消费该消费。此时,RocketMQ不会立即将消息丢弃,而是将其发送到该消费者对应的特殊队列中去。
在RocketMQ中,这种正常情况下无法被消费的消息被称为死信消息(Dead-Letter Message),存储死信消息的特殊队列称为死信队列(Dead-Letter Queue)。
(1)死信消息具有以下特性:
(2)死信队列具有以下特性:
(1)在控制台查询出现死信队列的主题信息
(2)在消费界面根据主题查询死信消息
(3)选择重新发送消息
一条消息进入死信队列,意味着某些因素导致消费者无法正常消费该消息。因此,通常需要我们对其进行特殊处理。排查可疑因素并解决问题后,可以在消息队列 RocketMQ 控制台重新发送该消息,让消费者重新消费一次。
RocketMQ并不保证一条消息只会被推送一次,因此一条消息就有可能被消费多次。消费者在接收到消息以后,有必要根据业务上的唯一 Key 对消息做幂等处理的必要性。
在互联网应用中,尤其在网络不稳定的情况下,RocketMQ 的消息有可能会出现重复,这个重复简单可以概括为以下情况:
发送时消息重复
当一条消息已被成功发送到服务端并完成持久化,此时出现了网络闪断或者客户端宕机,导致服务端对客户端应答失败。 如果此时生产者意识到消息发送失败并尝试再次发送消息,消费者后续会收到两条内容相同并且 Message ID 也相同的消息。
投递时消息重复
消息消费的场景下,消息已投递到消费者并完成业务处理,当客户端给服务端反馈应答的时候网络闪断。 为了保证消息至少被消费一次,消息队列 RocketMQ 的服务端将在网络恢复后再次尝试投递之前已被处理过的消息,消费者后续会收到两条内容相同并且 Message ID 也相同的消息。
负载均衡时消息重复(包括但不限于网络抖动、Broker 重启以及订阅方应用重启)
当RocketMQ 的 Broker 或客户端重启、扩容或缩容时,会触发 Rebalance,此时消费者可能会收到重复消息。
因为 Message ID 有可能出现冲突(重复)的情况,所以真正安全的幂等处理,不建议以 Message ID 作为处理依据。 最好的方式是以业务唯一标识作为幂等处理的关键依据,而业务的唯一标识可以通过消息 Key 进行设置:
Message message = new Message();message.setKey("ORDERID_100");SendResult sendResult = producer.send(message);
消费方收到消息时可以根据消息的 Key 进行幂等处理:
consumer.subscribe("test", "*", new MessageListener() { public Action consume(Message message, ConsumeContext context) { String key = message.getKey() // 根据业务唯一标识的 key 做幂等处理 }});
转载地址:http://ahxzb.baihongyu.com/