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("ons_test", "*", new MessageListener() {
    
    
    public Action consume(Message message, ConsumeContext context) {
    
    
        String key = message.getKey()
        // 根据业务唯一标识的 key 做幂等处理
    }
});

注意：

消息重复消费的情况是不能去避免的，我们需要考虑的就是在有重复消息的情况之下，怎么取保证幂等性，那么在保证幂等性的有一个关键，就是在发送消息的时候携带一个业务Key，然后在接收到消息后先去获得这个业务Key，然后在消费方的数据库当中判断一下这个业务Key所对应的消息有没有消费过，如果没有消费过就接着消费，消费完了在数据中存储一下，或者缓存数据库中存储也行，如果当前业务Key对应的消息已经消费过，那么直接舍弃即可！

前言

消费幂等的必要性

处理方式

注意：

猜你喜欢