从RocketMQ源码深扒中，我找出了7种导致消息重复消费的原因

柔情只为你懂 2024-03-25 22:29 12阅读 0赞

在众多关于MQ的面试八股文中有这么一道题，“如何保证MQ消息消费的幂等性”。

为什么需要保证幂等性呢？是因为消息会重复消费。

为什么消息会重复消费？

明明已经消费了，为什么消息会被再次被消费呢？

不同的MQ产生的原因可能不一样

本文就以RocketMQ为例，来扒一扒RocketMQ中会导致消息重复消息的原因，最终你会发现，其实消息重复消费算是RocketMQ无奈的“bug”。

![format_png][]

### 消息发送异常时重复发送 ###

首先，我们来瞅瞅RocketMQ发送消息和消费消息的基本原理。

![format_png 1][]

如图，简单说一下上图中的概念：

*  Broker，就是RocketMQ的服务端，如上图就有两个服务实例
 *  Topic就是一类消息集合的名字
 *  Queue就是Topic的对应的队列，消息都存在Queue上，每个Topic都会有自己的几个Queue

所以，整个消息发送和消费过程大致如下：

*  生产者在发送消息之前根据负载均衡策略(默认是轮询)选择一个Queue，然后跟这个Queue所在的机器建立连接，把消息发送到这个Queue上
 *  消费者只要消费这个Queue，那么就能消费到消息

在正常情况下，生产者的确是按照这个方式来发送消息的

但是当出现了异常时，这种异常包括消息发送超时、响应超时等等，RocketMQ为了保证消息成功发送，会进行消息发送的重试操作，默认情况下会最多会重试两次

![format_png 2][]

重试操作比较简单，就是选择另一台机器的Queue来发送。

虽然重试操作可以很大程度保证消息能够发送成功，但是同时也会带来消息重复发送的问题。

举个例子，假设生产者向A机器发送消息，发生了异常，响应超时了，但是就一定代表消息没发成功么？

不一定，有可能会出现服务端的确接受到并处理了消息，但是由于网络波动等等，导致生产者接收不到服务端响应的情况，此时消息处理成功了，但是生成者还是以为发生了异常

此时如果发生重试操作，那么势必会导致消息被发送了两次甚至更多次，导致服务端存了多条相同的消息，那么就一定会导致消费者**重复消费消息**。

### 消费消息抛出异常 ###

在RocketMQ的并发消费消息的模式下，需要用户实现`MessageListenerConcurrently`接口来处理消息

![format_png 3][]

当消费者获取到消息之后会调用`MessageListenerConcurrently`的实现，传入需要消费的**消息集合**`msgs`，这里提到的`msgs`很重要

![format_png 4][]

如上代码，当消息消费出现异常的时候，`status`就会为null，后面就会将`status`设置成为`RECONSUME_LATER`。

`RECONSUME_LATER`翻译成功中文就是稍后重新消费的意思

所以从这可以看出，一旦抛出异常，那么消息之后就可以被重复消息。

到这其实可能有小伙伴觉得消息消费失败重新消费很正常，保证消息尽可

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/5924b9e98b194b67a1c392afacd86380.png
[format_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/2956b8549fc046f0bcb30c1a797be3cf.png
[format_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/1428b0e51a054418a5dfa4500064114f.png
[format_png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/2dc446b72dd748c7b06d941e520a0173.png
[format_png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/e231f011f2f34d08a62fc0a83c959438.png