Outbox 之后谁来可靠地把消息搬出去：轮询 poller 还是 CDC，你们到底怎么取舍

背景

社区里「写库 + 发消息」这一步已经聊得比较透了：212 号那篇《写库再发消息到底丢了多少》把「库里有、消息没有」的半截状态讲得很清楚，大家基本共识是别在业务事务里直接调 MQ，而是落到一张本地 outbox 表。但我觉得很多人停在了「选定 Outbox」这一步，下一个同样致命的问题被悄悄跳过了——outbox 表里已经躺着一行待发记录，到底是谁、用什么机制把它可靠地搬到 MQ 里去？ 这一步做错了，前面所有语义保证都白搭，而且故障形态特别隐蔽：表一直在涨、MQ 一直不涨，监控还都是绿的。

常见的几种做法（也是分歧所在）

1. 轮询 poller：起一个（或几个）进程，SELECT ... WHERE status='PENDING' ORDER BY id LIMIT N FOR UPDATE SKIP LOCKED，发出去后回写 status='SENT'。简单、不依赖额外组件，但 poller 自己就是新的单点/脑裂源，多实例抢锁、批量大小、回写失败重试、表膨胀清理，每一项都能单独翻车。
2. CDC（Debezium / Canal 监听 binlog）：业务只管往 outbox 表写行，binlog 天然有序，下游 connector 负责投递。可靠性和解耦都更好，但多一套要运维的组件（offset 存哪、schema 变更、connector 重启回放、binlog 保留时长），团队门槛明显更高。
3. MQ 事务消息 / 半消息：绕开 outbox 表，靠 broker 回查兜底。这条 212 号已经展开，这里不重复，但它和「轮询 vs CDC」其实是同一道题的不同解法。

我的倾向与理由

我带团队处理订单、库存这类有副作用的链路时，倾向是：中小团队、组件预算有限 → 轮询 poller，但必须把三件事做扎实：SKIP LOCKED 抢锁（MySQL 8.0+）避免多实例重复投递；发送成功与回写 status 之间用一个「已发未回写」的内存 + 对账兜底（宁可重复、不可丢，配合消费端幂等）；定时清理 SENT 行、给 status, id 建复合索引，否则表越大 LIMIT N 越慢。而组件预算够、链路是核心资金/履约 → 直接上 CDC，因为 binlog 的持久性与顺序性正好补上了 poller 自己那块最脆的「回写原子性」。我不太推荐在核心链路上用一个自己写的 poller 去赌运维能力。

想听大家在什么场景下怎么选

• 你们现在线上是轮询还是 CDC？poller 是单实例还是多实例抢锁？SKIP LOCKED 还是 SELECT ... FOR UPDATE 串行锁？
• 轮询的 poller 挂了 / 回写失败，你们的兜底和对账是怎么做的？有没有因为「已发未回写」窗口导致过重复或丢失？
• CDC 这边：Debezium 的 offset 存在哪、schema 变更怎么平滑、binlog 保留策略你们怎么定的？
• 有没有人踩过「outbox 表膨胀到千万行、poller 越转越慢」的坑，最后怎么治理的？

欢迎贴具体的表结构、poller 伪代码或 connector 配置，越能复现越好，我们一条条拆。