分布式事务

为什么需要分布式事务

随着互联网的快速发展，业务越来越复杂，一个完整的业务往往需要调用多个子服务，涉及的数据也越来越多。传统的系统难以支撑，就出现了分布式系统，而分布式系统又带来了数据一致性的问题，从而产生了分布式事务。

什么叫分布式事务

分布式条件下，多个节点操作的整体事务一致性。

特别是在微服务场景下，业务A和业务B关联，如果事务A成功了，事务B失败了。由于跨系统，事务B无法通知到事务A，就造成了数据的不一致。

如何实现分布式下的一致性

强一致性XA弱一致性不用事务，业务侧补偿冲正柔性事务，使用一套事务框架保证最终一致性的事务。一、强一致性事务

1. XA分布式事务

在学习XA之前，我们先了解一下DTP模型，该模型规范了分布式事务的模型设计

应用程序（Application Program）:定义事务边界（即事务的开始和结束），并且在事务边界内对资源进行操作资源管理器（Resource Manager）：如数据库、文件系统等。并提供访问资源的方式事务管理器（Transaction Manager)：负责分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚等。

XA协议 是由 X/Open 组织提出的，作为资源管理器与事务管理器的接口标准.目前Oracle、DB2、MySQL的InnoDB存储引擎都对XA进行了支持。XA接口提供资源管理器与事务管理器之间进行通信的标准接口。XA协议包括两套函数，以xa_开头的及以ax_开头的。

xa_start：负责开启或者恢复一个事务分支xa_end：负责取消当前线程和事务分支的关联xa_prepare：询问RM是否准备好提交事务分支xa_commit：通知RM提交事务分支xa_rollback：通知RM回滚事务分支xa_recover：列出所有prepare的XA事务

MySQL 从5.0.3开始支持 InnoDB 引擎的 XA 分布式事务，MySQL Connector/J 从5.0.0版本开始支持 XA

MySQL XA事务状态

完整的XA事务流程

XA事务异常情况

业务SQL执行期间，某个RM崩溃怎么处理？

答：通知回滚。 2. 全部prepare后，某个RM崩溃怎么处理？

答：5.7以前崩溃的那个RM会丢失事务，导致别人都提交了，他被回滚了。5.7之后修复了，重连后还能继续提交。

commit时，某个RM崩溃了怎么办？

答：RM恢复之后重试，要是重试还是失败就要发送告警，人工进行干预。

XA协议存在的问题

同步阻塞问题

全局事务内部包含了多个独立的事务分支，这一组事务分支，这一组事务分支要不都成功，要不都失败。各个事务分支的ACID特性构成了全局事务的ACID特性。那么mysql的效率也会降低 2. 单点故障

TM是单点的，一旦TM发生故障，参与者RM会一直阻塞下去。尤其在第二阶段，TM发生故障，那么所有的RM都还处于锁定资源的状态中，而无法完成事务操作。成熟的XA框架需要考虑TM的高可用性。

数据不一致

在提交阶段的时候，TM向RM发送commit请求后，发生了局部网络异常或者在发送commit请求的时候TM故障了，会导致部分RM收到commit请求并执行，而部分RM未收到commit请求则无法进行事务提交，就会造成数据不一致的情况。

支持XA的框架

XA方面的框架，比较推荐Atomikos和narayana

二、柔性事务

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

BASE:

Basically Available （基本可用）Soft state(柔性状态) 允许系统状态更新有一定的延时Eventually consistent(最终一致性)

柔性事务常见模式

1. TCC

TCC模式将每个服务的业务操作分为两个阶段。第一个阶段检查并预留相关资源（Try），第二个阶段根据Try状态，如果都成功，则进行Comfirm操作，如果任意一个发生错误，则全部Cancel。

Try：完成所有业务检查，预留资源Confirm：正在执行的业务逻辑，不做业务检查，只是要Try阶段预留的业务资源。因此，只要Try成功，Confirm基本能成功。另外Confirm需要满足幂等性。Cancel：释放Try阶段的资源。同样Cancel也需要满足幂等性。

TCC不依赖RM对分布式事务的支持，而是通过对业务逻辑的分解来实现分布式事务。对业务有侵入性

TCC需要注意的问题：

允许空回滚

Cancel的时候要判断Try有没有完成，没完成就不做Cancel 2. 防悬挂控制

如果网络等数据库还没收到Try的执行命令，Cancel命令先收到了。就会导致这个Try命令就没有相对于的Cancel操作了，会一直悬挂在那里。

解决方法：

可以控制Try和Cancel的顺序，让Try在前面先收到Cancel的时候，记录一下。再收到Try的时候就知道这个操作是要取消的，那Try就没必要执行了。幂等设计

commit操作可能会被重试，所以需要幂等性。

2. SAGA

Saga模式没有Try阶段，直接提交事务。复杂情况下，对回滚操作的设计要求较高。

3. AT

AT就是通过自动生成反向SQL的方式进行回滚。

在第一阶段的时候执行业务SQL，并且将SQL造成的影响保留下来。

第二阶段如果发生异常，就会通过保留的影响用反向SQL恢复回去。

缺点：生成反向SQL如果是在特别复杂的情况下，可能会处理不了。

4. 可靠消息最终一致性

服务A发送一个prepared消息给mq,如果发送失败则取消操作消息发送成功则开始执行本地事务本地事务执行成功就向mq发送确认消息,执行失败就发送回滚消息如果mq没有接收到确认消息,mq会去轮询未确认的prepared消息,然后去查询服务A是否执行成功,然后确定是重试还是回滚如果mq成功收到确认消息,那么他会被服务B消费到,并且服务B可以通过ACK机制保证服务B执行成功.如果服务B实在是无法执行成功,可以通知服务A回滚,或者发送报警消息让手工补偿.

5. 本地消息表

服务A执行业务代码,并往自己的消息表插入一条数据服务A执行成功后,会向MQ发送一条数据,去调用服务B的方法服务B收到后,先往自己的消息表插入一条数据,然后去执行业务代码如果服务B业务代码执行成功,那么更新自己的消息表的状态并且通知服务A更新消息表状态如果服务B业务代码执行失败,那么服务B不用做什么服务A会有一个定时任务定时轮询自己的消息表,将失败的消息再发给MQ,让服务B重新在执行一次(服务B保证接口幂等性)通过不断的重试,保证最终一致性

这个方案大量使用来消息表,对于高并发的场景不太友好.

6. 最大努力型通知

类似银行的支付回调，会多次回调直到成功。

这种方案适用于允许有些事务失败的情况,如记录日志等.

三、分布式事务框架

1. Seata

Seata是阿里巴巴和蚂蚁金服联合打造的分布式事务框架。其AT事务的目标是让开发者像使用本地事务一样使用分布式事务。

核心组件：

TM 事务管理者：开启提交或回滚全局事务TC 事务协调者：维护全局和分支事务的状态，指示全局提交或回滚。RM 资源管理者：管理执行分支事务上的资源，向TC注册分支事务、上报分支事务状态、控制分支事务的提交或回滚。

Seata管理的分布式事务的典型声明周期：

TM要求TC开始一个全新的全局事务。TC生成一个代表该全局事务的XID。XID贯穿整个微服务的调用链。TM要求TC提交或回滚XID对应的全局事务。TC驱动XID对应的全局事务下的所有分支事务完成提交或回滚。

Seata支持 XA、TCC、Saga模式，但支持的主要方式是 AT。

2. ShardingSphere对分布式事务的支持

ShardingSphere 通过整合常用的几个事务开源实现，如Atomkkos、Narayana,为本地事务、两阶段事务和柔性事务提供统一的分布式事务接口，并弥补当前方案的不足，提供一站式的分布式事务解决方案是ShardingSphere的设计目标。

作者丨女友在高考

来源：