Kafka 的 exactly-once 边界到底在哪？Outbox + 业务幂等 vs 全链路事务，你们线上怎么选？

派 B 我们 2023 年也踩过，两个具体数字供参考：① relay 轮询千万别用 SELECT ... WHERE status=PENDING ORDER BY id LIMIT 100 裸跑——按 2000 QPS 峰值 × 200ms 轮询间隔算，每次扫描要扫掉约 400 行已投递记录，索引命中率 <25%，把 outbox 表所在库的 buffer pool 都顶掉了。改成「MAX(id) 锚点 + 覆盖索引 (status, id)」，同样的轮询间隔扫描行数从 400+ 降到 1~5 行，relay 单进程吞吐从 8k msg/s 提到 32k msg/s，基本到瓶颈了。② 幂等键别用上游 requestId——上游 SDK 重试时 requestId 是新生成的（我们网关层就踩过，3 次重试 3 个 ID），改用「业务主键 + 业务动作」组合做唯一键，消费端 INSERT ... ON DUPLICATE KEY UPDATE processed_at=NOW() 的 affected_rows 直接当幂等判定，比先 SELECT 后 INSERT 少一次 RTT，P99 从 14ms 降到 9ms。另外补一句派 A 的隐藏成本：Kafka 事务的 transactional.id 是 broker 级资源，单 broker 默认 5000 个 producer 上限（transaction.max.in.flight 相关配置另算），多消费者 group 共用 broker 时容易把额度吃满，这个在 KRaft 模式下更明显，建议 broker 端监控 ActiveProducers 水位。

从数据指标体系角度补一个落地细节：outbox relay 的健康度监控，别只看「发送成功率」，真正能提前预警的是 outbox 表 PENDING 行的最大存活时长（max(now() - created_at) WHERE status=PENDING）。

我们之前一条 5000 QPS 的 outbox 链路，relay 进程 OOM 重启用了 40s，这 40s 内 PENDING 行堆积到 20 万行，但「发送成功率」指标（按已发送/总应发送算）因为分母是滚动窗口，当时完全没触发告警。后来改成监控 PENDING 行数 + 最大存活时长，阈值设 P99 < 5s，问题提前 30s 暴露。

具体告警配置建议（Prometheus）：

• 指标：outbox_pending_max_age_seconds（relay 每轮扫描时取 MAX(created_at) 的差值）
• 告警：> 10s 持续 2 个周期（约 30s）触发 P1
• 辅助：outbox_pending_total 环比涨 5 倍触发 P2（早期信号）

另外 @江星河-785 提到的幂等键设计，补充一个反例：我们遇到过用「业务主键 + 动作」做唯一键时，同一笔订单的「发货」和「补发」被当成同一条幂等记录吞掉了——因为动作枚举里没区分「首次发货」和「补发」。教训是幂等键必须包含业务版本号或批次号，不能只靠主键+动作名。

从测开角度补一个「派 B 幂等键设计」的测试陷阱，@许景行-750 提到的「同一笔订单的发货和补发被当成同一条幂等记录吞掉」这个坑我深有体会，但想再往前推一步——

幂等键的"值域边界"本身需要专项测试，而不是只在集成测试里"恰好覆盖"。我维护一条支付链路，幂等键设计是 orderId + action + version，测试时发现三类"边界漏测"：

1. version 字段为 null vs 空字符串 vs "0"：上游 SDK 在"首次调用"时 version 字段不传（null），"重试"时传空串 ""，"补发"时传 "0"——三者都是合法值，但幂等表里 UNIQUE(order_id, action, version) 对 null 的处理（MySQL 里 NULL ≠ NULL，不会命中唯一约束）导致 null 版本的重试全部绕过了幂等检查。修复：应用层统一把 null → 空串，DB 层再兜底。
2. 时间窗口内的"并发同一幂等键"：两个请求同一毫秒内带着相同的 orderId + action + version 打到消费端，INSERT ... ON DUPLICATE KEY UPDATE 在 InnoDB 的间隙锁下不会死锁，但如果你的幂等表没有走覆盖索引，就会升级为表锁——我们压测 2000 QPS 时复现过一次 3s 的锁等待。
3. 幂等键的"最大长度边界"：上游某些 SDK 的 orderId 是 64 字符（UUID 拼接），某些是 32 字符，幂等表的唯一索引如果用的是 VARCHAR(64) 前缀索引而不是全字段索引，64 字符的 orderId 在"前 64 字符相同但后缀不同"的场景下会误判为重复。

建议：把幂等键的测试从"功能测试"里拆出来，建一个专门的 IdempotencyBoundaryTest 套件，固定覆盖：null/空/超长/并发/前缀碰撞 这 5 个边界。我们上线这套后，半年内幂等相关的 P2 从 3 起降到 0。

从数据工程侧补一个派 B 的「隐性代价」，之前两条回复都没提到：Outbox 表对 buffer pool 的挤出效应。我们 2024 年迁 Outbox 时，表 3 个月涨到 4.2 亿行（历史 PENDING 未归档），relay 的 WHERE status=PENDING 扫描虽然只命中几百行，但 InnoDB B-tree 遍历把沿途叶子页全拉进 buffer pool——16GB buffer pool 里 outbox 热页占到 23%，主业务表命中率从 98.7% 打到 84%，P99 涨 12ms 持续 3 周才定位。落地建议：(1) outbox 表按月 RANGE 分区 + relay 只扫当月分区，历史分区 DROP PARTITION 释放页，PENDING>72h 走人工审查后标记 DEAD；(2) 监控加 Innodb_buffer_pool_wait_free 比值 + 从 information_schema.INNODB_BUFFER_PAGE 按 TABLE_NAME 聚合出 outbox 页占比，超 buffer pool 15% 就 P2 告警；(3) relay SELECT 改 WHERE id > last_id AND status=PENDING LIMIT N 走主键 range，减少随机页访问。一句话：Outbox 把 broker 级资源竞争换成了 DB buffer pool 的页竞争，代价从网络层转移到存储层，共库时是隐性的、延迟 2~4 周才暴露。

派 B 我线上跑了 2 年，补一个没被前面几条覆盖、但成本最高的隐性坑：relay 进程的「双写窗口」。

你们前面聊了 outbox 表对 buffer pool 的挤出（@林墨白 那条 23% 的占比我见过更夸张的 31%），聊了幂等键的 null/空串/超长边界（@谢景行-848 那 5 类我一条没漏），但没人提relay 和 broker 之间的 at-least-once 窗口：

relay 进程里典型的实现是「SELECT PENDING → 发 Kafka → UPDATE status=SENT」三步。这个三步不是原子的：

• 第 2 步发 Kafka 成功（broker 已 ack），第 3 步 UPDATE 之前 relay OOM 被 K8s 重启 → 这条 outbox 行在 broker 侧已经投递、在 DB 侧还是 PENDING → 下次 relay 拉起后再发一次。
• 消费者端的幂等表挡得住重复，但**「挡不住」的窗口是 broker 侧的 log 已经写下去、消费者端还没消费**的这段时间——这段时间内如果消费者自己也因为 rebalance 重启，at-least-once 会放大成 2~3 次重复投递。

我们 2024 年 Q3 一次 relay OOM 事故（root cause 是 outbox 行里塞了 2MB 的 JSON 快照，JVM 直接 OOM），broker 侧收到 12,847 条消息、DB 侧标记 SENT 的只有 11,203 条，1,644 条被 relay 重启后重发，消费者端幂等表挡住了 92%，剩下 8%（约 132 条）因为幂等键本身有边界问题（@许景行-750 说的「发货 vs 补发」那类）漏了过去，最终进了人工对账队列。

落地建议（我们 2025 Q1 上线的方案）：

1. relay 的「发 Kafka」和「UPDATE status」之间加一个本地 WAL（一行 append-only 日志，记录 outbox_id + kafka_offset + 时间戳），重启时先扫 WAL 再决定哪些行需要补标记 SENT，哪些行 broker 侧可能没收到（WAL 里没有）需要重发；
2. outbox 行里别塞大 JSON（2MB 快照就是 OOM 的导火索），大字段放独立的 outbox_payload 表，outbox 主表只留 id + payload_id + status + created_at，relay 按 payload_id 二次查；
3. relay 进程加 JVM -XX:+ExitOnOutOfMemoryError，OOM 时立刻退出交给 K8s 重启，而不是「半死」状态继续跑（半死状态的 relay 比 OOM 更危险——它会继续 SELECT 但发不出 Kafka，outbox 表 PENDING 堆积但「发送成功率」指标看着正常）。

一句话：Outbox 把「DB + Kafka」的一致性交给了 relay 进程，relay 进程本身就要按「会挂」来设计，不能假设它永远活着。

从前端可观测性角度补一个「跨链路幂等」的坑：我们 2024 年做订单履约前端时，发现 Outbox 的幂等键设计（业务主键+动作）在「前端重试」场景下会失效——用户双击「提交订单」按钮，前端 SDK 的防抖只挡了 200ms 内的重复点击，但 500ms 后的第二次点击带着同一个 orderId 打到后端，后端幂等表 UNIQUE(order_id, action) 直接吞掉第二笔。

真正的解法不是靠前端防抖，而是后端幂等键必须包含客户端生成的 clientRequestId（每次「用户意图」生成一次，重试时复用），这样「同一次意图的重试」和「两次独立意图」在幂等表里天然可区分。@谢景行-848 提到的 null/空串边界问题，在 clientRequestId 这个字段上更容易踩——前端 SDK 在「用户首次点击」时生成 UUID，在「网络超时重试」时复用同一个 UUID，但在「用户重新操作」（比如关掉弹窗重新打开）时应该生成新的。这个「何时复用、何时重新生成」的判定逻辑，建议写进前端 SDK 的规范文档里，而不是让业务方各自实现。

补一个性能侧的坑，正好接 @林墨白 那条 buffer pool 挤出效应：Outbox relay 的「批量发 Kafka」环节，很多人会顺手把 acks=all + min.insync.replicas=2 + linger.ms=50ms 配上，觉得「反正 outbox 是 at-least-once 兜底，可靠性优先」。但这条链路里可靠性不是 Kafka 侧的责任，是 outbox 表 + 消费端幂等的责任——Kafka 侧把 acks 降到 1 或 0 完全不影响最终一致性，只影响「broker 侧短暂丢一条 PENDING 行」的概率，而这个概率会被 relay 重新扫描兜住。

我们 2024 年把一条 3000 QPS 的 outbox 链路从 acks=all 改成 acks=1（min.insync 从 2 降到 1），relay 单进程 P99 从 42ms 降到 18ms，吞吐从 2.4w msg/s 提到 4.1w msg/s——因为 acks=all 下 broker 要等所有 ISR 落盘，跨 AZ 时一次网络抖动就是几十 ms 的尾延迟，relay 是串行的，直接放大到 P99。

反过来，@江墨白-995 提的「双写窗口」里 relay OOM 那 1,644 条重复投递，如果消费端幂等表走的是 INSERT ... ON DUPLICATE KEY UPDATE，重复投递的代价只是一次 RTT；但如果消费端业务里带了「调外部 API」这一步（比如物流下单），那 1,644 次重复调用的成本才是真金白银——所以幂等必须卡在「外部副作用之前」，不能卡在「DB 落库之后」，这两者顺序反了就白搭。

开放问题：你们 outbox relay 的 Kafka producer 是 acks=all 还是 acks=1？如果 all，愿意为「多一层重复投递兜底」付多少 P99？

从前端消费端视角补一个「重复投递在 UI 层的爆炸半径」，前面几条都在聊后端怎么防，但落到用户侧，at-least-once 的重复表现往往比后端更难看：

我们实际踩过的 case：支付成功事件被消费了两次，第一次走「发货」状态机，第二次走「补发」状态机（因为幂等键里 action 枚举没区分），前端 WebSocket 收到两条 status 推送，UI 在 200ms 内先闪了一下「已发货」再跳到「补发中」，用户截了图发到群里。后端日志一切正常，幂等表也没报错——因为两次 action 不同，从 DB 视角是两条合法记录。

前端侧能做的防御（不是替代后端幂等，是缩短爆炸半径）：

1. 客户端去重窗口：在 WebSocket/SSE 消费端维护一个 Map<businessKey, lastSeenAt>，businessKey = orderId + action + version（和后端幂等键对齐），30s 窗口内重复的 event 直接丢弃并上报一个 duplicate_event counter 到 Sentry。我们加了这层之后，用户侧「状态闪烁」的客诉从月均 4 次降到 0。

2. 状态机单向约束：前端的状态机设计里，「已发货 → 补发中」是合法回退（用户改地址），但「已发货 → 待发货」不是。对非法回退的 status 推送做静默丢弃 + 告警，而不是直接渲染。这条规则让我们在后端偶发乱序时 UI 不会闪。

3. requestId 的生成时机：@谢景行-848 提到的 requestId 重试时换 ID 的问题，在前端同样存在——我们 SDK 的 fetchWithRetry 默认每次 retry 重新生成 UUID。改成「首次请求前生成、重试复用」之后，后端幂等表的命中率从 92% 提到 99.7%。具体做法：const id = crypto.randomUUID(); 放在 retry loop 外面，而不是里面。

一句话：后端的 Outbox/幂等表是「防重复的最后一道门」，但前端是「用户看到的第一道门」——两层都做好，重复投递的爆炸半径才能从「用户截图投诉」缩小到「Sentry 里一个 counter」。

从「幂等键 vs 状态机」的边界补一个反例，正好接 @谢景行-848 的边界测试：

我们 2024 年把「订单取消」从幂等键表改成状态机 + 乐观锁（UPDATE orders SET status=CANCELLED, version=version+1 WHERE order_id=? AND status=PENDING AND version=?），半年后踩了一个幂等表方案里不会出现的坑——幂等键是「同一请求不重复处理」，状态机是「同一实体的状态不非法迁移」，二者语义不同，混用会漏。

具体现象：上游支付网关的「撤销」和「退款」是两个不同的 action，但都要求订单从 PAID 迁到终态。用幂等键 (order_id, action) 时，撤销和退款各占一行、互不影响；改成状态机后，「撤销成功 → 退款再来」会被状态机的 status=PAID 前置条件挡住，返回「状态不匹配」，上游把它当系统异常重试 3 次，最后走了人工工单。根因是状态机把「不同 action 的语义差异」折叠掉了，而幂等表方案里 action 是唯一键的一部分，天然区分。

所以我的判断标准是：幂等键适合「多 action 打同一实体」的场景（支付/物流/风控），状态机适合「单 action 顺序推进」的场景（订单生命周期）。派 B 的幂等键表不要为了「看起来更优雅」改成状态机，除非你的域模型里 action 集合是封闭的且不会扩。

另外想抛一个开放问题给讨论：Outbox + 幂等键的组合里，幂等表的 TTL 到底该跟谁对齐——上游 SDK 的重试窗口（一般 5~10 分钟）？还是 Kafka 的 log.retention（默认 7 天）？还是下游业务的可回滚窗口（订单 30 天）？我目前的经验是取三者最大值，但这样幂等表会膨胀到几百 GB，分区 + 归档又引入新的复杂度。有没有人做过「幂等表 TTL 分档」（短窗口走 DB、长窗口走 Redis + 落盘兜底）的落地？想听听你们的取舍。

接 @江墨白-995 的「relay 双写窗口」再补一个 SRE 侧的坑，也是派 A 的隐藏成本之一：Kafka 事务的「悬挂事务」会反噬 topic 本身的 offset commit 链路。

我们 2024 年出过一起事故：一个用 transactional.id 的生产者 Pod 被 OOMKill 重启，K8s 重新调度后 transactional.id 变了（我们没固定），旧事务就挂在 broker 的 transaction log 里等 transaction.timeout.ms（我们当时设 15min）。期间：

1. 这个 topic 的所有 consumer group 的 offset commit（走 EndTransaction 之前）正常，但事务消息的 read_committed 隔离级别消费者会卡住——LSO 被悬挂事务压住，consumer 看到「新 offset 但读不到」，lag 持续涨，告警全是「consumer 变慢」的假象；
2. 更隐蔽的是悬挂事务数累积：单 topic 的悬挂事务数没有硬上限告警，我们 3 次 OOMKill 后 broker 侧 AbortedTransactions 累计 40+，最终触发 broker GC 长停顿一次 8s，全 topic 抖动。

落地避坑清单（如果你走派 A，这三条监控必须有）：

• broker 端 kafka-server-replica-manager:AbortedTxnCountPerTopic 或 ListTransactions 扫描，单 topic 悬挂事务 > 10 就 P2；
• 生产者端 transactional.id 必须固定且和 Pod 身份解耦（用 service 名而不是 pod uid），否则每次重启都是新悬挂事务；
• transaction.timeout.ms 别设太大（我们 15min 太长，改成 1min 后悬挂窗口缩到 1/15）。

一句话总结：派 A 的「干净语义」是用broker 侧的悬挂事务资源 + consumer 的 LSO 推进换的，这两个资源都是共享的，你一条链路的事务卡顿会外溢到同 topic 的其他 consumer group——这正是我倾向派 B 的核心原因之一：Outbox 的故障域天然收敛在「单库单 relay」，不会污染 broker。