考察点
这题考的是 Kafka 0.11 之后引入的 Exactly-Once 语义，面试官想分清两件事你懂不懂：幂等和事务解决的是不同层面的问题，幂等管"重试别写重"，事务管"一批写要么全成要么全败"。追问方向：PID 和序列号的机制、Producer 重启后幂等为什么失效、事务的两阶段提交流程、性能代价。
参考答案
问题从哪来：重试导致的重复
Producer 发消息给 Broker，Broker 写入成功但响应在网络中丢失，Producer 超时重试，同一条消息就被写了两遍。这是消息系统里"至少一次"语义的根源——发送方无法区分"没收到"和"收到了但 ACK 丢了"。
应用层自己做去重（每条消息带业务唯一 ID，消费端查库判重）当然可行，但成本高。Kafka 选择在协议层解决，出了两个东西：幂等生产者（Idempotent Producer）和事务（Transactions）。注意它们都只解决"写入 Kafka 这一侧"的问题，消费端的重复要靠位移管理解决，这是面试里常被故意混淆的点。
幂等生产者：PID + 序列号
开启方式就一个参数：enable.idempotence=true（3.x 之后默认开启）。要求 acks=all、retries 大于 0、max.in.flight.requests.per.connection 不超过 5，不满足会直接报错。
实现机制：Producer 初始化时向 Broker 申请一个 PID（Producer ID），对每条发往 <Topic, Partition> 的消息维护一个单调递增的序列号。Broker 端按 <PID, Topic, Partition> 维度记录最近收到的序列号，新消息的序列号如果不是"已见最大值+1"，就判定为重复或乱序：重复的直接丢弃但返回成功（让 Producer 以为发成功了），乱序的抛 OutOfOrderSequence 异常。
序列号在内存里存最近几个 batch 的信息，落盘部分持久化到日志里。去重粒度是"单个 Producer 会话内的单个分区"，这就是幂等的两个边界：
- Producer 重启后 PID 变了，重启前发过的消息重启后再发，Broker 认不出来，照样重复。所以幂等不等于跨会话的 Exactly-Once。
- 只保单个分区，跨分区没有原子性。
理解了这两个边界，事务的存在意义就自然浮现了。
事务：跨分区的原子写
事务解决两类问题：一是 Producer 要向多个分区/主题写一批消息，要么全成功要么全失败；二是流处理里 consume-transform-produce 链路中，"消费位移"和"处理结果"要原子提交（这是端到端 Exactly-Once 的关键，Kafka Streams 就建立在这上面）。
用法：Producer 配置 transactional.id（业务自己定，比如机器名+任务 ID），调用 initTransactions()、beginTransaction()、send()、commitTransaction() / abortTransaction()。transactional.id 和 PID 有映射关系，同一个 transactional.id 的新实例启动时会" Fencing "掉旧实例（epoch 递增），防止僵尸 Producer 脑裂双写。
底层流程是两阶段提交的变体：
- Producer 先找 Transaction Coordinator（Broker 侧组件，状态存在内部主题
__transaction_state）注册事务。 - 事务期间，消息正常写入各分区，但标记为"未提交"。
- 提交时，Coordinator 先往
__transaction_state写 PREPARE_COMMIT，然后往事务涉及的每个分区日志写一条控制消息（Control Batch，COMMIT 或 ABORT 标记），最后更新状态为 COMMITTED。
Consumer 侧配 isolation.level=read_committed 时，只读已提交的消息，未提交和被中止的消息被过滤掉（Broker 端返回时会带上中止事务的索引信息）；默认 read_uncommitted 则全都能看到。整个流程里 Coordinator 宕机不碍事，状态在 __transaction_state 里，新 Coordinator 接手恢复。
代价和选型建议
幂等几乎没有额外开销（少量内存和带宽），生产环境没理由不开。事务有实打实的开销：每个事务多出几条控制消息和 Coordinator 往返，吞吐会掉，事务越大摊得越薄，所以流处理里常用加大 commit.interval.ms 的方式摊薄成本。普通"只往 Kafka 写日志"的场景不需要事务，它主要是给流处理和跨分区写准备的。
可能的追问
- 幂等开了之后，Kafka 就能保证端到端不重复了吗？ 不能。幂等只管生产侧单分区单会话，消费侧 offset 提交和处理之间的窗口仍会造成重复消费，端到端 Exactly-Once 需要事务 + 消费位移原子提交，或者业务层做幂等。
- Broker 重启后序列号状态丢了怎么办？ 序列号状态随日志持久化，Broker 重启从日志恢复；真正会重置的是 Producer 重启换 PID，这正是幂等只管单会话的原因。
- 事务消息在 read_committed 下延迟会变高吗？ 会有一点：消费位点被事务的 LSO（Last Stable Offset）卡住，长事务会挡住后续消息被读到，所以事务不宜开太久不提交。