常见分布式事务解决方案

分布式事务 ：

就是指事务的参与者、支持事务的服务器、资源服务器以及事务

管理器分别位于不同的分布式系统的不同节点之上。简单来说，分布式事务指

的就是分布式系统中的事务，它的存在就是为了保证不同数据库节点的数据一

致性。

聊到分布式事务，大家记得这两个理论哈： CAP 理论 和 BASE 理论

分布式事务的几种解决方案：

• 2PC(二阶段提交)方案、3PC
• TCC（Try、Confirm、Cancel）
• 本地消息表
• 最大努力通知
• seata

2PC( 二阶段提交 ) 方案

2PC ，即两阶段提交，它将分布式事务的提交拆分为 2 个阶段： prepare 和

commit/rollback ，即准备阶段和提交执行阶段。在 prepare 准备阶段需要等待

所有参与子事务的反馈，因此可能造成数据库资源锁定时间过长，不适合并发 高以及子事务生命周长较长的业务场景。并且协调者宕机，所有的参与者都收

不到提交或回滚指令。

3PC

两阶段提交分别是： CanCommit ， PreCommit 和 doCommit ，这里不再详述。 3PC

利用超时机制解决了 2PC 的同步阻塞问题，避免资源被永久锁定，进一步加强

了整个事务过程的可靠性。但是 3PC 同样无法应对类似的宕机问题，只不过出

现多数据源中数据不一致问题的概率更小。

TCC

TCC 采用了补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应

的确认和补偿（撤销）操作。它分为三个阶段： Try-Confirm-Cancel

try 阶段：尝试去执行，完成所有业务的一致性检查，预留必须的业务资源。

Confirm 阶段：该阶段对业务进行确认提交，不做任何检查，因为 try 阶段已经检

查过了，默认 Confirm 阶段是不会出错的。

Cancel 阶段：若业务执行失败，则进入该阶段，它会释放 try 阶段占用的所有业

务资源，并回滚 Confirm 阶段执行的所有操作。

TCC 方案让应用可以自定义数据库操作的粒度，降低了锁冲突，可以提升性能。

但是应用侵入性强， try 、 confirm 、 cancel 三个阶段都需要业务逻辑实现。

本地消息表

ebay 最初提出本地消息表这个方案，来解决分布式事务问题。业界目前使用

这种方案是比较多的，它的核心思想就是将分布式事务拆分成本地事务进行处

理。可以看一下基本的实现流程图：

最大努力通知

最大努力通知方案的目标，就是发起通知方通过一定的机制，最大努力将业务

处理结果通知到接收方。

 

 

seata

Saga 模式是 Seata 提供的长事务解决方案。核心思想是将长事务拆分为多个

本地短事务，由 Saga 事务协调器协调，如果正常结束那就正常完成，如果某

个步骤失败，则根据相反顺序一次调用补偿操作。 Saga 的并发度高，但是一致性弱，对于转账，可能发生用户已扣款，最后转

账又失败的情况