分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

1. 两阶段提交（2PC）

   两阶段提交（Two-phase Commit，2PC），通过引入协调者来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。

   1. 准备阶段: 协调者向所有参与者发送事务内容，并等待答复，参与者发回事务执行结果。
   2. 提交阶段: 如果事务在每个参与者上都执行成功，协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。

   XA 是一个两阶段提交协议，该协议分为以下两个阶段

   • 第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.
   • 第二阶段：事务协调器要求每个数据库提交数据。

   XA优点：简单。缺点：性能差。使用少

   seata的AT 模式基于 支持本地 ACID 事务 的 关系型数据库：（seata脏写问题）

   • 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。
   • 二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。
   • 二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。

   优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）

   缺点： 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

2. 补偿事务（TCC）

   TCC 其实就是采用的补偿(所谓补偿就是已经提交了只能做补偿，+2就-2，可以通过全局undo日志实现)机制，所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作，这个操作是要自定义实现的。它分为三个阶段：

   • Try 阶段主要是对业务系统做检测（一致性）及资源预留（准隔离性）。调用 自定义 的 prepare 逻辑。
   • Confirm 阶段主要是对业务系统做确认提交，执行真正的业务。调用 自定义 的 commit 逻辑。
   • Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。调用 自定义 的 rollback 逻辑。

   优点： 跟2PC比起来，实现以及流程相对简单了一些，只需要按照人家的接口分为3个阶段，框架会自己在合适时机触发他们。但数据的一致性比2PC也要差一些

   缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。

所以TCC会保证分布式下的原子性，甚至极端情况若有些Try逻辑的服务器一直宕机，那么会TCC会一直重试、一直撤销，必须保证全体成功。不少大公司里，其实都是自己研发 TCC 分布式事务框架的。开源TCC框架有：ByteTCC，TCC-transaction，Himly。