第27章消息丢失/重复消费的全链路排查（生产者→Broker→消费者）

所属模块：模块五：消息中间件深度实战

消息丢失/重复消费的全链路排查（生产者→Broker→消费者）

一、真实场景

一批订单创建成功消息，在一次网络抖动后，部分订单没有触发下游的库存扣减和物流通知，排查发现是消息丢失导致的。整个排查过程横跨生产者、Broker、消费者三个环节，才最终定位到问题出在生产者的异步发送模式没有做失败确认处理。

场景变体：同一笔扣款被处理了两次

与消息丢失对称的另一类故障是重复消费：某次网络抖动导致消费者处理完一笔支付成功消息、准备提交offset确认时超时，Broker没有收到确认，于是在短暂延迟后把这条消息重新投递给了消费者（或消费组内的另一个实例），业务侧因为没有做幂等处理，同一笔支付被重复入账，导致用户账户余额多加了一次。这类问题往往比消息丢失更隐蔽------因为消息"确实被消费到了"，日志里能看到两次处理记录，很容易被误判为"业务代码本身有 bug 重复调用了两次"，而不是消息中间件层面的正常重投递行为。

二、消息丢失的全链路拆解

消息从产生到被消费，经过三个环节，每个环节都存在独立的丢失风险，需要分别设置对应的可靠性保障：

2.1 生产者环节

如果采用异步发送 且不等待Broker确认结果就认为发送成功（比如fire-and-forget模式），一旦网络异常或者Broker临时不可用，消息可能根本没有到达Broker，但生产者侧的业务代码却认为"已经发送成功"继续往下执行。

Kafka 的 acks 参数直接决定了这个环节的可靠性级别：

acks 取值	含义	可靠性	性能
`acks=0`	生产者发出后不等待任何确认，发送即认为成功	最低，网络异常时消息直接丢失且无感知	最高
`acks=1`	只要求 Leader 副本写入成功即确认	中等，Leader 写入后、同步给 Follower 前发生故障仍会丢失	中等
`acks=all`（或 `-1`）	要求所有 ISR（In-Sync Replicas，同步副本集合）都写入成功才确认	最高，需配合 `min.insync.replicas` 使用	相对较低

对应的解决方案是设置acks=all（Kafka）这类参数，要求生产者必须等待Broker（以及配置的副本数量）明确确认接收成功才算发送完成，同时在业务代码里对发送失败的情况做重试或者记录到本地消息表（呼应第18章讲的本地消息表方案）兜底。

重试与重复的取舍 ：一旦在生产者侧引入失败重试，就必然会在网络抖动、超时误判等场景下产生"消息其实已经发送成功，只是确认响应没送达"的情况，重试会导致 Broker 收到同一条消息的多个副本，这是重复消费问题的源头之一。因此可靠的生产者配置从来不是孤立的------acks=all + 重试机制，必须同时搭配 enable.idempotence=true（幂等生产者），让 Broker 能够根据生产者分配的序列号自动识别并丢弃重复的重试请求，两者缺一不可。

2.2 Broker存储环节

如果Broker的刷盘策略是异步刷盘（消息先写入操作系统的页缓存，由操作系统异步刷到磁盘），一旦Broker所在机器发生断电或者进程崩溃，还没来得及刷盘的消息会丢失。

对应的解决方案是配置同步刷盘（每条消息写入后立即强制刷盘再返回确认），但这会明显降低写入性能，需要结合业务对可靠性和性能的真实取舍来决定；更常见的折中方案是配合多副本机制，只要消息成功同步到多数副本，即使某一个副本所在机器故障，数据依然不会丢失。

需要注意的是，acks=all 只保证消息同步到了 ISR 列表内的副本，如果 min.insync.replicas（最少同步副本数）设置为 1，即使配置了 acks=all，在只剩一个副本存活的极端情况下，这一份数据依然是单点，仍然存在丢失风险------acks=all 和 min.insync.replicas 需要配合起来看，才能准确评估真实的可靠性水位。

2.3 消费者环节

这是最容易被忽视的丢失场景------如果消费者采用先提交offset（消费位点），再处理业务逻辑 的模式，一旦offset提交成功后、业务逻辑处理过程中程序异常崩溃，这条消息在Broker看来已经被"消费"过了（offset已经前移），但实际业务逻辑并没有执行成功，造成事实上的消息丢失。正确的顺序应该是先完整处理完业务逻辑，确认处理成功后，再提交offset。

另一个容易踩的坑是 Kafka 客户端默认开启的自动提交 （enable.auto.commit=true），自动提交会按固定时间间隔（auto.commit.interval.ms）在后台提交offset，这个提交时机和业务逻辑是否处理完全无关------如果自动提交恰好发生在业务逻辑执行到一半时，同样会造成"offset已前移但业务未完成"的丢失场景，生产环境对可靠性有要求的消费链路，都应该关闭自动提交，改为业务逻辑完成后手动提交。

三、重复消费的全链路拆解

大多数消息中间件默认提供的是 at-least-once（至少一次）语义，而不是 exactly-once（精确一次）------这意味着"消息可能会被重复投递"本身就是设计上允许发生的正常现象，而不是故障。理解这一点后，重复消费的排查重点就不再是"为什么会重复"，而是"业务侧的幂等处理是否到位"。

3.1 重复产生的三个来源

生产者重试导致的重复：如 2.1 节所述，发送失败重试且未开启幂等生产者时，Broker 可能存储了同一条业务消息的多份拷贝；
消费者 ack 未送达导致的重复投递：消费者已经处理完业务逻辑，但提交offset的确认请求因网络问题未能到达 Broker，Broker 会认为这条消息还未被成功消费，在超时后重新投递给消费组内的某个实例；
消费者组再均衡（Rebalance）导致的重复：消费者实例发生扩缩容、宕机重启、心跳超时等情况，触发分区重新分配，如果某个分区在再均衡发生前刚处理完一批消息但offset还未来得及提交，这批消息会被重新分配到的消费者再次消费。

3.2 幂等消费设计

既然重复投递无法从消息中间件层面完全杜绝，业务侧的幂等处理就是必须补齐的一环，常见做法包括：

数据库唯一约束去重：为业务表设计唯一索引（如订单号 + 操作类型），重复消费时插入会因唯一约束冲突而失败，业务代码捕获该异常直接判定为重复，跳过后续处理；
状态机判断：处理前先查询当前业务状态（如订单是否已经是"已扣库存"状态），如果已经是目标状态则直接跳过，只有状态未变更时才执行实际操作；
乐观锁版本号 ：更新数据时带上版本号或前置状态作为更新条件（如 UPDATE ... WHERE status = 'PENDING'），重复消费时由于状态已经变化，更新会影响 0 行，据此判断为重复并跳过；
短期去重表 / Redis 去重 ：为每条消息生成全局唯一ID，消费前先用 SETNX 之类的原子操作在 Redis 里做一次短期去重标记，命中说明是重复消息，直接跳过（适合对处理时效要求高、不方便直接查业务表状态的场景，需要注意去重标记的过期时间要覆盖住消息可能重复投递的最大时间窗口）。

四、可靠性配置清单

在评审一条消息链路的可靠性时，可以对照以下清单逐项检查，而不是凭印象判断"应该没问题"：

生产者是否配置了 acks=all，而不是默认的 acks=1；
生产者是否开启了 enable.idempotence=true，避免重试导致 Broker 端重复存储；
生产者发送失败是否有本地记录兜底（本地消息表 / 重试队列），而不是仅打一条错误日志；
Broker 的 min.insync.replicas 是否与 acks=all 配合，达到预期的可靠性水位（通常建议至少为 2）；
消费者是否关闭了自动提交（enable.auto.commit=false），改为业务处理成功后手动提交；
消费者处理逻辑是否具备幂等性，能够正确处理同一条消息被重复投递的情况；
是否为关键链路建立了消息全局唯一ID，并在生产、Broker、消费三端埋点，具备端到端的链路追踪能力。

五、排查工具 / 关键命令

消息链路追踪是排查这类问题最有效的手段------为每条消息生成一个全局唯一ID，在生产、Broker存储确认、消费者处理成功这三个关键节点分别打印带有这个ID的日志，一旁比对三端的日志，就能精确定位消息究竟是在哪个环节"消失"的；而对重复消费问题，同样的全局唯一ID可以用来在业务表或日志中检索"同一个ID是否出现了多次成功处理记录"，从而确认是否发生了重复消费。

bash 复制代码

# Kafka:查看某个消费组的消费进度(offset),对比生产端已发送的消息总数
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group order-consumer-group

# 查看__consumer_offsets内部topic,了解offset提交的详细记录(用于更深入的问题排查)

# 查看某个 Topic 分区的 ISR 状态,确认 min.insync.replicas 是否有足够副本存活
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic order-events

# 结合业务侧 SQL,按消息全局唯一ID分组,统计是否存在同一ID被处理多次的记录
# SELECT message_id, COUNT(*) FROM order_process_log GROUP BY message_id HAVING COUNT(*) > 1;

六、代码示例：可靠消息发送与幂等消费模板

java 复制代码

// 生产者:同步确认发送,并对失败情况做本地记录兜底
public void sendOrderCreatedEvent(OrderCreatedEvent event) {
    try {
        RecordMetadata metadata = kafkaTemplate.send("order-events", event.getOrderId(), JSON.toJSONString(event))
            .get(3, TimeUnit.SECONDS); // 同步等待Broker确认
        log.info("消息发送成功, offset: {}", metadata.offset());
    } catch (Exception e) {
        log.error("消息发送失败,记录到本地消息表等待重试: {}", event.getOrderId(), e);
        localMessageMapper.insertPending(event); // 兜底,由定时任务重试
    }
}

// 消费者:先完整处理业务逻辑,成功后再手动提交offset,并做幂等判断
@KafkaListener(topics = "order-events", groupId = "order-consumer-group")
public void onMessage(ConsumerRecord<String, String> record, Acknowledgment ack) {
    OrderCreatedEvent event = JSON.parseObject(record.value(), OrderCreatedEvent.class);
    try {
        // 幂等判断:利用 Redis SETNX 做短期去重,命中说明是重复投递,直接跳过
        Boolean firstSeen = redisTemplate.opsForValue()
            .setIfAbsent("dedup:order-events:" + event.getMessageId(), "1", 10, TimeUnit.MINUTES);
        if (Boolean.FALSE.equals(firstSeen)) {
            log.info("检测到重复消息,直接跳过: {}", event.getMessageId());
            ack.acknowledge(); // 重复消息也需要正常提交offset,避免无限重新投递
            return;
        }
        processOrderCreated(event); // 先处理完整业务逻辑
        ack.acknowledge(); // 处理成功后再手动提交offset
    } catch (Exception e) {
        log.error("消息处理失败,不提交offset,等待重新投递: {}", record.value(), e);
        // 不调用ack.acknowledge(),消息会在下次poll时被重新消费
    }
}

对应的生产者与消费者关键配置（Kafka示例）：

properties 复制代码

# 生产者
acks=all
retries=3
enable.idempotence=true

# 消费者
enable.auto.commit=false

七、常见误区

把"用了消息队列"直接等同于"消息不会丢失"------消息中间件本身只是提供了实现高可靠性的能力（比如各种确认机制、刷盘策略、副本机制），但默认配置往往是为了性能做了取舍（比如默认的异步发送、异步刷盘），不做针对性的可靠性配置，默认情况下这三个环节都存在真实的丢失风险，不能想当然地认为"用了Kafka/RocketMQ，消息就绝对可靠"。
把重复消费当作"业务代码有 bug"来排查，而没有意识到 at-least-once 语义下重复投递是正常现象------排查方向应该从"为什么重复"转向"幂等处理是否到位"，前者往往排查不出结果，因为重复投递本身就是设计使然。
只做了acks=all却没开启幂等生产者------重试机制和acks=all结合，会必然在网络抖动场景下产生重复消息，如果不开启enable.idempotence，这些重复会原封不动地流入下游，变成消费者必须独自承担的幂等负担。
用 Redis 短期去重时，去重标记的过期时间设置得比消息可能被重新投递的最大时间窗口还短------比如消费者组再均衡可能导致消息在几分钟后才被重新投递，但去重标记只设置了几十秒过期，等消息真正被重复投递时，去重标记早已失效，起不到防护效果。
消费者手动提交offset却把提交操作放在了try块之外或者放在了异步线程里------手动提交必须发生在业务逻辑真正处理成功之后的同一个逻辑分支内，一旦提交时机和业务处理结果脱节，等于变相退化成了"先提交再处理"的不可靠模式。

正确的核心认知：消息可靠性不是消息中间件单方面提供的属性，而是生产者配置、Broker配置、消费者处理逻辑三端协同才能达成的结果；同时，"消息不丢失"和"消息不重复"是两个独立的目标------多数消息中间件默认只保证前者对应的 at-least-once 语义，重复消费是设计上允许的正常现象，业务侧必须自行补齐幂等处理，而不是寄希望于中间件本身做到 exactly-once。

第27章 消息丢失/重复消费的全链路排查（生产者→Broker→消费者）