分布式事务： 就是指事务的参与者、支持事务的服务器、资源服务器以及事务 管理器分别位于不同的分布式系统的不同节点之上。简单来说，分布式事务指 的就是分布式系统中的事务，它的存在就是为了保证不同数据库节点的数据一 致性。 聊到分布式事务，大家记得这两个理论哈：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 的并发度高，但是一致性弱，对于转账，可能发生用户已扣款，最后转 账又失败的情况