写库再发消息到底丢了多少：Outbox 与 MQ 事务消息回查的取舍与落地

一、现象与背景：不是丢消息，是「丢了一半」

先讲结论：「先写本地库、再发 MQ」这个看起来最朴素的写法，在高并发下丢的不是消息，而是「库里有、消息没有」的半截状态。这类问题比纯丢消息更隐蔽，因为它能通过所有常规监控——库表数据完整、MQ 消费正常、对账也平，只有下游依赖该事件做后续动作的链路会静默断掉。

去年我们做订单履约链路时撞上了它：order 服务 8 实例，下单 QPS 峰值约 1400，每次下单要落 order 表 + order_item 表，然后发 order-created 事件给库存、积分、风控三个下游。用的是「本地事务提交成功后再调 producer.send」。一次大促压测里，order 表落了 118,402 单，而三个下游事件表合计只收到 117,931 条——差 471 单。这 471 单不是崩溃丢的，是「事务提交返回成功之后、send 之前」进程被 OOMKilled / 被 k8s 滚动重启打断了。对账按库表做的，所以账是平的；断的是下游。

二、根因：跨资源的两步操作没有任何原子性保证

把动作拆开看，「写库 + 发消息」本质是两个不同资源上的两步操作：

1. 本地 DB 事务在 InnoDB 里通过 redo log + 2PC 保证原子性；
2. MQ 的消息持久化是 broker 侧的另一套日志（如 RocketMQ 的 commitlog）。

这两套日志之间没有共享的提交点。你 commit() 成功的那一刻，DB 已经 durable，但消息还在 producer 内存里、或者刚发到 broker 还没 ack。中间任何一步失败（网络、进程退出、broker 抖动），都会留下「库有、消息无」的窗口。反过来「先发消息再写库」则留下「消息有、库无」的窗口——下游收到事件去查库查不到，直接报错。

关键洞察：这不是「重试几次就能解决」的问题，而是「两步操作没有共同提交点」的结构问题。重试只能缩小窗口，不能消除。

三、两种解法与我们的取舍

方案 A：本地事务表（Outbox）

把「要发的消息」作为一行数据，和业务数据在同一个本地事务里一起落库：

BEGIN;
INSERT INTO order(...) VALUES (...);
INSERT INTO order_item(...) VALUES (...);
INSERT INTO outbox(id, topic, payload, status, created_at)
  VALUES (uuid(), 'order-created', json, 'PENDING', now());
COMMIT;

然后由一个独立的 relay 进程轮询 outbox，status=PENDING 的取出发 MQ，成功后置 SENT 并记录 sent_at。因为消息和业务数据在同一个事务里，要么都落、要么都不落，从结构上消灭了半截状态。

我们的 relay 配置（RocketMQ 4.9.4，16 核单机）：

扫描批次 batch_size = 200
扫描间隔 poll_interval = 200ms
outbox 表按 created_at + status 建复合索引 idx_status_created (status, created_at)
发送成功批量 UPDATE ... SET status='SENT', sent_at=now() WHERE id IN (...)

压测下 118,402 单全部产生 outbox 行，relay 在 4.2s 内把 PENDING 清空，事件到达率 100%，relay 自身 P99 端到端延迟约 380ms（含 200ms 轮询周期）。

方案 B：MQ 原生事务消息（以 RocketMQ 为例）

RocketMQ 的事务消息用 half message + 回查：先发 half（对消费者不可见），本地事务提交后 commit / rollback；若 producer 挂了，broker 会定时回查（默认 transactionCheckInterval=60s、transactionCheckMax=15 次）你的 checkLocalTransaction 接口，让你根据本地库状态补 commit / rollback。

它把「提交点」挪到了 broker 侧，比方案 A 更省一张表，但强依赖回查接口能正确反映本地事务终态——如果本地事务其实没提交成功、而回查误判成 committed，就会再次出现半截状态，只是把窗口藏得更深。

我们的最终取舍

我们选了 方案 A（Outbox），理由有三：

1. 回查逻辑的「正确性」难以在压测里穷举，Outbox 的「原子性」是 DB 事务天然给的，不依赖额外代码正确性；
2. Outbox 表天然是审计日志，能直接回答「这单到底发没发、什么时候发的」；
3. 团队里 DBA 对轮询 relay 的容量规划比「回查 + broker 状态机」更可控。

代价是：多一张表、多一个 relay 进程、多一次磁盘写。

四、踩过的坑 / 反直觉之处

1. relay 的「发送成功」判断不能只看 send 返回。我们最初用 sendResult.sendStatus == SEND_OK 就当成功，结果发现 broker 端 flushDiskType=ASYNC_FLUSH 时，SEND_OK 只表示 broker 收到、未必刷盘。改成要求刷盘确认（或接受 at-least-once 语义）后，才把「消息有、下游没有」的窗口真正关掉。

2. outbox 表不能无限膨胀。SENT 行必须归档。我们加了定时任务：status='SENT' AND sent_at < now() - interval '7' day 的行，按天迁到 outbox_archive。一开始没做，outbox 表 3 周涨到 2.1 亿行，relay 扫描 P99 从 380ms 飙到 4.6s，索引也频繁分裂。

3. 轮询 relay 的「至少一次」必须靠下游幂等兜底。relay 发出后、UPDATE 状态前崩溃，会重发。我们一开始把下游当「恰好一次」设计，重发直接导致积分重复加。给下游加了基于 outbox.id 的幂等键后解决。记住：Outbox 给的是 at-least-once，不是 exactly-once。

4. 复合索引顺序。idx_status_created(status, created_at) 比 idx_created_status 好——因为 relay 永远先按 status='PENDING' 过滤，status 选择性在前能把扫描行数压到最小。

五、结论与可复用清单

核心观点：「写库 + 发消息」的原子性问题，根子是两步操作没有共同提交点，重试只能缩小窗口、不能消除窗口。要么把消息「搬进」本地事务（Outbox），要么把提交点「搬给」broker（事务消息回查），二者必须选一个，不能裸奔。

可复用清单：

• [ ] 新增任何「落库 + 发事件」的链路时，默认上 Outbox 表，而不是「commit 后 send」。
• [ ] outbox 行必带全局唯一 id，并作为下游幂等键。
• [ ] relay 判定「发送成功」要匹配你要的投递语义（ASYNC_FLUSH 下 SEND_OK ≠ durable）。
• [ ] outbox 表加 idx_status_created(status, created_at) 复合索引，并定期归档 SENT 行。
• [ ] 明确告知下游：这是 at-least-once，幂等是下游的责任。
• [ ] 若选事务消息回查，必须为「回查误判」准备补偿/对账，不能假设回查一定正确。

留个开放问题给社区：当一条消息要扇出到 10+ 个下游、且各下游的确认时间差异很大时，Outbox 的「单表 + 单 relay」会不会成为瓶颈？你们有没有人把 relay 拆成「按 topic 分片」的多实例？欢迎在楼下聊聊。