分布式事务实现

一、什么是分布式事务

1.1 单体应用
首先，来看下传统的单体应用（Monolithic App）。下图是一个单体应用的 3 个 模块，在同一个数据源上更新数据来完成一项业务，整个过程的数据一致性可以由数据库的本地事务来保证，如下图：

1.2 分布式应用
随着业务需求和架构的变化，单体应用进行了服务化拆分：原来的 3 个 模块被拆分为 3 个独立的服务，每个服务使用独立的数据源（Pattern: Database per service）。整个业务过程将由 3 个服务的调用来完成，如下图：

面临分布式系统所面临的典型分布式事务需求：
分布式系统需要一个解决方案来保障对所有节点操作的数据一致性，这些操作组成一个分布式事务，要么全部执行，要么全部不执行。

二、二阶段协议

二阶段提交（2PC， two-phase commit protocol），顾名思义，就是通过二阶段的协商来完成一个提交操作。
2PC分为两个阶段：投票阶段和提交阶段，我们来详细看下。

事务过程
二阶段提交协议，包含两类节点：

• 一个中心化协调者节点（coordinator），一般也叫做事务协调者
• 多个参与者节点（participant、cohort），一般也叫做事务参与者

二阶段提交协议的每一次事务提交过程如下：

投票阶段

1、事务协调者请所有事务参与者进行投票：是否可以提交事务，然后等待所有参与者的投票结果；

2、参与者如果投票表示可以提交事务，那么就必须预留本地资源（执行本地事务），然后响应YES，后续也不再允许放弃事务；如果不能，就返回NO响应；

3、如果协调者接受某个参与者的响应超时，它会认为该参与者投票为NO，即预留资源失败。

提交阶段（commit phase）
在该阶段，事务协调者将基于投票阶段的投票结果进行决策：提交或取消各参与者的本地事务

1、仅当所有参与者都返回 YES 响应时，协调者才向所有参与者发出提交请求，此时所有参与者必须保证提交事务成功；

2、如果投票阶段中任意一个参与者返回 No 响应，则协调者向所有参与者发出回滚请求，所有参与者进行回滚操作。

优点：

• 强一致性，因为一阶段预留了资源，所有只要节点或者网络最终恢复正常，协议就能保证二阶段执行成功；

• 业界标准支持，二阶段协议在业界有标准规范——XA 规范，许多数据库和框架都有针对XA规范的分布式事务实现。

缺点：

• 在提交请求阶段，需要预留资源，在资源预留期间，其他人不能操作（比如，XA 在第一阶段会将相关资源锁定） ，会造成分布式系统吞吐量大幅下降；

• 容错能力较差，比如在节点宕机或者超时的情况下，无法确定流程的状态，只能不断重试，同时这也会导致事务在访问共享资源时发生冲突和死锁的概率增高，随着数据库节点的增多，这种趋势会越来越严重，从而成为系统在数据库层面上水平伸缩的"枷锁"；

2PC分布式事务方案，比较适合单体应用跨多库的场景，一般用spring + JTA就可以实现。但是因为严重依赖于数据库层面来搞定复杂的事务，效率很低，所以绝对不适合高并发的场景。

分布式事务：TCC

一、简介

2007年，Pat Helland发表了一篇名为《Life beyond Distributed Transactions: an Apostate’s Opinion》的论文，提出了TCC（Try-Confirm-Cancel） 的概念。

两阶段提交（2PC）和三阶段提交（3PC）并不适用于并发量大的业务场景。TCC事务机制相比于2PC、3PC，不会锁定整个资源，而是通过引入补偿机制，将资源转换为业务逻辑形式，锁的粒度变小。

TCC的核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作，分为三个阶段：

• Try：这个阶段对各个服务的资源做检测以及对资源进行锁定或者预留；

• Confirm ：执行真正的业务操作，不作任何业务检查，只使用Try阶段预留的业务资源，Confirm操作要求具备幂等设计，Confirm失败后需要进行重试；

• Cancel：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，即执行回滚操作，释放Try阶段预留的业务资源 ，Cancel操作要求具备幂等设计，Cancel失败后需要进行重试。
  

二、TCC的执行

TCC将一次事务操作分为三个阶段：Try、Confirm、Cancel，我们通过一个订单/库存的示例来理解。假设我们的分布式系统一共包含4个服务：订单服务、库存服务、积分服务、仓储服务，每个服务有自己的数据库，如下图：