分布式事务常见解决方案（两阶段、三阶段）传统项目方案

川长思鸟来 2022-01-28 12:45 347阅读 0赞

# [分布式事务常见解决方案（两阶段、三阶段）传统项目方案][Link 1] #

## 分布式一致性协议 ##

### XA接口 ###

XA是由X/Open组织提出的分布式事务的规范。XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口。XA接口是双向的系统接口，在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。XA之所以需要引入事务管理器是因为，在分布式系统中，从理论上讲（参考Fischer等的论文），两台机器理论上无法达到一致的状态，需要引入一个单点进行协调。事务管理器控制着全局事务，管理事务生命周期，并协调资源。资源管理器负责控制和管理实际资源（如[数据库][Link 2]或JMS队列）

### Jta规范 ###

作为java平台上事务规范JTA（Java Transaction API）也定义了对XA事务的支持，实际上，JTA是基于XA架构上建模的，在JTA 中，事务管理器抽象为javax.transaction.TransactionManager接口，并通过底层事务服务（即JTS）实现。像很多其他的java规范一样，JTA仅仅定义了接口，具体的实现则是由供应商(如J2EE厂商)负责提供，目前JTA的实现主要由以下几种：  
1.J2EE容器所提供的JTA实现(JBoss)  
2.独立的JTA实现:如JOTM，Atomikos.这些实现可以应用在那些不使用J2EE应用服务器的环境里用以提供分布事事务保证。如Tomcat,Jetty以及普通的java应用。

## 两段提交协议 ##

交易中间件与数据库通过 XA 接口规范，**使用两阶段提交来完成一个全局事务**， **XA规范的基础是两阶段提交协议**。

第一阶段是表决阶段，所有参与者都将本事务能否成功的信息反馈发给协调者

第二阶段准备阶段：协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，则会写redo或者undo日志（提交日志和回滚日志），然后锁定资源，执行操作，但并不提交。协调者会向参与者发送一个指令，如果参与者收到指令后，会把该业务逻辑是否执行成功结果返回给协调者。如果参与者都返回执行成功，协调者在第二阶段发送提交事务通知，如果有一方执行失败，就会终止提交。

缺点：如果协调者发生宕机，整个就没法指挥协调了。 库存服务和订单服务会一直等待。

就绪代表业务逻辑执行成功了 ~

第一阶段：

![1179709-20181121235859125-1224052752.png][]

第二阶段：

![1179709-20190115030204422-262960670.png][]

第二阶段是执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提交或者回滚。

第二阶段:如果每个参与者明确返回准备成功，则协调者向参与者发送提交指令，参与者释放锁定的资源，如何任何一个参与者明确返回准备失败，则协调者会发送中指指令，参与者取消已经变更的事务，释放锁定的资源。

小结：

**第一阶段提交**： 协调者会向参与者发送一个指令，如果参与者收到指令后，都会把该业务逻辑是否执行成功发送给协调者。

如果参与者都返回为执行成功，协调者在**第二阶段**发送提交事务通知。如果有一方返回的是执行失败，则终止提交。

**其实由这个图可以看出 分布式解决方案非常类似于 注册中心！  注册中心 管理服务与服务之间的依赖关系  全局事务 管理每个参与者的事务关系**

![1179709-20181121224656801-1872115116.png][]

两阶段提交方案应用非常广泛，几乎所有商业OLTP数据库都支持XA协议。但是两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。

鉴于二阶段提交协议的缺点 全局事务协调者宕机的问题， 提出了三阶段提交协议

## 三阶段提交协议 ##

三阶段提交协议 和两阶段提交协议 最大区别：**两阶段准备阶段再加了一个询问阶段**。

三阶段提交协议是两阶段提交协议的改进版本。它通过超时机制解决了阻塞的问题，并且把两个阶段增加为三个阶段：

询问阶段：协调者询问参与者是否可以完成指令，协调者只需要回答是还是不是，而不需要做真正的操作，这个阶段超时导致中止。

准备阶段：如果在询问阶段所有的参与者都返回可以执行操作，协调者向参与者发送预执行请求，然后参与者写redo和undo日志，执行操作，但是不提交操作；如果在询问阶段任何参与者返回不能执行操作的结果，则协调者向参与者发送中止请求，这里的逻辑与两阶段提交协议的的准备阶段是相似的，这个阶段超时导致成功

提交阶段：如果每个参与者在准备阶段返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源，这里的逻辑与两阶段提交协议的提交阶段一致

**2PC与3PC提交区别**

增加了一个询问阶段，询问阶段可以确保尽可能早的发现无法执行操作而需要中止的行为，但是它并不能发现所有的这种行为，只会减少这种情况的发生在准备阶段以后，协调者和参与者执行的任务中都增加了超时，一旦超时，协调者和参与者都继续提交事务，默认为成功，这也是根据概率统计上超时后默认成功的正确性最大。

三阶段提交协议与两阶段提交协议相比，具有如上的优点，但是一旦发生超时，系统仍然会发生不一致，只不过这种情况很少见罢了，好处就是至少不会阻塞和永远锁定资源。

关于Jta+Atomikos 的解决方案：

Jta+Atomikos 属于两阶段提交协议

后台管理系统的分布式事务解决方案采用Atomikos， 应用场景比较简单，可能会有多个数据源的那种。

XA协议：Jta+Atomikos 底层是基于XA协议，主流数据库 MySQL等都支持XA协议。一个规范，能够参与解决分布式事务问题。这个协议规范就是 协调者把指令发送给参与者的过程。

传统项目中，比如项目中使用到多数据源的时候大多数采用jta+Atomikos解决分布式事务问题，jta+Atomikos底层是基于XA协议的两阶段提交方案。  
XA协议:XA 事务的基础是两阶段提交协议。需要有一个事务协调者来保证所有的事务参与者都完成了准备工作(第一阶段)。如果协调者收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了（第二阶段）。Mysql 在这个XA事务中扮演的是参与者的角色，而不是协调者(事务管理器)。

JTA:JTA（java Transaction API）是JavaEE 13 个开发规范之一。java 事务API，用来操作事务。允许应用程序执行分布式事务处理——在两个或多个网络计算机资源上访问并且更新数据。JDBC驱动程序的JTA支持极大地增强了数据访问能力。事务最简单最直接的目的就是保证数据的有效性，数据的一致性。

Atomikos:Atomikos TransactionsEssentials 是一个为Java平台提供增值服务的并且开源类事务管理器    底层就是遵循了XA协议的规范   
演示jta+atomikos项目  
分布式事务解决方案采用Atomikos 后台管理系统

参考：https://www.cnblogs.com/toov5/p/9820227.html

将参与者 连接到同一个协调者  所有的DataSource关联到一起

xaDataSource.XX 各种神操作

不适合微服务~

分布式事务解决方案采用Atomikos  后台管理系统

主流数据库 都遵循  协调者 发送消息 给参与者 的差异协议   Atomic就是遵循这个协议的Java框架

jta Java语言操作事务

[Link 1]: https://www.cnblogs.com/toov5/p/9998758.html
[Link 2]: http://lib.csdn.net/base/mysql
[1179709-20181121235859125-1224052752.png]: /images/20220128/d572c4e9dc7e4f18a95a91a1e5e6d560.png
[1179709-20190115030204422-262960670.png]: /images/20220128/2636a813422b441b95bf51972767227e.png
[1179709-20181121224656801-1872115116.png]: /images/20220128/f12c329697264872a4d84e9c00f9acb0.png