分布式事务实现
一、什么是分布式事务
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个服务:订单服务、库存服务、积分服务、仓储服务,每个服务有自己的数据库,如下图: