kafka 的精准一次处理语义（eos）需生产者、broker 和消费者三方协同实现：幂等生产者（enable.idempotence=true）防重发；事务机制（transactional.id+两阶段提交）保障跨操作原子性；消费者设置 isolation.level=read_committed 实现只读已提交消息。
Kafka 的精准一次处理语义（Exactly-Once Semantics，EOS）不是靠单个配置开关实现的，而是生产者、Broker 和消费者三方协同作用的结果。Java 客户端要真正用好 EOS，关键在于理解三个层次的配合逻辑，并在代码中正确串联它们。
幂等生产者是基础：防重发不靠猜，靠序列号校验
启用幂等性是事务型写入的前提，它解决的是网络抖动或 Broker 响应延迟导致的重复发送问题。
- 必须设置 enable.idempotence=true，且不能手动配置
retries、max.in.flight.requests.per.connection（Kafka 会自动设为 1 和 Integer.MAX_VALUE） -
acks=all是强一致性保障的必要条件，确保消息写入所有 ISR 副本才返回成功 - 每个生产者实例会获得唯一 PID，每条消息携带
(PID, Topic, Partition, Sequence Number)元组，Broker 端缓存并比对序列号，重复批次直接丢弃但返回成功 ACK
事务机制是核心：跨操作原子性靠两阶段提交
单纯幂等只能保单分区不重，而事务把消息写入、数据库更新、位移提交等动作打包成一个原子单元。
- 需指定 transactional.id（如
"order-service-01"），用于标识事务归属和故障恢复时的僵尸检测 - 调用
initTransactions()初始化（仅需一次），再用beginTransaction()、commitTransaction()或abortTransaction()控制边界 - 事务日志存储在内部 Topic
__transaction_state中，由 Transaction Coordinator 统一管理状态，支持崩溃后恢复 - 注意：事务内不能混用非事务型 Producer；同一
transactional.id不可被多个实例并发使用
消费者隔离是闭环：只读已提交，避免脏读中间态
即使生产端做了事务，若消费者读到未提交的消息，仍会导致业务逻辑错乱。
- 消费者端必须设置 isolation.level=read_committed，否则默认
read_uncommitted会看到 ABORTED 或正在进行中的消息 - 事务消息在 Broker 端以 CONTROL RECORD（如 COMMIT/ABORT 标记）结尾，消费者跳过未提交事务的数据段
- 消费位移（offset）也可纳入事务——调用
producer.sendOffsetsToTransaction()将 offset 提交与消息写入绑定，实现“处理+位移”原子性
端到端 EOS 还需应用层配合：状态一致性不能全交给 Kafka
Kafka 保证的是“消息投递恰好一次”，但业务是否真正“处理恰好一次”，取决于你如何设计状态更新逻辑。
- 推荐采用外部存储的幂等写入，例如用订单 ID 作为数据库主键或 Redis key，先查后写，或用带版本号的乐观锁
- 避免在事务内做耗时操作（如远程 HTTP 调用），防止事务长时间挂起，影响 Coordinator 性能
- 异常处理必须明确：捕获业务异常后调用
abortTransaction()，同时记录日志便于人工对账
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
