Kafka 幂等 Producer 和事务 Producer 有什么区别？
面试怎么回答
幂等 Producer 通过 Producer ID 和分区序列号，避免发送重试导致同一记录在单分区重复写入；事务 Producer 则把多条、多分区或多 Topic 写入，以及消费 Offset 的提交，放进同一个原子边界。事务依赖幂等，消费者通常要用 read_committed 才能屏蔽中止事务。两者都不能自动把外部数据库纳入 Kafka 事务，端到端一致性仍需单独设计。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
enable.idempotence=true 已经能避免重试写出重复消息，为什么 Kafka 还要提供事务 Producer？
因为两者解决的原子性范围不同：幂等关注单个分区内的重复写入，事务关注一组写入是否整体提交。
把这两个概念混在一起，最容易得出一个错误结论：开启幂等，就已经实现端到端 Exactly-Once。
幂等 Producer 解决什么？
网络超时后，Producer 不确定 Broker 是否已经写入，于是会重试。如果没有幂等机制，同一条消息可能被追加两次。
启用幂等后，Kafka 利用 Producer ID 和分区内序列号识别重复请求，从而避免因为 Producer 重试产生重复记录。
它的边界要说清楚：
- 主要针对 Producer 到 Kafka 的重试重复
- 保证作用在单个分区的有序写入序列上
- 不会自动把多分区、多 Topic 的一组消息变成原子操作
- 不会替你处理业务主动发送的两条内容相同的消息
事务 Producer 解决什么？
事务允许一组 Kafka 写入一起提交或一起中止。
例如消费 Topic A，处理后写入 Topic B 和 Topic C，同时提交本批消费 Offset。使用事务后，这些 Kafka 内部操作可以放进同一个原子边界：
beginTransaction
send(B)
send(C)
sendOffsetsToTransaction(...)
commitTransaction / abortTransaction配置 transactional.id 后，Producer 才能使用事务；事务能力依赖幂等写入。下游消费者通常还要设置 isolation.level=read_committed，才不会读到已中止事务中的记录。
怎么选择？
只担心 Producer 重试重复
使用幂等 Producer，目标是让一条记录重试后仍只写入一次。
多条 Kafka 写入必须同成同败
使用事务 Producer，给多分区、多 Topic 或“结果消息 + Offset”建立原子提交边界。
还涉及外部数据库
Kafka 事务不能天然覆盖 MySQL、Redis 或第三方接口。跨系统一致性仍要通过幂等键、Outbox、CDC、补偿或其他一致性方案设计。
常见误区
误区一：有幂等就不会重复消费
幂等 Producer 控制的是写入端重试，不会阻止消费者在故障恢复后重复处理。
误区二：事务开启后所有消费者都看不到中止数据
消费者是否过滤中止事务记录，取决于它的隔离级别。
误区三：设置 transactional.id 就结束了
还要正确管理事务生命周期、实例唯一标识、超时、异常中止和故障恢复；乱用相同 transactional.id 还可能触发旧 Producer 被隔离。