微服务场景下跨服务及对接存量monolith系统的分布式事务管理咨询

跨多微服务多独立DB的分布式事务管理 #

优先基于业务的一致性容忍度选方案，不要默认选强一致性方案牺牲性能：

• 首选最终一致性的可靠事件模式（事务发件箱/本地消息表）：每个服务执行本地事务时，将需要通知下游的事件存在和业务库同实例的本地消息表中，和业务操作在同一个本地事务提交。提交后通过独立的后台线程轮询消息表，将事件推送到消息队列，下游服务消费完成后回传确认标记消息消费成功。该模式需要上下游所有接口实现幂等校验，避免重试导致的脏数据，性能损耗低，落地门槛小，是生产环境使用率最高的方案。
• 跨服务操作链路长、需要明确回滚逻辑的场景用Saga模式：将跨服务的分布式事务拆分为多个独立的本地子事务，每个子事务都对应一个反向补偿操作。链路短可以用编排式Saga，由各服务自行触发下一个节点的调用和异常时的补偿逻辑；链路复杂、涉及服务多的场景用协调式Saga，通过独立的协调器统一控制事务执行流程和异常回滚。注意Saga默认不提供事务隔离性，需要自行在业务层做并发控制，比如增加资源锁定标记、操作流水校验等逻辑。
• 对一致性要求极高的核心场景（如资金扣减、账户变更）可以用TCC（Try-Confirm-Cancel）模式，三个阶段的操作都是原子执行，性能优于XA协议，但是业务侵入性极高，每个操作都需要开发 Try、Confirm、Cancel 三套逻辑，需要评估投入产出比后再选型。

迁移过渡期微服务回写单体的分布式事务处理 #

该场景属于过渡性的异构系统双写场景，优先选轻量方案，避免为临时逻辑引入过重的组件：

• 对一致性容忍度在分钟到小时级的业务，用双写+定时对账方案：微服务先提交本地事务，再异步调用单体系统的回写接口，后台定期跑对账任务，对比两边同主键的数据状态，对不一致的数据做补写/修正，所有回写接口必须实现幂等，避免重复调用产生脏数据。
• 对一致性要求较高、允许秒级延迟的业务，用本地消息表变种方案：微服务提交本地事务时，将需要回写单体的请求参数存在本地消息表，和业务操作同事务提交，后台线程实时捞取未处理的消息调用单体接口，调用成功删除消息，调用失败用指数退避策略重试，同时配合轻量的对账逻辑兜底即可满足需求。

不要为该过渡场景引入XA、全局事务协调器等重组件，后续全量迁移完成后还要额外拆除，会增加不必要的开发和运维成本。

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