Appearance
分布式事务方案详解-XA到最大努力通知
看在前面
分布式事务科普
随着业务的快速发展、业务复杂度越来越高，传统单体应用逐渐暴露出了一些问题。例如开发效率低、可维护性差、架构扩展性差、部署不灵活、健壮性差。而微服务架构是将单个服务拆分成一系列小服务，且这些小服务都拥有独立的进程，彼此独立。微服务架构很好地解决了传统单体应用的上述问题，但是事务一致性的保证成为新的难点。本文首先从事务的概念出发。带大家先回顾ACID、事务隔离级别、CAP、BASE、2PC、3PC这类基本理论（参考上篇《分布式事务科普——初识篇》）。然后再详细讲解分布式事务的解决方案：XA、AT、TCC、Saga、本地消息表、消息事务、最大努力通知。
分布式事务解决方案
在引入分布式事务前，建议先明确我们是否真的需要分布式事务。有可能因为过度设计致使微服务过多，从而不得不引入分布式事务。这个时候就不建议你采用下面的任何一种方案。而是把需要事务的微服务聚合成一个单机服务，使用数据库的本地事务。因为不论任何一种方案都会增加你系统的复杂度，这样的成本实在是太高了。禁止因为追求某些设计，而引入不必要的成本和复杂度。
常见的分布式事务方案有：XA、AT、TCC、Saga、本地消息表、MQ消息事务、最大努力通知。
X/Open DTP模型与XA
X/Open，即现在的open group，是一个独立的组织，主要负责制定各种行业技术标准。官网地址：http://www.opengroup.org/。X/Open组织主要由各大知名公司或者厂商支持，这些组织不光遵循X/Open组织定义的行业技术标准，也参与到标准的制定。
DTP全称是Distributed Transaction Process，即分布式事务模型。在DTP本地模型实例中包含3个部分：AP、TM和RM（角色结构图见 XA协议 的 DTP 节）。其中，AP 可以和TM 以及 RM 通信，TM 和 RM 互相之间可以通信。
- AP（Application Program，应用程序）：AP定义事务边界（定义事务开始和结束）并访问事务边界内的资源。
- RM（Resource Manager，资源管理器）：RM管理着某些共享资源的自治域，比如说一个MySQL数据库实例。在DTP里面还有两个要求。一是RM自身必须是支持事务的。二是RM能够根据全局（分布式）事务标识（GTID之类的）定位到自己内部的对应事务。
- TM（Transaction Manager，事务管理器）：TM能与AP和RM直接通信，协调AP和RM来实现分布式事务的完整性。负责管理全局事务，分配全局事务标识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复。
AP和RM之间则通过RM提供的Native API 控制资源。这个没有约束API和规范，各个厂商自己实现自己的资源控制，比如Oracle自己的数据库驱动程序。
DTP模型里面定义了XA接口，TM 和 RM 通过XA接口双向通信（这也是XA的主要作用）。除此之外，XA还对两阶段提交协议做了部分优化。例如：TM通知RM提交事务或者回滚事务，RM把提交结果通知给TM。XA 的全称是eXtended Architecture，它是一个分布式事务协议，它通过二阶段提交协议保证强一致性。
其过程大致如下：
第一阶段：TM请求所有RM准备，并告知它们各自需要做的局部事务（Transaction Branch）。RM收到请求后判断能否完成自己的局部事务。能完成就持久化局部事务的工作内容，再给TM肯定答复。要是发生了其他情况，那给TM的都是否定答复。在发送了否定答复并回滚了局部事务之后，RM才能丢弃持久化了的局部事务信息。
第二阶段：TM根据情况（比如说所有RM Prepare成功，或者AP通知它要Rollback）。TM先持久化全局事务的处理决定和所涉及的RM清单。然后通知所有涉及的RM去提交或者回滚它们的局部事务。RM们处理完自己的局部事务后，将返回值告诉TM。此后TM才可以清除掉包括刚才持久化的处理决定和RM清单在内的这个全局事务的信息。
基于XA协议实现的分布式事务是强一致性的分布式事务。典型应用场景如JAVA中有关分布式事务的规范，如JTA（Java Transaction API）和JTS（Java Transaction Service），两者中就涉及到了XA。
XA 协议通常实现在数据库资源层，直接作用于资源管理器上。因此，基于 XA 协议实现的分布式事务产品对业务几乎都没有侵入。这类产品无论是分布式数据库还是分布式事务框架，用起来就像普通数据库一样。
不过XA的使用并不广泛，究其原因主要有以下几类：
性能，如：阻塞性协议，增加响应时间、锁时间、死锁这类因素的存在，在高并发场景下并不适用。
支持程度，并不是所有的资源都支持XA协议。在数据库中支持完善度也有待考验，比如MySQL 5.7之前都有缺陷：MySQL 5.0版本开始支持XA。只有当隔离级别为SERIALIZABLE的时候才能使用分布式事务。
运维复杂。
Seata与AT模式
AT（Automatic Transaction）模式是基于XA事务演进而来，核心是对业务无侵入。它是一种改进后的两阶段提交，需要数据库支持。AT最早出现在阿里巴巴开源的分布式事务框架Seata中，我们不妨先简单了解下Seata。
Seata简介
Seata 是 2019 年初由国内头部互联网企业共同开源的分布式事务解决方案。全称是 Simple Extensible Autonomous Transaction Architecture，即一站式分布式事务解决方案。Seata 的设计思路是将一个分布式事务理解成一个全局事务，全局事务下面挂了多个分支事务。一个分支事务是一个满足 ACID 的本地事务。因此我们可以像操作本地事务一样操作分布式事务。
Seata 内部定义了 3 个模块来处理全局事务和分支事务的关系和处理过程。这 3 个模块分别是 TM、RM 和 TC。其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。
- Transaction Coordinator（TC）：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
- Transaction Manager（TM）：控制全局事务的边界，负责发起一个全局事务，并最终发起全局提交或全局回滚的决议。
- Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报。RM 接收事务协调器的指令，驱动分支（本地）事务的提交和回滚
简要概括整个事务的处理流程为：
1、TM 向 TC 申请发起一个全局事务。TC 创建全局事务后返回全局唯一的 XID。XID 会在全局事务的上下文中传播；
2、RM 向 TC 注册分支事务，该分支事务归属于拥有相同 XID 的全局事务；
3、TM要求TC提交或回滚XID的相应全局事务。
4、TC在XID的相应全局事务下驱动所有分支事务以完成分支提交或回滚。
Seata 会有 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。这个小节我们主要来讲述AT模式的实现方式，TCC和Saga模式在后面会继续介绍。
本文为转载节选，原文止于 Seata/AT。TCC、Saga、本地消息表、最大努力通知详见 分布式事务解决方案 与 分布式事务面试八问。