排查 Kafka CommitFailedException

Kafka 消息处理成功后又被消费时，先记录重复消息的 topic、partition、offset 和业务键。同一 Kafka 位点重现，优先查消费端位点提交；同一业务键对应不同位点，转查生产者重试或上游重复投递。出现 CommitFailedException 时，直接排查 rebalance、处理耗时和消费者成员变化。

排查分类参考 CSDN《Kafka 重复消费：自动提交位点与手动提交的 3 个错位》，具体判断仍以实际日志和提交结果为准。

先按位点、业务键和报错分类

常见报错如下：

org.apache.kafka.clients.consumer.CommitFailedException: Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member.

该报错表明提交发生时，消费者组已经重平衡，相关分区被交给了另一成员，因此当前成员提交的位点可能不再被接受。

如果相同业务键对应不同 offset，就不能继续只盯消费端。Kafka 0.11 及以上可以启用幂等生产者，减少生产者重试造成的重复写入：

props.put("enable.idempotence", true);

它不能代替消费端提交，也不能解决消费端重放。 同时核对 group.id 是否发生变化，位点是按消费者组跟踪的，换了组相当于换了一套消费进度。

自动提交为什么会在处理成功后重放

自动提交不等于业务方法返回后立即提交。资料描述的常见客户端行为是：后续 poll() 触发自动提交时，提交上一轮 poll() 返回的消息位点。因此，业务成功与位点落盘之间存在重放窗口。

排查时重点核对三处：两次 poll() 之间是否发生过进程退出、强制结束线程或 rebalance；单批消息是否处理过慢，导致迟迟没有进入下一次 poll()；关闭消费者前是否先调用了 unsubscribe()，使部分位点没有提交。

如果需要把提交时机绑定到业务成功时，可以关闭自动提交：

props.put("enable.auto.commit", "false");

对应的 Spring 配置为：

spring.kafka.consumer.enable-auto-commit=false

关闭自动提交只是把提交责任交给应用。如果没有在业务成功后正确提交，重复窗口不会消失，只是从客户端自动提交转移到了应用代码。

手动提交和重平衡要一起改

手动提交要满足两个条件：业务成功后再提交，提交的位点则是下一条消息的位点，即当前 offset + 1。业务完成前提交可能漏消费，业务完成后提交失败仍会重复消费。

多分区批量消费时，应按分区分别记录下一位点，避免拿错分区或落后位点：

Map<TopicPartition, OffsetAndMetadata> nextOffsets = new HashMap<>();

for (ConsumerRecord<String, String> record : records) {
    process(record);
    nextOffsets.put(
        new TopicPartition(record.topic(), record.partition()),
        new OffsetAndMetadata(record.offset() + 1L)
    );
}

consumer.commitSync(nextOffsets);

如果某条消息处理失败，不能继续提交它后面的 offset，否则失败消息可能被直接跳过。

异步提交时，调用 commitAsync() 不等于提交成功，必须检查回调异常：

consumer.commitAsync((offsets, exception) -> {
    if (exception != null) {
        log.error("Commit failed", exception);
    }
});

资料还将多个异步提交乱序完成造成位点回退列为常见坑。使用时应按实际客户端版本确认顺序保证，避免并发提交，并记录已经确认成功的进度。

CommitFailedException 往往与处理超时或成员变化连在一起。早期资料强调 session.timeout.ms，较新的资料更强调 max.poll.interval.ms：前者用于成员失联检测，后者限制两次 poll() 的间隔，不能混为一谈。具体默认值随客户端版本变化，应结合单批最坏耗时和 max.poll.records 核对，而不是照抄固定数值。

在 onPartitionsRevoked 中可以尝试提交已经确认处理成功的位点，但提交本身仍可能失败，不能把它当作绝对保证。 业务侧仍需增加幂等保护：订单号、消息 ID 可以使用数据库唯一索引，高吞吐场景可以考虑 Redis SETNX，已有处理状态的业务则适合使用状态机。

按两个现象验收：同一业务键被重放后不产生第二次业务副作用；日志顺序能够确认“业务成功在前、位点提交在后”，且提交回调没有异常。