分布式事务，只知道TCC？

Posted 2021-04-25 支付技术那些事

本文目录

一、事务的分类

本地事务也称为数据库事务

数据库事务是需要满足ACID（原子性、一致性、隔离性、持久性）四个特性的；

在单一数据节点中，事务仅限于对单一数据库资源进行访问控制，这种事务也称为本地事务

（跨进程）分布式事务

在基于微服务的分布式应用环境下，越来越多的应用场景要求将多个服务的访问以及相对应的数据库资源纳入同一个事务；

如何让数据库在分布式场景下满足ACID特性，或找寻相应的替代方案打到最终结果，是分布式事务的重点工作内容。

二、分布式事务类别

三、柔性事务

柔性事务定义

如果将实现了ACID特性的事务称为刚性事务的话，那么基于BASE事务要素的事务则称为柔性事务。

柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面移至业务层面，通过放宽对强一致性的要求来换取系统吞吐量的提升。

柔性事务特点

基本可用保证分布式事务参与方不一定同时在线。

柔性状态允许系统状态更新有一定的延时，客户不一定能够察觉。

最终一致性通常通过消息可达的方式来保证。

四、XA 协议（刚性事务代表）

XA协议介绍

XA协议通过一个全局事务管理器与多个资源管理器进行交互；

全局事务管理器负责管理全局事务状态和参与事务的资源；

资源管理器则负责具体的资源操作

示意图

两阶段提交

XA协议使用两阶段提交来保证分布式事务的原子性以，它将提交过程分为准备阶段和提交/回滚阶段

准备阶段

全局事务管理器向每个资源管理器发送准备消息，用于确认本地事务操作成功与否

提交阶段

若全局事务管理器收到了所有资源管理器回复的成功消息，则向每个资源管理器发送提交消息，否则发送回滚消息

两阶段提交过程

整个过程

1. 开启XA全局事务后，所有子事务会按照本地默认的隔离级别锁定资源，并记录undo和redo日志，然后由TM发起prepare投票，询问所有子事务是否可以进行提交。

2. 当所有子事务反馈的结果为“yes”时，TM再发起commit；若其中任何一个子事务反馈的结果为“no”，TM则发起rollback；

3. 如果在prepare阶段的反馈结果为yes，而commit的过程中出现宕机等异常，则在节点服务重启后，可根据XA recover再次进行commit补偿，以保证数据的一致性

XA协议的优缺点

1. 严格保障事务的ACID特性。

2. 对业务的侵入性很弱。

最大的优势就是对使用方透明，用户可以像使用本地事务一样使用基于XA协议的分布式事务

3.性能下降

事务执行过程中需要将所需资源全部锁定，更加适用于执行时间确定的短事务；

而，对长事务来说，在整个事务进行期间独占数据将导致依赖热点数据的业务系统的并发性能明显衰退。

五、柔性事务的实现方案

5.1 尽最大努力通知

使用场景

适合用于“对数据库的操作最终一定能够成功”的场景

使用最大努力送达方案的柔性事务是没有回滚功能的

优缺点

优点是无锁定资源时间，性能损耗小

缺点是尝试多次提交失败后无法回滚，它仅适用于事务最终一定能够成功的业务场景

使用实例

各种第三方支付回调，尽最大努力通知型。如支付宝、微信的支付回调接口方式，不断回调直至成功，或直至调用次数衰减至失败状态。

5.2 Saga

适用场景

Saga方案更适合用于长事务场景

Saga模型

将一个分布式事务拆分为多个本地事务，每个本地事务都有相应的执行模块（Transaction）和补偿模块（Compensation），任和一个本地事务出错时，都可以通过调用相关的补充方法实现事务的最终一致性。

Saga模型同时支持正向恢复和逆向恢复

正向恢复是指重试当前失败的事务，它的实现前提是每个子事务最终都能够执行成功；

逆向恢复则是指在任意一个子事务失败时补偿所有已完成的事务。

正向恢复没有必要提供补偿事务，如果在业务中的子事务最终总会成功，那么正向恢复能够降低Saga模型的使用复杂度。

一个实例过程

服务器A的事务先执行，如果执行顺利，那么事务A就先行提交；

如果提交成功，那么就开始执行事务B，如果事务B也执行顺利，则事务B也提交，整个事务就算完成。

但是如果事务B执行失败，那事务B本身需要回滚，这时因为事务A已经提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行前事务A的状态。

5.3 补偿事务 TCC 

补偿事务

通过对业务逻辑进行分解来实现分布式事务

Try-Confirm/Cancel 业务操作

Try：完成业务检查，预留业务所需的资源。Try操作是整个TCC的精髓，可以灵活选择业务资源锁的粒度。

Confirm：执行业务逻辑，直接使用Try阶段预留的业务资源，无须再次进行业务检查。

Cancel：释放Try阶段预留的业务资源。

优缺点

TCC模型对业务的侵入性较强，改造的难度较大。

在柔性事务中，TCC事务模型的功能最强，但需要应用方负责提供实现Try、Confirm和Cancel操作的三个接口，供事务管理器调用，因此业务方改造的成本较高。

A 向 B 转账的一个实例

以A账户向B账户汇款100元为例，代码如下

开源组件

使用 TCC 比较麻烦，一般使用开源的工具去做，常见的开源的：ByteTCC，TCC-transaction，Himly。

5.4 消息驱动

什么是消息驱动

通过消息中间件保证上下游应用数据操作一致性的

基本思路

将本地操作和发送消息放在同一个本地事务中，下游应用从消息系统订阅该消息，收到消息后执行相应的操作，本质上是依靠消息的重试机制达到最终一致性的

消息驱动的缺点

耦合度高，需要在业务系统中引入消息中间件，将导致系统复杂度增加。

实践（eBay 本地消息表）

其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。如果不考虑性能及设计优雅，借助关系型数据库中的表即可实现。

六、分布式事务总结