本地消息表、Outbox 与事务消息：到底该让谁为"消息不丢不重"负责？

背景：只要系统里同时存在"写业务库"和"发消息"两件事，就绕不开一个经典问题——怎么保证这两步的原子性。我见过三种主流做法在同一家公司里共存：本地消息表（业务表 + 消息表同库同事务，后台扫表投递）、Outbox 模式（同上但配合 CDC 如 Debezium 把消息表变更直接发出去）、事务消息（RocketMQ 的 half message / prepare+commit）。三者都能达成最终一致，但落地成本、可观测性、故障面完全不同。

常见分歧，我观察到的至少有这么几派：

派 A（本地消息表派）：最朴素，不引入额外中间件依赖，投递逻辑完全在应用手里，出问题时"查表 → 重投"就是全部排查路径。缺点是扫描线程和投递服务容易和主业务抢 DB 连接，消息表膨胀后清理策略（保留多久、按状态删还是归档）需要单独设计。

派 B（Outbox + CDC 派）：把"消息表"当作数据库的一部分，用 Debezium / Canal 这类 CDC 工具订阅 binlog 直接推 Kafka，应用侧零投递代码。好处是投递链路和应用解耦，DB 就是唯一事实源；坏处是又多了一层中间件（CDC connector），binlog 格式变更、GTID 切换、connector 重启位点这些坑都得自己扛，且对 DBA 的 binlog 保留策略有强依赖。

派 C（事务消息派）：用 RocketMQ 的 half message，prepare 阶段 broker 落盘但消费者不可见，业务事务 commit 后 send commit，事务回滚则 send rollback。应用侧代码最简单（一次 API 调用），且天然支持"查不到 commit 就回查"的兜底。缺点是把原子性的一部分交给了 broker，broker 自身的持久化可靠性（pagecache 刷盘策略、磁盘故障）就成了新的故障面，且这套机制基本是 RocketMQ 独享，Kafka / Pulsar 没有等价物，技术栈绑死。

我的倾向：中小团队、DBA 话语权不强的场景，我会优先选"本地消息表 + 幂等消费"，理由有三——一是排查路径最短（一张表就能定位所有未投递 / 已投递状态），二是不引入 CDC 这种"隐形中间件"，三是把"消息可靠投递"的责任收敛在应用层，而不是分散到 broker / connector / 应用三处。但前提是：消息表要有独立索引、按状态分表或定期归档，且消费端必须有幂等（业务主键去重表或唯一约束），否则重投 = 数据错乱。

如果团队已经在用 Kafka 且 DBA 对 binlog 管理有成熟流程，Outbox + Debezium 的工程收益更大——应用零投递代码，DB 就是唯一 source of truth。

想听大家聊聊：

1. 你们现在生产上用的是哪种？团队规模和 DBA 成熟度大概是什么水平？
2. 消费端幂等你们怎么做的——去重表、唯一约束、还是业务层天然幂等（比如"设置状态"而不是"累加"）？
3. 有没有遇到过"消息表膨胀到几千万行后清理策略翻车"的情况？怎么处理的？
4. 如果让你从零设计一条新链路（订单 → 积分 → 通知），你会怎么组合这三种手段？

欢迎贴你们的具体配置、表结构、扫描线程参数，越具体越好。