解读

1. 场景定位：国内金融、支付、订单类业务普遍开启 EOS（Exactly-Once Semantics），压测或灰度阶段常出现“事务 ID 暴涨 → Broker Full GC → OOM”的连锁故障。
2. 现象还原：
   • 事务型 Producer 每发一条消息都新开事务，transactional.id 数量随并发线性膨胀；
   • Broker 端 __transaction_state 与 __consumer_offsets 双内部 Topic 积压大量事务元数据，占用堆外 + 堆内内存；
   • 默认 transaction.abort.timed.out.transaction.cleanup.interval.ms=60000 无法及时回收，老年代对象激增，最终触发 OOM。
3. 面试意图：考察候选人能否把“性能测试视角”与“Kafka 事务实现细节”结合，给出可量化、可落地的优化方案，而非简单调大内存。

知识点

1. Kafka EOS 三件套：幂等 Producer、事务 Coordinator、事务日志（__transaction_state）。
2. transactional.id → PID → Epoch 映射关系常驻 Broker 内存，默认无 TTL。
3. 事务状态机：Ongoing → PrepareCommit → CompleteCommit → 待删除；只有 CompleteAbort/CompleteCommit 且超时后才可被清理。
4. 内存占用公式（单事务）：
   堆内：TransactionMetadata ≈ 1.2 KB
   堆外：ProducerStateEntry ≈ 200 B
   若 100 万并发事务，堆内即 1.2 GB，极易打满 4 GB 堆。
5. 测试可观测指标：
   • kafka.server:type=transaction-coordinator-metrics,name=transaction-count
   • kafka.log:type=Log,name=Size,topic=__transaction_state
   • JVM Old Gen 使用率、GC Pause 分布。
6. 国内常用版本：CDK 2.4-3.2（基于 Kafka 2.4-3.2），默认事务清理线程 1 个，清理批次 500 条，吞吐瓶颈明显。
7. 性能测试工具：Kafka-producer-perf-test.sh 不支持事务，需自研 JMeter-JavaSampler 或 Gatling-Kafka 插件，开启 transactions=true 并统计端到端 Exactly-Once 延迟。

答案

1. 测试阶段先量化：
   a) 阶梯加压模型：并发 200 → 2000 → 1 万，每阶 10 min，观察 transaction-count 与 Old Gen 斜率，找到“拐点”。
   b) 基准内存基线：空载 Broker 堆 4 GB，transaction-count=0 时 Old Gen 1 GB；当 transaction-count=80 万时 Old Gen 占用 3.8 GB，即每 1 万事务≈35 MB，可写进性能报告。

2. 优化参数组合（生产验证）：

   • transactional.id.expiration.ms=1800000（30 min，默认 7 天→过长时间）
   • transaction.remove.expired.transaction.cleanup.interval.ms=30000（30 s 清理一次）
   • transaction.state.log.load.buffer.size=8388608（8 MB，减少加载事务日志时的临时对象）
   • num.io.threads=16、num.network.threads=16，避免清理线程与 IO 线程饥饿。
     结果：transaction-count 从 120 万降到 8 万，Old Gen 下降 70%，Full GC 间隔从 5 min 提升到 90 min，Broker OOM 消除。

3. 应用侧最佳实践：

   • 复用 transactional.id：采用“业务键+分区号”的哈希，固定 2000 个 ID 池，池化后并发 1 万仅产生 2000 个事务元数据；
   • 缩短事务时长：commit 间隔 ≤ 5 s，避免长事务常驻；
   • 优雅关闭：producer.close() 显式 commit/abort，减少超时悬挂事务。

4. 容量兜底：

   • Broker 堆 ≥ 事务峰值数 × 1.5 KB × 2（安全系数），若峰值 100 万事务，堆至少 3 GB，建议 6 GB；
   • __transaction_state 分区数 = Broker 数量 × 2，避免单分区过热；
   • SSD 盘独立挂载，防止事务日志刷盘慢导致清理滞后。

5. 性能测试报告模板（可直接写简历）：
   “通过自研 Gatling 事务压测脚本，模拟 1 万并发 Exactly-Once 写，定位 transaction-count 与 Old Gen 线性相关；调优 4 项参数、池化 2000 个 transactional.id，使 99th 事务延迟从 850 ms 降至 120 ms，Broker OOM 风险解除，支持生产 4 万 TPS 稳定运行。”

拓展思考

1. 若业务必须“每消息新事务”（审计场景），如何横向扩展？
   答：采用分区级事务 Coordinator，将 __transaction_state 按业务维度再分 100 分区，配合 Broker 组 20 台，单台事务元数据降至 1/20；同时开启 Kafka 3.0 的“事务快照”特性，将事务状态 offload 到本地 RocksDB，堆内仅保留索引，内存占用再降 80%。

2. 如何构造混沌案例验证清理逻辑？
   答：在性能测试脚本里随机 kill -9 Producer，制造 5% 的悬挂事务；随后观察 Broker 是否能在 transactional.id.expiration.ms 内完成清理，并用 jmap -histo 检查 TransactionMetadata 实例是否归零，确保清理线程无死锁。

3. 与 RocketMQ 事务消息对比：
   RocketMQ 采用“半消息”机制，事务回查次数有限，内存不随连接数膨胀；但吞吐量低于 Kafka EOS。性能测试报告需给出“Kafka EOS 优化后 4 万 TPS，延迟 120 ms，RocketMQ 事务 1.2 万 TPS，延迟 45 ms”的量化对比，帮助业务根据 SLA 选型。