分布式场景之刚性事务-XA/2PC详解

分布式一致性

分布式场景下，多个服务同时对服务一个流程，比如电商下单场景，需要支付服务进行支付、库存服务扣减库存、订单服务进行订单生成、物流服务更新物流信息等。如果某一个服务执行失败，或者网络不通引起的请求丢失，那么整个系统可能出现数据不一致的原因。

上述场景就是分布式一致性问题，追根到底，分布式一致性的根本原因在于数据的分布式操作，引起的本地事务无法保障数据的原子性引起。

分布式一致性问题的解决思路有两种，一种是分布式事务，一种是尽量通过业务流程避免分布式事务。分布式事务是直接解决问题，而业务规避其实通过解决出问题的地方(解决提问题的人)。其实在真实业务场景中，如果业务规避不是很麻烦的前提，最优雅的解决方案就是业务规避。

 

事务分类

分布式事务实现方案从类型上去分刚性事务、柔型事务。刚性事务：通常无业务改造，强一致性，原生支持回滚/隔离性，低并发，适合短事务。柔性事务：有业务改造，最终一致性，实现补偿接口，实现资源锁定接口，高并发，适合长事务。

刚性事务：XA 协议（2PC、JTA、JTS）、3PC

柔型事务：TCC/FMT、Saga（状态机模式、Aop模式）、本地事务消息、消息事务（半消息）

 

XA协议

X/Open DTP模型

X/Open DTP是X/Open 组织（即现在的 Open Group ）1994定义的分布式事务处理模型。XA规模型包括应用程序（ AP ）、事务管理器（ TM ）、资源管理器（ RM ）、通信资源管理器（ CRM ）四部分。一般，常见的事务管理器（ TM ）是交易中间件，常见的资源管理器（ RM ）是数据库，常见的通信资源管理器（ CRM ）是消息中间件。

 

2PC 通常使用到XA中的三个角色RM、TM、AP

AP：事务发起方，通常为微服务自身；定义事务边界(事务开始、结束)，并访问事务边界内的资源

TM：事务协调方，事务操作总控；管理事务全局事务，分配事务唯一标识，监控事务的执行进度，负责事务的提交、回滚、失败恢复。

RM：本地事务资源，根据协调方命令进行操作；管理本地共享资源(既数据库)。

 

XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：

XA接口详解

X/Open XA接口是双向的系统接口，在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。事务管理器控制着JTA事务，管理事务生命周期，并协调资源。在JTA中，事务管理器抽象为javax.transaction.TransactionManager接口，并通过底层事务服务（即JTS）实现。资源管理器负责控制和管理实际资源（如数据库或JMS队列）。下图说明了事务管理器、资源管理器，以及典型JTA环境中客户端应用之间的关系：

注意，上图中XA接口形成了事务管理器和资源管理器之间的通信桥梁。因为XA接口的双向特质，XA支持两阶段提交协议，我们将在本章的后续部分讨论。

本章所叙述的内容很难覆盖XA接口的所有细节。如果读者关心XA的细节，请参考X/Open XA接口规范（可在http://www.opengroup.org/onlinepubs/009680699/toc.pdf通过pdf的格式拿到）。

什么时候应该使用XA？

在Java事务管理中，常常令人困惑的一个问题是什么时候应该使用XA，什么时候不应使用XA。由于大多数商业应用服务器执行单阶段提交（one-phase commit）操作，性能下降并非一个值得考虑的问题。然而，非必要性的在您的应用中引入XA数据库驱动，会导致不可预料的后果与错误，特别是在使用本地事务模型（Local Transaction Model）时。因此，一般来说在您不需要XA的时候，应该尽量避免使用它。下面的最佳实践描述了什么时候应当使用XA：

最佳实践 仅在同一个事务上下文中需要协调多种资源（即数据库，以及消息主题或队列）时，才有必要使用X/Open XA接口。

这里体现了一个重要的观点，即虽然您的应用可能使用到多个资源，但仅当这些资源必须在同一个事务范畴内被协调时，才有必要用到XA。多个资源的情形包括访问两个或更多的数据库（并不止是多个表，而是彼此分开的多个数据库），或者一个数据库加上一个消息队列，又或者是多个消息队列。您可能有一个应用同时使用到一个数据库和一个消息队列。然而，如果这些资源并不在同一个事务中使用，就没有必要去用XA。本章开始的代码，预置一个固定收入交易，而后向队列发送一条消息，就是需要使用XA以便维护ACID特性的例子。

需要并使用XA最常见的场景是在同一个事务中协调数据库更改和消息队列（或主题）。注意这两种操作有可能在应用完全不同的地方出现（特别是在使用像hibernate这样的ORM框架的时候）。XA事务必须在回滚事件发生时协调两种类型的资源，或让更改与其他事务保持隔离。如果没有XA，送往队列或主题的消息甚至会在事务终止前到达并被读取。而在XA环境下，队列中的消息在事务提交之前不会被释放。此外，如果是协调一个操作型数据库和一个只读数据库（即参考数据库），您就不需要XA。然而，由于XA支持“只读优化”，当把一个只读数据源引入XA事务时，您可能并不会看到任何的性能损失。

当意图在您的企业Java应用中使用XA时，有几个隐含的问题是需要考虑的。这些问题包括两阶段提交（2PC，two-phase commit process），经验异常，以及XA驱动的使用。

 

参考资料：

DTP模型之一：（XA协议之一）XA协议、二阶段2PC、三阶段3PC提交 https://www.cnblogs.com/duanxz/p/4672708.html

Spring+iBatis+Atomikos实现JTA事务 https://www.cnblogs.com/duanxz/p/4672640.html

JTA负责Atomikos框架的一个指挥和调度，让它按照事务的基本步骤来走，Atomikos框架相当于是DTP模型里的TM，跟各个MySQL（RM）通信，XA START、XA END、XA COMMIT、XA ROLLBACK等符合XA规范的一套接口调用。

MySQL binlog 组提交与 XA(两阶段提交) https://www.linuxidc.com/Linux/2015-11/124942.htm

 

维基百科定义：

X/Open XA

在计算技术上，XA规范是开放群组关于分布式事务处理 (DTP)的规范。规范描述了全局的事务管理器与局部的资源管理器之间的接口。XA规范的目的是允许多个资源（如数据库，应用服务器，消息队列，等等）在同一事务中访问，这样可以使ACID属性跨越应用程序而保持有效。XA使用两阶段提交来保证所有资源同时提交或回滚任何特定的事务。

XA规范描述了资源管理器要支持事务性访问所必需做的事情。遵守该规范的资源管理器被称为XA compliant。

参见

• Resource Recovery Services
• 二阶段提交
• 分布式关系型数据库架构（DRDA）

外部链接

• Distributed TP: The XA Specification
• X/Open distributed transaction processing model[永久失效链接]
• XA Transaction for MySQL

 

二阶段提交

二阶段提交（英语：Two-phase Commit）是指在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。通常，二阶段提交也被称为是一种协议（Protocol）。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点（称作参与者）的操作结果并最终指示这些节点是否要把操作结果进行真正的提交（比如将更新后的数据写入磁盘等等）。因此，二阶段提交的算法思路可以概括为： 参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

 

 

 

2PC定义

 

2PC全称Two-phaseCommit，中文名是二阶段提交，是XA规范的实现思路，XA规范是 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。XA 接口函数由数据库厂商提供。

 

2PC流程

 

2PC 分成2个阶段，第一阶段：请求阶段（commit-request phase，或称表决阶段，voting phase）和第二阶段：提交阶段（commit phase）。

 

表决阶段：事务协调者(TM)串行给每个参与者(RM)发送Prepare消息，每个参与者要么直接返回失败，要么在本地SQL执行、记录事务日志(Undo、Redo)，但不提交，到达一种“万事俱备，只欠东风”的状态。

 

可以进一步将准备阶段分为以下三个步骤：

1）TM串行向每个参与者节点询问是否可以执行提交操作，并等待各参与者节点的响应。

2）参与者节点执行询问的所有SQL语句，并将Undo和Redo写入日志。

3）各参与者节点响应TM发起的询问。如果参与者节点的事务操作实际执行成功，则返回一个”success”消息；如果参与者节点的事务操作实际执行失败，则返回一个”abort”消息。

 

提交阶段：如果TM收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据TM的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

 

分支一--当TM从所有参与者节点获得的相应消息都为”success”时：

1）TM向所有参与者节点发出”正式提交(commit)”的请求。

2）参与者节点正式完成操作，并释放在整个事务期间内占用的资源。

3）参与者节点向TM发送”完成”消息。

4）TM受到所有参与者节点反馈的”完成”消息后，完成事务。

分支二--如果任一参与者节点在第一阶段返回的响应消息为”abort”，或者 TM在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：

1）TM向所有参与者节点发出”回滚操作(rollback)”的请求。

2）参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。

3）参与者节点向TM发送”回滚完成”消息。

4）TM受到所有参与者节点反馈的”回滚完成”消息后，取消事务。

不管最后结果如何，第二阶段都会结束当前事务。

 

总结

 

2PC虽然将XA规范方案细化成思路，也形成了流程图，大部情况下确实能提供原子性操作，但是仍存在一定问题，所以又出现了3PC。