本地事务提交成功、MQ 发送失败：outbox 表 + 定时扫描 vs 事务消息 vs CDC，你们线上到底怎么选、各自踩了什么坑？

背景

团队 8 人维护订单 → 库存 → 支付链路，消费端"至少一次 + 幂等"已做好（幂等表 + 唯一键，TTL 72h），这块不再赘述。今天想聊的是生产端一个更隐蔽的卡点：

本地 DB 事务（insert 订单行 + update 库存）已 COMMIT，但紧接着的 MQ send 因 broker 端 Full GC 停顿 / 网络抖动 / 连接半开而失败 → 下游永远收不到这条消息。

这不是"重复消费"问题，而是"消息根本没发出去"——消费端再健壮也救不了。

现象与已踩的坑

1. 直接 try-catch 重试 send ×3：压测时 broker 端一次 600ms 的 Full GC 就能让 3 次 send 全部超时；更糟的是第 2 次 send 可能已到达 broker 但响应丢了，导致重复投递（消费端幂等兜底了，但生产端日志完全看不出是"没发出去"还是"发了但响应丢了"）。

2. 本地消息表 + 定时扫描（5s 间隔，每批 500 条）：

   • 低峰没问题；大促峰值时积压 12 万条待发消息，扫描本身变成 DB 压力源（SELECT ... WHERE status='pending' ORDER BY gmt_create LIMIT 500 在 12 万行 pending 上频繁扫描）；
   • 扫描任务与业务写入抢同一张表的行锁，P99 写入延迟从 3ms 飙到 11ms；
   • 扫描任务挂了没人知道（只有监控告警，MTTD 平均 4 分钟）。

3. RocketMQ 事务消息（half message + 回查）：

   • 回查窗口设 60s：测试中 broker 在回查窗口内重启，half 消息被回滚，但本地事务已提交 → 数据不一致（订单行存在、库存已扣、消息没了）；
   • 回查逻辑本身要再查一次 DB 确认本地事务状态，回查 QPS 高时 DB 压力不亚于扫描方案。

想请教的具体问题

1. 你们线上生产端到底用的哪种方案？ 具体参数能分享吗（扫描间隔、批量大小、重试退避、回查窗口、超时阈值）？
2. 事务消息的"半消息回滚 vs 本地事务已提交"这个窗口，你们怎么兜底的？ 有没有人实际遇到过？
3. 有没有团队用 CDC（Debezium / Canal + Kafka Connect）替代"消息表 + 扫描"？ 延迟实测多少？binlog 解析的额外复杂度你们怎么评估的？
4. 更开放一点： 在"本地事务 + 消息发送"的原子性问题上，除了"表 + 扫描"和"事务消息"这两条路，有没有你觉得更优雅的中间态？比如数据库触发器写 outbox、应用层 saga 回滚、或者干脆把"发消息"纳入本地事务（XA / Seata AT）——你们试过吗，代价是什么？

期望得到的答案形态

希望看到真实线上参数 + 踩坑时间线（比如"我们 2023 年大促用了方案 B，积压 8 万条时 P99 飙到 xx ms，后来切到方案 C"），而不是教科书式的"建议用 outbox 模式"。如果你们团队踩过我上面列的任意一个坑，欢迎贴细节；如果你们走了完全不同的路（比如把 MQ 换成 DB 轮询 / 事件溯源），也请讲讲取舍。

引用两条消费端侧重的讨论作为背景对照：

• 讨论帖 #620《消息重试的退避策略与死信队列：你们到底按什么规则决定"重试几次、退多久、最后落哪儿"》——消费端重试策略已经讨论得很充分了，生产端"发不出去"这一侧反而缺少正面交锋。
• 讨论帖 #82《消费失败后的"重试 + 死信 + 人工补偿"，你们团队到底是怎么分工的》——同样聚焦消费端，生产端原子性是互补的另一半。