无需CDC如何实现消息队列at-least-once投递与数据库事务提交一致性

你提到的基于events表的方案属于行业通用的发件箱模式（Outbox Pattern），不需要以牺牲实时性为成本做权衡，只需要对投递逻辑做简单优化即可：

优化后的发件箱实现流程 #

• 事务内逻辑调整：
  1. 开启PostgreSQL事务
  2. 完成业务数据的读取、写入操作
  3. 满足消息触发条件时，将待投递的消息内容、唯一消息ID写入events表，标记状态为待投递，事务内不调用RabbitMQ接口
  4. 提交数据库事务
• 投递逻辑采用双触发机制：
  1. 事务提交成功后，立刻触发异步协程/线程读取刚写入的events记录，调用RabbitMQ完成投递，投递成功后将记录标记为已投递
  2. 保留低频次的cron兜底任务：例如每5分钟执行一次，仅筛选创建时间超过1分钟、状态仍为待投递的记录做重试投递，覆盖事务提交后进程立刻崩溃、未触发异步投递的极端场景

这套方案99.9%以上的消息都能实现毫秒级投递，仅极端故障场景下会出现最多5分钟的延迟，同时完全规避了消息先于事务提交的问题，满足at-least-once投递要求。

配套要求：消费者侧必须实现幂等逻辑，可直接使用消息内的唯一业务ID做消费校验，避免重复消费带来的业务异常。

如果后续考虑切换到CDC方案，有两个极低运维成本的实现路径：

• PostgreSQL内置LISTEN/NOTIFY机制：无需额外部署服务，给events表配置行级触发器，事务提交后触发NOTIFY事件，投递服务全程监听对应通道，收到事件后立刻拉取待投递消息，延迟比异步触发更低
• 轻量CDC插件组合：使用PG官方维护的pg_cron+pg_logical插件，直接在PG实例上安装即可，不需要部署Debezium等重型CDC服务，通过逻辑解码获取数据变更后直接投递到RabbitMQ，资源开销仅占PG实例的5%以内，适合中小规模业务场景。

纯cron轮询的发件箱模式是成本最低的实现，但并非必选项，上述双触发、LISTEN/NOTIFY方案的开发和运维成本都极低，远低于分布式事务、XA协议等一致性方案，完全可以同时满足一致性、实时性、低成本三个要求。

内容的提问来源于stack exchange，提问作者typicallearner