3. Kafka 事务原理：事务 ID、事务协调器、事务日志与原子写入机制
Kafka 事务机制是构建端到端精确一次语义（EOS）的基石。它通过引入事务 ID、事务协调器、事务日志以及原子写入协议，确保跨分区、跨主题的多条消息要么全部成功提交，要么全部回滚，从而在分布式流处理中实现“恰好一次”的语义保障。
3.1 核心概念：事务 ID 与事务状态
每个 Kafka 事务由一个全局唯一的 TransactionalId 标识。生产者通过 initTransactions() 向事务协调器注册该 ID，协调器会维护该事务的完整生命周期状态机。
| 状态 | 说明 | 触发动作 |
|---|---|---|
| Empty | 事务尚未开始，或已完成提交/回滚 | 初始化完成 |
| Ongoing | 事务正在进行中，生产者正在发送消息 | beginTransaction() |
| PrepareCommit | 协调器收到提交请求，准备提交 | commitTransaction() |
| PrepareAbort | 协调器收到回滚请求，准备中止 | abortTransaction() |
| CompleteCommit | 事务已提交，写入完成 | 提交日志写入成功 |
| CompleteAbort | 事务已回滚，所有写入被丢弃 | 回滚日志写入成功 |
关键设计：TransactionalId 与生产者 PID（Producer ID）绑定。即使生产者崩溃重启，协调器仍能通过 TransactionalId 识别旧事务，并强制中止未完成的事务，防止僵尸生产者污染数据。
3.2 事务协调器：事务的“大脑”
事务协调器是 Kafka Broker 上的一个逻辑角色，负责接收事务请求、管理事务状态、写入事务日志，并与目标分区 Leader 交互完成原子提交。每个 TransactionalId 通过哈希算法映射到特定的协调器 Broker。
3.3 事务日志：__transaction_state 主题
事务日志是一个名为 __transaction_state 的内部主题，默认 50 个分区，每个分区存储不同 TransactionalId 的事务状态记录。协调器将事务的每个状态变更（如 Ongoing → PrepareCommit）以追加写的方式持久化到该日志中，确保事务状态不丢失。
日志记录格式：
key: TransactionalId
value: {
"transactionalId": "txn-001",
"producerId": 1001,
"producerEpoch": 0,
"transactionStatus": "Ongoing",
"partitions": ["topic-a:0", "topic-b:1"],
"lastUpdateTimestampMs": 1699000000000
}3.4 原子写入机制：两阶段提交协议
Kafka 事务的原子写入基于两阶段提交（2PC）的变体实现，但避免了传统 2PC 的阻塞问题。整个过程分为三个阶段：
- 数据写入阶段：生产者将消息发送到目标分区，消息携带 PID 和事务序列号（Sequence Number），但此时消息对消费者不可见（标记为未提交）。
- 预提交阶段：生产者调用
commitTransaction()，协调器将事务状态更新为PrepareCommit并写入事务日志。协调器向所有参与分区发送提交标记（Commit Marker），该标记是一条特殊的控制消息。 - 完成阶段：分区 Leader 收到提交标记后，将事务内的消息标记为已提交，并回复协调器。协调器将事务状态更新为
CompleteCommit，事务结束。
3.5 事务边界与消费者隔离级别
Kafka 事务的原子写入对消费者透明。消费者通过设置 isolation.level 参数控制可见性：
| 隔离级别 | 行为 | 适用场景 |
|---|---|---|
| read_uncommitted | 消费者可以看到所有消息，包括未提交的事务消息 | 非事务场景、实时监控、允许脏读 |
| read_committed | 消费者只能看到已提交的事务消息，未提交消息被过滤 | 金融交易、订单处理、需要精确一次语义 |
性能注意事项：read_committed 模式下，消费者需要等待事务提交标记或中止标记才能返回数据。如果事务长时间未完成（如生产者崩溃），消费者会阻塞等待，直到事务超时（transaction.timeout.ms，默认 60 秒）。建议合理设置超时时间，避免消费者堆积。
3.6 事务与幂等生产者的协同
Kafka 事务机制依赖底层的幂等生产者。每个生产者实例在初始化时获得一个唯一的 Producer ID (PID) 和 Epoch。幂等生产者通过序列号去重，确保同一事务内的消息不会因重试而重复写入。事务机制在此基础上增加了跨分区原子性保障。
生产者初始化代码示例：
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("transactional.id", "my-transactional-id");
props.put("enable.idempotence", "true"); // 必须开启
KafkaProducer<String, String> producer = new KafkaProducer<>(props);
producer.initTransactions();
try {
producer.beginTransaction();
producer.send(new ProducerRecord<>("topic-a", "key1", "value1"));
producer.send(new ProducerRecord<>("topic-b", "key2", "value2"));
producer.commitTransaction();
} catch (Exception e) {
producer.abortTransaction();
}3.7 事务性能调优要点
- 事务超时设置：
transaction.timeout.ms控制事务最大持续时间。过短会导致频繁超时回滚，过长会阻塞消费者。建议根据业务处理耗时设置为 30-120 秒。 - 事务日志分区数：默认 50 个分区，可根据事务并发量调整。每个协调器负责一部分分区，增加分区数可提升事务处理吞吐。
- 批量提交：将多个
send()操作放在一个事务中，减少事务提交次数，降低协调器负载。 - 避免大事务：单个事务包含过多分区（超过 1000 个）会导致协调器内存压力增大，提交延迟上升。建议将大事务拆分为多个小事务。