面试必问的 Kafka 重复消费问题表面问的是配置项实际上考的是三件事你知不知道 Kafka 默认的投递语义你能不能说出重复消息从哪几个环节产生以及你有没有真正在消费端做过幂等处理。我面试候选人的时候很多人的反应是“把enable.auto.commit改成 false”但再追问一句“改完就不会重复吗”经常答不上来。这篇会从工程落地角度把重复消费的根源、参数调整、代码幂等、排查链路一次说清楚适合准备面试的人也适合生产环境里已经遇到重复消息的人。1. 面试官问 Kafka 如何避免重复消费真正想考什么1.1 先搞清楚 Kafka 的投递语义重复不是偶发 bugKafka 默认提供的不是“不重不漏”而是“至少一次”语义。所谓至少一次就是消息不会丢但可能重复。这个特性不是 Kafka 设计失误而是要保证不丢消息时必然面临“消费者处理完但 offset 还没提交”的窗口。常见的三种语义可以这样理解语义大致含义什么时候出现at-most-once最多一次可能丢先提交 offset再处理业务处理失败就丢了at-least-once至少一次可能重复先处理业务后提交 offset崩溃后重读exactly-once精确一次不重不漏需要额外机制配合单靠 Kafka 消费端不成立RabbitMQ、RocketMQ 也会有类似问题。RabbitMQ 在消费者处理超时或断线时会重新投递消息RocketMQ 在客户端收到消息但没返回消费成功的确认时也会重投。重复消费是消息系统里很常见的边界场景不是 Kafka 独有的毛病。很多人以为 Kafka 开启“幂等生产者”之后就不会重复了这是误解。幂等生产者解决的是 producer 到 broker 之间因为网络重试导致同一条消息被写入多次的问题。它管不到消费者处理逻辑和外部数据库写入。真要避免业务层面的重复必须在消费端想办法。1.2 面试回答能到什么层次一眼就能看出来我平时看候选人回答这类问题时基本会看三个层次。第一个层次是只答配置。知道把enable.auto.commit关掉改用手动提交。这个答案不能算错但太浅。因为手动提交只是把“什么时候提交”的控制权拿回来提交窗口依然存在消费者崩溃后依然可能从旧 offset 重新消费。第二个层次是答幂等。知道给消息加业务 key在消费端用数据库唯一约束、Redis 原子命令或者状态表去重。这个层次已经接近生产环境能用的方案。第三个层次是答边界。能说清楚 Kafka 的 exactly-once 到底覆盖哪一段为什么端到端精确一次很难实现以及在多线程、批量任务、Spring Boot、Flink 这类场景里幂等方案要怎么适配。面试官问“Kafka 如何避免重复消费”真正想听的不是某个固定的标准答案而是看你能不能把一个分布式系统里常见的重复问题用工程手段控制住。2. 先定位重复消费的来源不只是消费者重启那么简单2.1 自动提交 offset处理成功但提交前崩溃Kafka 消费者默认会开启自动提交也就是enable.auto.committrue每过一段时间自动提交当前拉取到的 offset。这个机制好处是代码简单代价是重复消费风险很高。流程大概是这样的消费者poll拉了一批消息开始处理业务。业务处理完毕还没来得及等到下一次自动提交服务突然崩溃或者被 kill。等进程重启之后Kafka 发现这个消费者组并没有把最新 offset 提交上去于是继续从上次提交的位置开始消费。那批已经处理完但没提交 offset 的消息就会被再次拉取。更麻烦的是自动提交不是处理完一条就提交一条而是按固定时间间隔批量提交。所以即使没有崩溃也有可能把一批还没处理完的消息的 offset 提前提交掉。如果处理失败又会变成丢消息。关闭自动提交不是为了避免重复而是为了把“提交时机”的控制权拿回来。2.2 消费者再均衡分区被转手新消费者从旧位置重读重复消费的第二个高发点是消费者组再均衡也就是 rebalance。一个消费组里多个消费者实例会分摊分区。当某个消费者加入、离开、崩溃或者分区数量变化组协调器会触发 rebalance把一些分区重新分配。问题在于rebalance 发生时原消费者还没来得及提交 offset。如果它已经把消息处理完成但 offset 停在旧位置新接手的消费者就会把这些分区重新消费一遍。触发 rebalance 的原因很多。最常见的是消费者处理时间太长超过了max.poll.interval.ms协调器认为这个消费者已经“假死”就把它移出消费组。还有心跳超时、网络抖动、GC 停顿等也可能导致消费者被判定为不健康。越频繁地 rebalance重复消费的概率就越高。因为每次分区交接都可能把一部分已处理但未提交的消息重新读出来。这也是为什么很多重复消费问题不是出现在正常重启而是出现在部署发版、实例扩容缩容的时候。2.3 生产端重试和事务机制上游重复不能指望下游感知重复消费不只是消费者自己的问题。producer 在发送消息时如果网络超时、broker 切换或者客户端没有收到确认就会重试。某些情况下消息其实已经写入了 broker只是 ack 丢了。producer 再次发送同一条消息就被写入了两次。开启 producer 的幂等功能也就是enable.idempotencetrue可以解决同一 producer 会话内因重试导致的重复。如果配上transactional.id还能做到跨会话去重。但这些都是 broker 层面的处理消息一旦落盘消费端看到的就是多条内容相同的消息。如果生产端把同一个业务事件发到了多个 partition或者同一业务 ID 对应多条不同 offset 的消息消费端拿到的本身就是重复业务数据。这种情况消费端很难只靠 Kafka 配置去判断必须在消息设计阶段就约定好业务幂等键。3. 最稳妥的兜底方案把消费者做成幂等3.1 给消息设置业务幂等键避免重复消费的根基是让每个业务事件在语义上有一个唯一标识。比如订单支付事件可以用支付流水号、订单号、或者支付平台返回的交易 ID。库存扣减事件可以用扣减单据号。如果是系统内部生成的通用事件最好显式生成一个 UUID 或 requestId 放到消息 key 里。不要在消费端用topic partition offset作为去重键。同一个业务事件在重试时可能因为 rebalance 换到另一个分区offset 也完全不同。只有业务幂等键才是稳定的。生产端在设置消息 key 时可以这样约定事件本身具备唯一编号时直接用业务编号。没有天然唯一编号时生成全局唯一 ID。需要兼容多个来源时用来源系统 业务 ID 组合。消费端拿到消息后第一件事不是立即处理而是拿这个业务幂等键去查“我是不是已经处理过”。这个过程就是幂等消费。3.2 数据库唯一约束适合强一致业务数据库唯一约束是最直观的幂等方案。用户下订单、扣减库存、入账这类场景通常需要把业务操作和消费记录写在一个事务里。表结构可以做成这样CREATE TABLE consumed_message ( biz_id VARCHAR(64) PRIMARY KEY, topic VARCHAR(64), partition_id INT, offset_id BIGINT, create_time DATETIME );消费伪代码大致如下String bizId record.key(); // 生产端约定的业务幂等键 // 尝试插入消费记录如果业务操作和插入在同一个事务里重复插入会失败 try { transactionTemplate.execute(status - { consumedMessageMapper.insert(bizId, topic, partition, offset); orderService.handle(record.value()); }); } catch (DuplicateKeyException e) { log.warn(重复消息已被其他事务处理bizId{}, bizId); }这里最容易踩的坑是顺序。如果先处理业务再插入消费记录业务操作成功但插入消费记录失败事务回滚两个都会重来。如果先插入消费记录再处理业务业务处理失败但事务回滚消费记录也跟着回滚不会误跳过消息。所以核心原则是“消费记录和业务副作用必须在同一个本地事务里”。如果业务操作涉及外部接口调用比如调第三方支付、发短信、写入另一个数据库就不能简单地放在本地事务里。你只能把外部调用设计成可重试、可补偿或者用本地消息表这类方案做最终一致性。数据库唯一约束本身只保证本地事务内不重复管不到外部系统的副作用。3.3 Redis 原子去重适合短时间窗口如果业务对重复的容忍窗口较短比如 5 分钟内重复的请求直接丢弃用 Redis 做去重更合适。Redis 里可以用一条原子命令完成检查和写入SET consumed:{bizId} 1 NX EX 86400NX表示只有 key 不存在时才设置EX表示过期时间。返回 OK说明当前消息是第一次处理返回空说明已经处理过。Java 伪代码可以这样理解Boolean first redisTemplate.opsForValue() .setIfAbsent(consumed:order: bizId, 1, Duration.ofDays(1)); if (!Boolean.TRUE.equals(first)) { log.warn(重复消息直接跳过); return; } try { bizService.process(message); } catch (Exception e) { // 处理失败要删掉 key否则这条消息永远不会被重试 redisTemplate.delete(consumed:order: bizId); throw e; }关键在于“处理失败要删除去重 key”。如果业务处理异常但 key 已经写进去了后面重试这条消息时会被当成重复消息跳过造成隐式丢消息。先 SETNX再处理失败后主动删除是比较稳妥的做法。Redis 去重的边界也很明显过期时间超过后相同业务消息还有可能再进来那就处理不了。对时间窗口要求特别严格的场景还是要落到数据库或者状态存储里。4. 通过 Kafka 配置和提交策略降低重复概率4.1 关闭自动提交手动控制提交时机没有一种配置能保证完全不重复但合理的提交策略可以把重复窗口缩小并且让重复行为变得可控。第一步就是关闭自动提交。enable.auto.commitfalse关掉自动提交后消费代码要自己在合适的时机提交 offset。简单场景下可以处理完一批再提交while (true) { ConsumerRecordsString, String records consumer.poll(Duration.ofMillis(1000)); for (ConsumerRecordString, String record : records) { handle(record); } try { consumer.commitSync(); } catch (CommitFailedException e) { // rebalance 会导致提交失败这里要记录日志不要吞掉 log.error(commit offset failed, e); } }这里有一个关键原则先确保业务处理完成再提交 offset。如果先提交再处理虽然消息不会重复但处理失败时消息会丢。如果先处理再提交消息不会丢但崩溃时可能重复。实际生产里“先处理后提交”配合“消费端幂等”是最常见的组合。它保证业务不丢重复了也能被下游拦截。而“先提交后处理”通常只被用在对丢消息容忍度极低的场景前提是你要接受消息可能丢失的后果。4.2 降低 rebalance 频率的参数怎么配很多重复消费问题是 rebalance 太频繁引起的。遇到这种情况先别急着改去重逻辑可以看几个参数参数作用调整建议session.timeout.msbroker 判断消费者是否存活处理慢可以适当调大但容灾时间也会变长heartbeat.interval.ms心跳发送频率一般取 session.timeout.ms 的三分之一左右max.poll.interval.ms两次 poll 之间的最大间隔业务处理耗时长要调大max.poll.records单次 poll 返回的最大消息数单条处理重时调小降低单批耗时enable.auto.commit是否自动提交 offset把重复窗口控制在手里建议手动提交比如消费者每批次要执行大批量计算单次 poll 拉 500 条可能跑半分钟加上 GC 或网络波动很容易超过max.poll.interval.ms。这种情况下有两种方向一是把max.poll.records调小让单批任务更快完成二是把max.poll.interval.ms调大让消费者有更充足的处理时间。但注意这些参数不是越大越好。把max.poll.interval.ms调得太大消费者实际上已经卡死但集群还要等很久才把它剔除故障转移会变慢。把session.timeout.ms调大也会让 broker 更晚发现消费者掉线。调参之前先看日志里 rebalance 的具体原因再决定动哪个参数。4.3 开 exactly-once真能一劳永逸吗Kafka 本身是有“精确一次”相关能力的但它的作用范围不是整个业务链路。producer 开enable.idempotencetrue配合transactional.id可以保证一条消息只写入一次。消费者设置isolation.levelread_committed只读取已提交的事务消息不会读到被 abort 的消息。但这些能力解决的是“Kafka 内部的消息不重复”不等于你消费后写入 MySQL、Redis、ES 只发生一次。真正要实现端到端精确一次需要把“消费消息并处理业务产生的外部写入”和“提交 offset”放在同一个原子操作里。比如 Kafka streams 可以把自己的状态存储和 offset 提交绑定起来Flink 可以通过 checkpoint 记录 source 的 offset再配合事务性 sink 输出。自己手写一个消费者去更新数据库很难做到严格意义上的端到端不重复。所以面试时如果被问到 exactly-once最好回答成Kafka 提供的精确一次是有边界的生产端到消费端只能保证流内一致业务外部系统的副作用还是需要幂等兜底。5. 复杂消费场景多线程、批量管道和 Spring Boot 集成5.1 单线程消费最稳多线程要自己管理 offset最不容易出错的 Kafka 消费者写法是一个线程循环 poll处理完一批再提交一批。KafkaConsumer 本身不是线程安全的多线程使用时要有额外设计。很多项目为了提高吞吐会在 poll 之后把消息丢进线程池处理。如果处理线程还没跑完主线程就提交了 offset一旦线程池里的业务失败消息就丢了。如果主线程不提交等所有线程处理完再提交某个线程卡住整个消费进度就会被拖住。这些都是真实环境里很常见的坑。我一般会建议单条消息处理耗时不长就保持单线程配合调大max.poll.records提升吞吐。如果必须多线程尽量按分区做隔离比如一个分区对应一个单线程队列避免同一个分区内部乱序。offset 提交也要改成“每个分区记录已经处理成功的最大 offset”提交最小已处理位置而不是无脑提交 poll 到的最后一跳。多线程本身不产生重复但它会把重复的判断复杂化。你没法简单地通过“处理完一批提交一次”来控制边界只能靠业务幂等键兜底。5.2 批量任务和 Flink 场景checkpoint 不代表下游不重复在 Kafka 生态里Flink、Spark 这类流处理框架也很常见。Flink 的 Kafka Consumer 会把 offset 保存进 checkpoint任务重启后从上次 checkpoint 恢复。这套机制能保证 Flink 内部状态的精确一次但不等于下游 MySQL、ES 的写入不重复。比如用 Flink 消费 Kafka 写入 Elasticsearch如果使用按业务 ID 生成的 doc id重复写入时 ES 会做覆盖更新问题不大。如果不带 doc id 而使用 create 语义重复事件到来时会保错或者生成重复文档。类似的写 MySQL 时最好用唯一键加 upsert而不是无脑 insert。批量任务也是一样虽然 Kafka 本身是实时流但很多团队会把它做成批处理按分钟或按小时统一拉取。批量任务最容易出的问题是先提交 offset再写结果到报表库报表库写入失败后offset 已经提交那批数据就丢了。反过来先写报表库再提交 offset任务重启又会把同一批数据重复写一遍。这时唯一靠谱的方式就是报表库侧做幂等比如按业务日期字段做唯一约束重复写入要么覆盖要么跳过。有些面试题会顺带问“Kafka 怎么实现延迟 30 分钟消费”。延迟消费解决的是时间问题不解决重复问题。你可以用延迟队列、时间轮、定时任务这些思路去做但被延迟的消息一旦到了消费端依然要按幂等逻辑处理。5.3 Spring Boot 集成 Kafka 时的常见配置和坑用 Spring Boot 接 Kafka很多人只看“能不能收到消息”不关心提交时机结果一上线就发现重启后重复消费一大堆。基础配置要注意几个点spring.kafka.bootstrap-serversnode1:9092,node2:9092 spring.kafka.consumer.group-idorder-consumer spring.kafka.consumer.enable-auto-commitfalse spring.kafka.consumer.auto-offset-resetearliest spring.kafka.consumer.properties.max.poll.interval.ms300000 spring.kafka.consumer.properties.max.poll.records200 spring.kafka.listener.ack-modemanual_immediateenable-auto-commitfalse是必须关的。ack-modemanual_immediate表示监听器手动提交并且收到 ack 后立刻提交。代码里可以在KafkaListener方法中显式调用 acknowledgeKafkaListener(topics order-event, groupId order-consumer) public void onMessage(ConsumerRecordString, String record, Acknowledgment ack) { try { process(record); ack.acknowledge(); } catch (Exception e) { // 不要直接吞异常记录日志等待重试或写入死信 log.error(消息处理失败, e); } }如果监听器抛异常Spring 默认情况下不提交 offset下一条 poll 会重新拉取这批消息。这就可能造成一批消息被反复处理。为了不让事务的一部分副作用重复执行还是得在 process 内部做幂等。多消费组也是常见坑。同一个业务如果被多个KafkaListener监听并且 group.id 相同那它们其实是在分摊同一个消费组的分区一条消息只会被其中一个 listener 消费。如果多个 listener 用不同 group.id每条消息会被每个 group 都消费一遍。这是多播不是重复消费但业务上如果没意识到很容易误判。如果对接 Canal 这类 binlog 同步工具消息里最好带上 binlog 文件名、position 或者业务主键作为幂等键不能只靠默认的自动提交。6. 如果还是重复给出一套排查链路和面试回答思路6.1 先判断是生产重复、消费重复还是下游写重复遇到重复消息第一件事不是改配置而是定位重复发生在哪一段。先在消费端日志里看同一条消息的 key。如果同一个业务 key 出现两条 Kafka record且 topic、partition、offset 不同说明上游重复投递可能是 producer 重试、事务重放、或者同步工具重复发送。如果两条日志的 offset 相同但消费逻辑执行了两次八成是消费端 offset 回退比如 rebalance 后从旧 offset 重新消费。然后可以看消费组的提交位置。用命令行工具kafka-consumer-groups.sh --bootstrap-server localhost:9092 \ --group order-consumer --describe关注 CURRENT-OFFSET、LOG-END-OFFSET、LAG 三列。如果 LAG 始终为 0但服务还是重复处理说明 offset 提交没问题重复来自更上游或者下游重试。如果 LAG 经常乱跳特别是重启后消费很多历史消息则要看 committed offset 是否稳定。也可以直接用 Offset Explorer 这类可视化工具连上集群检查某个 group 的 offset 变化。很多人用 Docker 搭本地 Kafka 时会遇到Error while fetching metadata with correlation id或者cluster authorization failed这种情况大概率是连接地址不通、容器内外的 host 映射不对或者 ACL 权限缺失不是重复消费本身。先把连接问题处理好再讨论重复。6.2 通用检查清单下面这个清单基本能覆盖重复消费的常见排查方向现象优先看什么处理思路重启后大量历史消息重放committed offset 是否提交成功查看消费组 offset确认 ack 模式和提交逻辑rebalance 频繁消费者日志里的 rebalance 原因调整 max.poll.interval.ms、max.poll.records、心跳参数处理失败导致批次重试监听器有没有丢异常记录失败日志让失败走重试或死信队列同一条业务被多个实例消费group.id 和分区分配是否合理确认是否误用多个 group或 producer 重复投递下游写入失败后重试重复数据库/ES 是否具备幂等能力增加唯一键、业务 ID、upsert 语义排查顺序也重要。我一般会按“生产端日志 - 消费端日志 - group offset - 下游幂等记录”这个顺序来。不要一上来就怀疑模型或代码很多时候输入格式、ack 模式、消息 key 已经决定了是否重复。6.3 面试回答怎么组织更稳如果面试官问你“Kafka 如何避免重复消费”可以按四步回答。先说结论Kafka 默认是至少一次语义重复消费无法靠单一配置杜绝核心思路是消费端幂等同时通过配置缩小重复窗口。再说来源消费者在业务处理完成但 offset 未提交时崩溃会从旧 offset 重读rebalance 导致分区交接时可能重复producer 重试也可能造成上游重复。然后给方案一是业务消息要带业务幂等键二是消费端用数据库唯一约束、Redis 原子命令或状态表做去重三是关闭自动提交处理好业务逻辑后再提交 offset四是调整会话、心跳、单批拉取条数参数降低 rebalance 频率。最后说边界如果你在面试中强调“开启 exactly-once 就不重复了”反而会显得不够深入。更稳的说法是producer 幂等和 read_committed 能解决 Kafka 内部一部分重复但端到端不重不漏还需要外部写入和 offset 提交具备原子性或者下游具备幂等能力。我常跟团队说的一句话是不要在配置文件里找一个“防重复按钮”那大概率不存在。消息队列的重复是常态真正可靠的防线是你给消息设计的业务幂等键以及消费端处理失败时还能安全重试的一套机制。把这两件事做扎实Kafka 重复消费这个问题基本就不会再让你的线上服务半夜告警了。
