一、什么样的情况下会出现消息重复消费？

在互联网应用中，尤其在网络不稳定的情况下，消息队列 RocketMQ 的消息有可能会出现重复，在一些比较敏感的场景下，重复消费会造成比较严重的后果，例如重复转账，重复支付。这个重复简单可以概括为以下情况：

1、发送消息时重复

当一条消息已被成功发送到服务端并完成持久化，此时出现了网络闪断或者客户端宕机，导

致服务端对客户端应答失败。 如果此时生产者意识到消息发送失败并尝试再次发送消息，

消费者后续会收到两条内容相同并且 Message ID 也相同的消息。  

2、投递消息时重复

在消息消费的场景下，消息已投递到消费者并完成业务处理，当客户端给服务端反馈应答的时

候网络闪断。 为了保证消息至少被消费一次，消息队列 RocketMQ 的服务端将在网络恢复后

再次尝试投递之前已被处理过的消息，消费者后续会收到两条内容相同并且 Message ID 也相

同的消息。

3、负载均衡时消息重复

负载均衡时消息重复（包括但不限于网络抖动、Broker 重启以及订阅方应用重启）。 当消息队列 RocketMQ 的 Broker 或客户端重启、扩容或缩容时，会触发 Rebalance，此时消 费者可能会收到重复消息。

二、解决方案

• 利用数据库有条件的插入语句限制重复插入
• 查询消息系统验证消息是否重复。在消费时，通过订阅的记录和消费的结果来判断，此消息是否重复订阅过，倘若重复订阅，则不再数据库中插入数据。
• 分布式锁（一般是zookeeper和redis搭建）
• 数据库约束+java异常处理机制。需要针对数据库简历约束，不允许产生重复数据，然后再使用java的异常处理机制来规避重复消息

三、总结

一般最好把去重操作直接放在了消费端，消费端处理消息的业务逻辑保持幂等性。消费者收到消息后，从消息中获取消息标识写入到Redis（分布式锁）或数据库（标识作为表唯一索引插入一条记录），当再次收到该消息时就不作处理。在broker端对Queue加锁（synchronized），Consumer监听的Queue存在已投递但未收到ack且未超时的消息，不允许获取锁，直到该Queue投递的消息全部ack或者消费超时，才允许新的Consumer获取锁，拉取消息。

四、思考问题

1、为什么不在生产者去重？

2、为什么在消费者做去重？