在消息队列中如何处理消费过程中的重复消息

消息队列是一个我们经常使用的中间件，那么我们在使用它的时候经常会被问到一些问题，比如说消息队列如何处理重复消息，消息队列如何防止消息丢失等等内容，那么照片文章就来看一下如何处理消息队列中的重复消费消息的问题。

假设有这样一个场景：“在我们的电商系统中，订单创建后会发送一条消息，下游的优惠券兑换系统会订阅这个消息，然后发放优惠券。我们的系统需要确保每一张优惠券，无论网络如何波动、系统如何异常，都只能被成功兑换一次。你会如何设计呢？”

这个问题看似简单，但它背后考验的是工程师对分布式系统复杂性的理解，尤其是对“幂等性”这一核心概念的掌握程度。很多同学的第一反应可能是“消息队列不是有‘exactly-once’（精确一次）的保证吗？”。但事实上，绝对的“精确一次”在分布式系统中是一个难以达到的理想状态，都需要业务方配合于重试和幂等来达成。

为什么消息会重复

我们在分析这个问题的时候可以拆分为消息队列的几个过程，分别是生产者将消息发送到broker的过程以及消费者从broker中获取数据并消费的过程

我们可以依次来分析

生产者重复发送：因为网络超时等原因没有收到broker的通知，但此时broker已经接收到了消息，这时生产者使用重试机制重复发送消息。
消费者重复消费：这个过程是消费者在从broker中获取到消息之后，它执行完消息对应的操作了，但是还没有提交消息，这时消费者宕机了，然后在消费者重启过来之后由于没有提交偏移量，导致重复消费。

对于生产者重复消费的问题我们并不需要过多的担心，因为我们的kafka本身就有幂等性的约束，它是这么实现的，Kafka 的发送幂等是通过序列号来实现的，每个消息都会被分配一个序列号，序列号是递增的，这样就可以保证消息的顺序性。当生产者发送消息时，会将消息的序列号和消息内容一起写入到日志文件中，下次收到非预期序列号的消息就会返回 OutOfOrderSequenceException 异常。

那么我们主要解决的就是消费者的重复消费问题了，那消费者这么保重永不重复呢，其实保证不了，我们能做的就是让我们的消费端服务具备幂等处理消息的能力。所谓幂等，就是一个请求无论被重复执行多少遍，其系统状态产生的相应都与第一次执行时完全相同。

那如何实现幂等操作呢？最好的方式就是从业务逻辑设计上入手，将香妃的业务逻辑设计成鱼油幂等性的操作。

实现方法

数据库唯一id

这是最简单、最直接，也是最常用的一种方案。其核心思想是，利用数据库中“唯一索引”或“主键”的特性，来阻挡重复数据的插入。

假设我们有一个电商系统，用户下单后会发送一条消息，触发给用户增加积分的操作。消息内容可能包含{ "order_id": "202508310001", "user_id": 58, "points_to_add": 100 }。

这个“增加积分”的操作，天然是非幂等的。我们可以这样改造：

建立一张积分流水表（points_log）。
表中包含字段：id (自增主键), order_id (订单ID), user_id (用户ID), points (变更积分), create_time。
关键一步： 对 order_id 这个字段建立一个唯一索引。

-- 尝试插入积分流水记录
-- 假设 order_id 字段上有唯一索引
INSERT INTO points_log (order_id, user_id, points) VALUES ('202508310001', 58, 100);

第一次消费：该订单ID首次出现，INSERT操作成功。然后我们可以安全地去更新用户的总积分。
重复消费：MQ再次投递相同的消息，消费者尝试INSERT时，数据库会因为order_id的唯一索引冲突而直接报错。我们的代码捕获这个异常后，就可以知道这是重复操作，直接忽略并返回ACK即可。

这是一种最简单的实现情况，面试的时候，为了展现你的思考能力，还可以做一个适当延伸，说明下这种方案的优缺点，以及扩展性

这种方案的优点是： 实现简单，成本低，效果可靠。 缺点也很明显： 强依赖数据库特性，对于非数据库操作的场景无能为力。

基于这个思路，如果不用关系型数据库，Redis的SETNX命令（SET if Not eXists）也能达到异曲同工的效果，可以用order_id作为key，实现分布式锁或状态记录。