深入理解消息幂等性：分布式系统中的消息去重策略与工程实践

一、为什么消息会重复？

在分布式系统中，消息重复消费是一个无法完全避免的现象。理解其根本原因，是设计幂等方案的前提。

1.1 网络不可靠性

TCP 协议虽然保证了可靠传输，但在以下场景下仍可能出现重复：

• ACK 丢失：消息处理完成但 ACK 因网络问题丢失，消息队列超时后会重新投递
• 连接断开：消费者与 Broker 连接中断，Broker 感知不到消费完成，触发重新投递
• 超时重试：处理耗时超过 Broker 的重试窗口，导致消息被重复推送

1.2 生产端重试

生产者发送消息后未收到确认（网络抖动、Broker 重启等），按「至少一次」语义会自动重试，造成消息重复写入。

1.3 消费者重平衡

Kafka Consumer Group 触发 Rebalance 时，部分分区的消费位移可能未及时提交，导致新消费者从旧位点重新消费。

1.4 人工运维操作

消息回溯、Offset 重置、死信队列重投等运维手段也会导致消息被再次投递。

二、什么是幂等性？

幂等（Idempotent）的数学定义是：对同一操作的任意多次执行所产生的影响与一次执行的影响相同。用公式表达：f(f(x)) = f(x)。

在消息消费场景中，幂等性意味着：同一条消息被消费一次或多次，对系统状态的改变是一致的。

2.1 不同操作的幂等性天然差异

因此，针对天然非幂等的操作（INSERT、增减更新），必须引入额外的幂等机制。

三、核心幂等策略

3.1 唯一消息ID + 去重表

这是最通用、最可靠的方案。每条消息携带全局唯一的业务ID，消费端维护已处理ID的记录表。

public boolean consumeWithIdempotency(Message msg) {
    String msgId = msg.get("biz_id");
    if (duplicateLog.exists(msgId)) {
        log.info("消息已处理，跳过: {}", msgId);
        return true;
    }
    processBusinessLogic(msg);
    duplicateLog.insert(msgId, System.currentTimeMillis());
    return true;
}

关键要点：

• 去重表与业务表在同一个数据库、同一个事务中，保证原子性
• 去重表设置合理的 TTL（如保留7天），定期清理过期数据
• 使用 Redis Set 等缓存层加速判断，但必须以数据库为准

3.2 数据库唯一约束

利用数据库表的 UNIQUE 约束，在 INSERT 时自动去重。适用于业务主键天然唯一的场景。

CREATE TABLE t_order (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    order_no VARCHAR(64) NOT NULL UNIQUE,
    amount DECIMAL(10,2),
    status TINYINT
);
INSERT INTO t_order (order_no, amount, status) VALUES ("ORD20241015001", 199.99, 1);
-- Duplicate entry → 捕获异常即为重复消息

3.3 乐观锁（版本号机制）

通过版本号控制并发更新，即使消息重复也只会有一笔更新生效。

UPDATE account SET balance = balance - 100, version = version + 1
WHERE user_id = 123 AND version = 5;
-- 影响行数为0 → 已处理过，直接返回成功

3.4 状态机（前置状态校验）

业务数据通常有明确的状态流转（待支付 → 已支付 → 已发货 → 已完成），通过状态前置条件保证幂等。

int updated = jdbcTemplate.update(
    "UPDATE t_order SET status = ?, pay_time = NOW() WHERE order_no = ? AND status = ?",
    OrderStatus.PAID.getCode(), orderNo, OrderStatus.PENDING.getCode()
);
if (updated == 0) {
    return ConsumeResult.SUCCESS; // 不处于待支付状态，已处理
}

3.5 分布式锁方案

为消息ID加上分布式锁，同一时刻只有一个消费者能处理该消息。适合执行时间较长但会降低吞吐量的场景。

四、主流消息中间件的幂等支持

4.1 Kafka 的幂等生产者

Kafka 0.11+ 引入了幂等生产者（Idempotent Producer），通过 PID（Producer ID）+ Sequence Number 实现 Broker 端的逐分区去重。配置 enable.idempotence=true 即可开启。但仅保证单会话单分区的去重，消费端幂等仍需自行实现。

4.2 RocketMQ 的事务消息

RocketMQ 提供事务消息机制，通过 Half Message → Commit → 消费 的流程保证消息最终一致。RocketMQ 5.x 的 Exactly-Once 消息进一步支持了消费端的事务回查机制。

4.3 RabbitMQ

RabbitMQ 不内置幂等机制，需依赖消费者自行实现。常见做法是使用 delivered 标志位或外部去重表。

五、工程落地方案推荐

标准架构：唯一ID + Redis 预检 + DB 去重表

消息到达 → 提取 bizId → Redis SETNX(bizId, 1, TTL=7天) → 失败则直接 ACK → 执行业务逻辑 → DB 事务（业务操作 + 写入去重记录）→ ACK

六、常见踩坑与最佳实践

• 去重记录要在事务内：如果去重记录和业务操作不在同一事务中，会导致去重失效
• 设置合理的去重窗口：常规业务7天，金融/支付30天甚至更长
• 全局唯一ID生成：推荐雪花算法、UUID、Leaf，不依赖消息队列 offset
• 幂等键设计：结合业务语义，如 orderId + eventType、billNo + amount

七、总结

消息幂等是分布式系统中不可或缺的基础能力。核心思路：「先查后做，有据可查，结果唯一」

给每条消息赋予全局唯一的业务标识；处理前先查询是否已处理；业务操作与去重记录在同一事务中完成；合理设置去重记录的有效期。没有银弹，合适的才是最好的。