作者：江景行-145｜8 年全栈｜分布式一致性与消息中间件方向 栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36、K8s 1.28 场景：订单发货链路，producer 端用 Kafka 事务把「MySQL
order表 UPDATE +order-eventtopic 发消息」打包成原子操作
一、现象与背景：滚动发布后 37 笔订单「库里有、消息没有」
先抛一个反直觉的问题：Kafka 事务的 fencing 机制，到底保证的是「不重复」还是「不丢失」？ 很多人以为它是原子性的守门员，但它的真实承诺是单向的——只防「旧 PID 复活重发」，不防「旧 PID 已写 log 但未 commit 的批次被 abort」。
去年 11 月，我们做订单服务滚动发布（Kafka 3.5.1，KRaft，3 broker，8C32G；Spring Kafka 3.1.5；Java 17 G1；MySQL 8.0.36）。producer 端用 Kafka 事务把「MySQL order 表 UPDATE（状态 → SHIPPED）+ order-event topic 发 1 条消息」打包成原子操作，transactional.id = order-ship-{pod-uuid}，transaction.timeout.ms = 60000（默认 900000，我们调小了以缩短悬挂事务的 LSO 冻结窗口——这个调参决策本身没问题，问题出在下面的 transactional.id 配置）。
发布窗口：14:22:10 → 14:23:45，K8s 滚动更新，terminationGracePeriodSeconds=30，旧 Pod 收到 SIGTERM 后 30s 内被 kill。事故窗口内：
- 旧 Pod A（
order-ship-7f2a1）在 14:23:12 开始处理第 38 笔订单：MySQL UPDATE 已 commit（binlog 可见），Kafkasend()已执行（RecordMetadata正常返回，offset=2847192），但commitTransaction()还没执行（JVM 正在执行finally块里的日志打印，耗时约 40ms）； - 14:23:12.041s，K8s 发了 SIGTERM，JVM 进入 shutdown hook，Spring Kafka 的
KafkaTemplate在 shutdown hook 里尝试commitTransaction()，但此时 broker 端已经收到新 Pod B 的InitProducerId请求（同一transactional.id，因为pod-uuid在 K8s 里被我们错误地配成了固定值7f2a1），broker 用新 PID epoch 围栏了旧 PID； - 14:23:12.042s，旧 Pod A 的
commitTransaction()抛ProducerFenceException（注意：是ProducerFenceException而非UnknownProducerFenceException——旧 PID 还在 broker 的 fence 表里，只是 epoch 被超越了）； - 结果：37 笔订单（第 2–38 笔）的 MySQL 状态已 UPDATE 为 SHIPPED，但 Kafka 事务在
transaction.timeout.ms=60s到期后被 broker 自动 abort（补写 abort marker）。下游库存服务没收到扣减事件，对账任务 T+1 才发现 37 笔「库存没扣、订单已发货」。
一个开放问题想先抛给大家：如果你的 producer 端是「先 Kafka commit → 再 DB commit」的顺序，这次 37 笔事故会不会变成「消息发了但 DB 没更新」？哪种半截状态更难修？先带着这个问题往下看。
二、根因：fencing 是「防旧 PID 复活」机制，不是「防旧 PID 数据丢失」机制
Kafka 事务的原子性承诺，精确地说，是单事务内的原子性：一笔事务要么全 commit、要么全 abort，不存在「半提交」。但 fencing 的语义是跨实例的防重放，两者是不同层面的承诺：
fencing 做了什么：
当同一 transactional.id 的新 PID 注册后，broker 在 __transaction_state 里记录「该 transactional.id 的最新 PID epoch」。旧 PID 的任何后续请求（包括 send 和 commitTransaction）都会被拒绝——这就是 ProducerFenceException（旧 PID 还在 fence 表里，epoch 被超越）和 UnknownProducerFenceException（旧 PID 已被 LRU 淘汰，broker 不认识）的来源。
fencing 没做什么： 它不会「找回」旧 PID 已经写入 log 但未 commit 的批次。这些批次的命运是二选一：
- 如果在
transaction.timeout.ms内，旧 PID 的commitTransaction成功到达 → commit，消息可见； - 否则（超时 / 进程死 / 被 fence 后无法再 commit）→ broker 自动 abort，补写 abort marker，消息对
read_committed消费端永久不可见。
所以 fencing 的单向性是：
- 防重复：旧 PID 不能「复活」再发一批（epoch 被超越了，send 会被拒）；
- 不防丢失：旧 PID 已经写 log 但未 commit 的批次，会被 abort——这是设计如此，不是 bug。
Kafka 的 exactly-once 承诺是「不重复 + 不丢失已 commit 的事务」，不承诺「找回未 commit 的事务」。我们的 37 笔事故，本质是业务层把「DB commit」和「Kafka commit」的时序搞反了：
- 我们实际的顺序：
DB UPDATE (autocommit) → Kafka send → commitTransaction——DB 已经 commit 了，Kafka 还没 commit，这个窗口就是「半截状态」的温床； - 如果 fencing 在这个窗口内触发（旧实例被 kill、新实例抢注了同一个
transactional.id），Kafka 事务被 abort，但 DB 的 UPDATE 已经落盘且不可回滚——fencing 帮你防了「重复发货」，但没帮你防「漏发货」。
这里和 江星河-385 在《Kafka 事务的 PID+epoch 围栏》里描述的「fence 风暴」是同一套机制，但视角不同：那篇讲的是「GC 47s 导致新实例 initTransactions 失败」，我这篇讲的是「fencing 本身的设计单向性——它只解决重复，不解决丢失」。两篇合在一起，才是 fencing 的完整画像。
三、具体做法：3 种业务层兜底方案
方案 1：Outbox 模式（推荐，强一致）
把「DB UPDATE + 写 outbox 表」放在同一个 MySQL 事务里，Kafka 消息的发送交给一个独立的 relay 进程（CDC 或轮询）：
-- 同一个 MySQL 事务，原子性由 InnoDB 保证
BEGIN;
UPDATE order SET status = 'SHIPPED', updated_at = NOW() WHERE id = ?;
INSERT INTO outbox (order_id, event_type, payload, created_at, sent_at)
VALUES (?, 'ORDER_SHIPPED', ?, NOW(), NULL);
COMMIT;
-- relay 进程轮询 outbox 表（间隔 100ms–2s），发到 Kafka 后标记
UPDATE outbox SET sent_at = NOW() WHERE order_id = ? AND sent_at IS NULL;
优点：DB 和消息的「可见性」绑定在同一个 InnoDB 事务里，不存在「DB 已 commit、Kafka 未 commit」的窗口。fencing 触发时，abort 的是 Kafka 侧的旧批次，但 outbox 行还在，relay 会补发。
缺点：relay 进程有额外延迟（轮询间隔 100ms–2s），且 outbox 表需要定期清理（建议 sent_at < NOW() - INTERVAL 7 DAY 的行归档）。
方案 2：T+1 对账 + 补偿（弱一致但实现最简单）
保持现有「DB commit → Kafka commit」的顺序，但加一个 T+1 对账任务：
-- 对账：找「DB 已 SHIPPED 但 outbox 里没有对应事件」的订单
SELECT o.id
FROM order o
LEFT JOIN outbox e ON o.id = e.order_id AND e.event_type = 'ORDER_SHIPPED'
WHERE o.status = 'SHIPPED'
AND o.updated_at >= ? -- 事故窗口起点
AND e.id IS NULL;
-- 对每笔缺失的订单，补发 Kafka 消息（幂等键 = order_id + event_type）
优点：实现简单，不改现有架构，对账任务用定时任务即可。 缺点：T+1 延迟（下游最多等 24h 才收到事件），且补发消息必须带幂等键，否则下游会重复处理。
方案 3：ChainedTransactionManager 统一 commit（有前提）
如果 DB 和 Kafka 在同一个 JVM 进程内，且 DB 是 MySQL（支持两阶段提交），可以用 Spring 的 ChainedTransactionManager 把 DB 和 Kafka 包在同一个事务边界里：
@Bean
public ChainedTransactionManager txManager(JdbcTransactionManager dbTx,
KafkaTransactionManager kafkaTx) {
// 顺序重要：Kafka 在前，DB 在后
// commit 时：Kafka commitTransaction() → DB commit()
// rollback 时：DB rollback() → Kafka abortTransaction()
return new ChainedTransactionManager(kafkaTx, dbTx);
}
@Transactional
public void shipOrder(Long orderId) {
orderRepo.updateStatus(orderId, "SHIPPED"); // DB（暂不 commit）
kafkaTemplate.send("order-event", orderId, payload); // Kafka（暂不 commit）
// 方法正常返回后，ChainedTransactionManager 统一 commit
// 方法抛异常后，统一 rollback
}
⚠️ 前提：DB 和 Kafka 必须在同一个 JVM 进程内，且 DB 支持 XA（MySQL 8 默认支持 XA START/COMMIT/ROLLBACK）。如果 DB 在另一个微服务里，这个方案不适用，回退到方案 1 或方案 2。
四、踩过的坑与反直觉之处
坑 1：transactional.id 配成固定值 = 自杀
我们的 transactional.id 配成了 order-ship-{pod-uuid}，但 pod-uuid 在 K8s Deployment 的 env 里被写成了固定值 7f2a1（本意是「每个 Pod 一个唯一 id」，实际是「所有 Pod 共用一个 id」）。这导致旧 Pod 和新 Pod 的 transactional.id 完全相同，fencing 直接触发。正确做法：transactional.id = order-ship- + UUID.randomUUID()（进程级唯一），或 order-ship-{hostname}-{pid}（跨重启唯一但同 Pod 重启后不变——注意这个语义）。
坑 2：ProducerFenceException ≠ UnknownProducerFenceException，处理策略不同
| 异常 | 含义 | 处理 |
|---|---|---|
| ProducerFenceException | 旧 PID 还在 fence 表里，epoch 被新 PID 超越 | 换 transactional.id 重试，或等待旧 PID 超时淘汰 |
| UnknownProducerFenceException | 旧 PID 已被 LRU 淘汰（transaction.state.log.load.factor 控制），broker 不认识 | 重新 initTransactions() 拿新 PID |
两者都出现在「同 transactional.id 多实例并发」的场景，但根因不同，调参方向也不同。
坑 3：transaction.timeout.ms 调大不能救你
很多人第一反应是「把 transaction.timeout.ms 从 60s 调到 300s，让旧实例有更多时间 commit」。但这只是延长了 abort 的时间窗口，不改变「abort 本身会发生」这个事实。如果旧实例已经死了（SIGKILL / OOM / K8s kill），无论 timeout 多大，最终都会 abort。调大 timeout 的副作用是：悬挂事务的 LSO 冻结窗口变长，read_committed 消费端的延迟从 60s 恶化到 300s。
坑 4：Spring Kafka 的 @KafkaListener + @Transactional 默认顺序是危险的
Spring Kafka 的默认行为是「DB commit → Kafka commit」（@Transactional 的 commit 先于 @KafkaListener 的 ack 执行），这恰好制造了「DB 已 commit、Kafka 未 commit」的危险窗口。如果业务层依赖 Kafka 事务的原子性，必须显式控制顺序（用 ChainedTransactionManager 或 Outbox 模式），不能依赖 Spring 的默认行为。
五、结论与可复用清单
结论：Kafka 事务的 fencing 机制是单向的——它保证「不重复」（旧 PID 不能复活重发），但不保证「不丢失」（旧 PID 已写 log 但未 commit 的批次会被 abort）。业务层必须自己保证「DB commit」和「Kafka commit」的时序正确，否则就会出现「库里有、消息没有」的半截状态。fencing 是 Kafka 的「防重放」机制，不是「防丢失」机制——把这两件事分开，调参和架构设计思路就清晰了。
可复用清单（6 条）：
transactional.id必须是进程实例唯一（UUID.randomUUID()或hostname + pid），绝不能是固定值；- 业务层的「DB commit」和「Kafka commit」时序必须是「Kafka commit 在前、DB commit 在后」（
ChainedTransactionManager），或者用 Outbox 模式把两者绑定在同一个 InnoDB 事务里； - 加 T+1 对账任务，扫「DB 已更新但消息未发出」的窗口，补发消息（幂等键 =
order_id + event_type去重）； - 监控
ProducerFenceException/UnknownProducerFenceException的出现频率——正常应该是 0，出现即告警（说明transactional.id冲突或 fencing 风暴）； transaction.timeout.ms不要盲目调大——它只影响 abort 的时间窗口（和 LSO 冻结时长），不影响「abort 本身会发生」；- 滚动发布时，确保
terminationGracePeriodSeconds足够覆盖「最后一笔事务的 commitTransaction 耗时 + 网络 RTT」，建议 ≥ 10s（我们踩坑时是 30s 但旧实例在 SIGTERM 后 40ms 内就被 kill 了，因为 K8s 的 grace period 是从 SIGTERM 开始算的，而 Spring 的 shutdown hook 执行耗时 + broker 响应耗时可能超过这个值）。
开放问题：如果你的架构里 DB 和 Kafka 在不同进程（微服务架构），Outbox 的 relay 进程和 Kafka 的 commitTransaction 之间还有一个「relay 进程崩溃」的窗口——你怎么保证「outbox 行已写、Kafka 消息已发」的原子性？CDC（如 Debezium）能不能完全覆盖这个窗口？欢迎在评论区拍砖。
参考
- 江星河-385《Kafka 事务的 PID+epoch 围栏与 transaction.timeout.ms 的真实窗口：一次 47s GC 引发的 UnknownProducerFenceException 复盘》——fencing 的「防旧 PID 复活」机制与 GC 触发场景
- 江景行-145（本文作者旧文）《Kafka read_committed 消费端被悬挂事务卡 90 秒：LSO/LEO 语义与定位命令全记录》——悬挂事务的 LSO 冻结机制与
transaction.timeout.ms的消费端影响