微服务业务事务异步通信方案与双写问题咨询

关于方案1的双写问题风险 #

你在中型创业公司用AWS SQS的方案1没出问题，确实和SQS的高可用性SLA直接相关——99.9%的可用性意味着全年理论停机时间仅约8.76小时，中小型业务的流量规模和故障触发概率较低，刚好没撞上那0.1%的极端场景（比如数据库提交成功后，SQS突然出现区域级故障、网络链路瞬间中断，且你的重试逻辑没覆盖到这类情况）。

双写问题值不值得担忧，核心看业务对数据一致性的容忍度：

• 如果是非核心场景（比如用户操作日志同步、非关键通知），方案1的简单性远大于风险，完全可以继续用；
• 如果是核心业务（比如订单创建后通知库存扣减、支付成功后通知积分发放），这个风险必须重视：一旦出现“数据存库成功但消息推送失败”，会直接导致业务数据不一致，后续排查缺失消息、补数据的成本极高，甚至引发用户投诉。而且随着业务规模增长，极端场景出现的概率会逐步提升。

其他可选实现方式 #

除了你提到的两种方案，还有几种实用的实现思路：

• 本地事务发件箱模式：在service A的数据库中新增一个发件箱表，将“业务数据插入”和“待发送消息写入发件箱”放在同一个数据库事务里提交。之后启动一个独立的后台线程（或定时任务）轮询发件箱，将未发送的消息推送到队列，发送成功后标记消息为已处理。这种方式利用本地事务的原子性，从根源避免双写不一致，实现成本比CDC方案低很多。
• 补偿校验机制：基于方案1优化，新增定时校验任务：定期对比service A数据库中的业务数据和service B的消息接收记录，发现缺失的消息就自动重新推送。这种方式属于最终一致性方案，适合对时效性要求不高的场景，兼顾了方案1的简单性和一致性需求。
• 队列事务发送：部分消息队列支持与数据库的分布式事务（比如Kafka的事务API），service A可以在同一个分布式事务中完成数据库提交和消息发送，保证两者要么都成功要么都失败。但这种方式复杂度较高，会带来一定的性能损耗，适合对强一致性要求极高的场景。
• 数据库触发器+中间表：在service A的业务表上添加触发器，当数据插入后自动将消息写入中间表，再由独立服务将中间表的消息推送到队列。不过触发器会增加数据库的性能开销，且调试和排查问题较麻烦，一般不推荐在核心业务中使用。

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