一. 前言

　　最近有很多小伙伴开始找工作，在面试时，面试官经常问到一个题目：RabbitMQ如何防止重复消费?

　　有很多小伙伴这个时候都在想，消息怎么就会重复消费呢???.......

　　所以他们在面试后就跑来问健哥，针对这个比较高频的题目，健哥就在这里为大家来讲讲MQ防止重复消费的实现方案吧。

　　二. 面试题考点

　　如果面试官是健哥的话，那么我想考察的，其实就是候选人除了对技术的基本使用之外，再就是在各种实际应用场景中对可能发生问题的实际处理能力。

　　所以这道题的考点，最起码有两点:

　　第一是RabbitMQ中消息的重复消费是如何产生的，我们首先要发现问题,，知道问题产生原因;

　　第二是针对这个重复消费问题的处理方案及机制。

　　·

　　三. 解题分析

　　接下来健哥就根据上述考点，带大家来一起分析这个问题的解题思路。

　　3.1 RabbitMQ消息重复消费的产生原因

　　根据上图，健哥给大家梳理总结出了消息重复消费的产生过程，如下：

　　消费方的业务项目从MQ队列中接收数据;

　　接着处理业务;

　　业务处理成功后，消费方项目给MQ返回ack进行手动确认;

　　返回回调执行结果的过程中，因为网络抖动等原因，回调数据时，MQ没有返回成功，所以MQ队列中的数据会再次发给业务项目，造成重复消费。

　　3.2. RabbitMQ消息重复消费的处理方案

　　针对消息的重复消费问题，健哥根据上图总结的解决思路如下：

　　监听器接收MQ队列中的数据;

　　利用redis的setnx命令，以消息唯一id为key，以消息内容为value，超时时间设置为10秒，存入redis中;

　　如果能够成功存入，说明没有重复消费，则处理业务，处理完业务后返回ack或者nack确认;

　　如果存不进去，则说明重复消费，直接返回ack确认的回调信息就可以了。

　　3.3 解决重复消费的案例代码

　　·

　　发送方测试代码

　　接收方测试代码

　　四. 总结

　　经过上面的分析，最后健哥再给大家总结一下这个问题的完整答案。

　　·

　　问题产生原因：

　　·

　　因为消费方和MQ服务器网络闪断等原因，造成了接收方消费后，返回给MQ服务器一个ack确认消息，结果MQ没有接收到，造成了重复消费。

　　·

　　解决过程：

　　·

　　利用redis的setnx命令，将消费的消息id存入到redis，超时时间设置为10秒，然后再给mq返回ack。消费前要判断redis中是否存在这个消息id，如果不存在说明没有消费过，则正常消费;如果redis中存在这个消息id，则说明重复消费，直接返回ack，不重复执行业务。

　　以上就是MQ中消息重复消费的产生原因及解决思路和对应案例，现在你知道该怎么解决了吗?如果你还有其他疑问，可以在评论区给我们留言哦。关注Java架构栈，每天干货不断!

上一篇

HashMap与ConcurrentHashMap的区别

下一篇

Redis的持久化机制有哪几种