面经策

说一下 Kafka 中关于事务消息的实现？ ​

  • 标签：Kafka、消息队列、后端

🏛 业务架构师 ​

Kafka 的事务是围绕"跨分区原子写 + 消费转换产出（consume-process-produce）"构建的，我按业务链路讲：

  1. 生产者找事务协调器：按 transactional.id 哈希定位，获取 pid 和 epoch（防僵尸生产者，同一逻辑生产者旧实例的请求会被拒绝——业务含义：服务重启不会双写）；
  2. 幂等基础：enable.idempotence，broker 按 <pid, 分区, 序号> 去重，单分区不再重复；
  3. 发送与标记：addPartitionsToTransaction 把输入分区和输出分区注册进事务，消息正常发送但对外不可见；
  4. 两阶段提交：prepare 阶段把 PREPARE_COMMIT 写入事务日志；再向各分区写 COMMIT 标记，消费端 read_committed 只能看到提交后的消息。

业务价值集中在流处理场景：实时数仓里"消费订单流→计算→写结果 topic"的 exactly-once，避免了以前"至少一次 + 下游去重"的双重建设。精准营销、实时大屏这类容不得重复扣减或重复计数的链路直接受益。

但我的提醒很实际：事务有性能开销（协调器交互、标记写入），跨系统的一致性它不管——Kafka 事务不覆盖"Kafka 写成功 + MySQL 写成功"这种业务最常见的跨资源场景。要理解它是"Kafka 内部的事务"，别把它当成分布式事务方案来用。

🏗 系统架构师 ​

Kafka 的事务是跨会话、跨分区的原子写 + 消费-转换-生产（EOS）语义，我按机制讲：

核心组件：

  • 每个生产者启动时从事务协调器（TransactionCoordinator）领取全局唯一的 transactional.id 和 producer epoch（防僵尸生产者，epoch 旧的请求直接拒绝）；
  • initTransactions 注册；beginTransaction 后正常发送，消息带上事务标记；commitTransaction 时协调器把 PREPARE_COMMIT 写入内部 topic __transaction_state，然后向事务涉及的所有分区写 commit marker（控制消息），最后写 COMPLETE；
  • 消费端配 isolation.level=read_committed，broker 只暴露到最新 commit marker 的消息，未提交/中止的不可见。

边界要讲清：它保证的是"写入 Kafka 多分区的原子性 + 精确一次处理流"，不包括外部系统——消息落库和发 Kafka 无法用它做原子。跨外部系统的最终一致我靠本地消息表 + 对账。

性能代价：事务提交流程多几次往返，单条小事务吞吐可能下降数倍，我的经验是攒批提交（比如 100ms 或 1000 条一个事务），在时延和吞吐间取平衡。

💻 全栈开发专家 ​

Kafka 事务解决的是 consume-transform-produce 的 exactly-once（跨分区多条消息原子写入），不是数据库那种分布式事务。

生产端三件套：

java
props.put("enable.idempotence", true);              // 幂等，前提
props.put("transactional.id", "order-tx-1");        // 唯一，跨重启恢复用
producer.initTransactions();
producer.beginTransaction();
producer.send(recordA);   // 可跨多分区
producer.send(recordB);
// 消费位点也纳入事务（注意传入 consumer.groupMetadata()）
producer.sendOffsetsToTransaction(offsets, consumer.groupMetadata());
producer.commitTransaction();   // 或 abortTransaction()

机制：initTransactions() 向事务协调器（__transaction_state 里的 partition）注册并取 PID；epoch 递增让旧实例的请求被拒（僵尸防护）；提交/中止标记（control batch）写入分区，broker 端过滤未提交消息。

消费端：isolation.level=read_committed 才只读已提交消息，默认 read_uncommitted 会读到脏数据——这是最容易踩的坑。

边界要说清：事务只覆盖 Kafka 内部链路，消费者对下游（DB/ES）的副作用仍需幂等，跨系统还是本地消息表/最终一致。我把 Kafka 事务主要用于流式计算（Kafka Streams exactly-once），普通业务消息用幂等 + 重试就够了。