分布式事务相关说明

分布式事务相关说明

一张图了解事务中的角色

XA 是由X/Open组织提出的分布式事务的规范。 XA规范主要定义了(全局)事务管理强（RM）和(局 部)资源管理器(RM)之间的接口。

事务的ACID 特性：
A （原子性）：整个事务中的所有操作要么全做，要么全不做
C（一致性） ：事务的执行必须保证系统的一致性，例如：A有200元，B有100元，一个事务里A成功转给B50元，只要事务执行成功了，那么最后A定是150元，B是150元
I （隔离型） ：事务和事务之间互不影响，一个事务的中间状态是不会被其他事务感知
D （持久性） ：事务一旦执行完成，那么事务操作的变更就会完全保存在数据库中

分布式事务出现原因：本来事务的参与者就在一个应用程序中，所以没有分布式事务的概念，但是由于微服务，SOA 架构的兴起，就产生了事务参与者在不同的应用程序中，多个程序中，比较难满足事务的ACID特性，所以才会有XA 协议的提出

XA包含两种实现 二阶段提交（2PC），三阶段提交（3PC）

二阶段提交

事务协调者：事务的发起者，事务参与者：事务的执行者

1. 准备阶段 ：

• 事务协调者向所有的事务参与者发送事务信息，询问事务准备好提交事务,并等待回复。
• 参与者接受到事务信息，开始执行事务操作，但是不提交事务（可以将相关操作记录日志），然后回复协调者，执行状态（准备状态ok/no）

2. 提交阶段：

• 协调者根据参与者回复状态，来确认事务是否提交，如果参与者中有一个返回状态为no，给所有的参与者发送事务回滚信息，否则发送提交信息
• 参与者根据协调者发送的信息进行事务提交或者回滚
  
  
  2PC 问题：执行事务操作的时候，所有参与者处于同步阻塞状态，占用资源，容易产生性能瓶颈问题。如果协调者出现了问题，那么参与者将处于锁定状态，无法确保阶段2后，所有参与者在网络原因下全部收到消息(一部分收到了事务提交信息，一部分没有)

三阶段提交

基于二阶段提交，加入超时机制，在协调者和参与者中都加入了超时机制

canCommit 阶段

1. 协调者向参与者发送canCommit 请求，询问事务是否可以提交
2. 参与者收到请求后，根据自身状态，返回是否可以提交（yes or no），这个阶段并不执行事务操作

preCommit 阶段

1. 协调者根据参与者上个阶段参与者返回的结果，进行处理，如果有一个返回no，则向所有参与者发送abort 请求，中断事务，否则向所有参与者发送preCommit 请求（2PC 中的准备阶段）
2. 参与者如果收到abort 请求或者等待协调者请求超时，参与者都会中断事务，收到preCommit 请求，执行事务操作，记录相关日志，但不提交事务，然后返回执行状态（ ack 响应或 no 响应）

doCommit 阶段

1. 协调者收到preCommit 阶段 中参与者ack 响应，向所有参与者发送doCommit 请求。如果有preCommit阶段中参与者返回no响应，则发送abort 中断事务
2. 参与者收到doCommit 请求 则提交事务，释放资源，返回ack响应，收到abort请求，中断事务并回滚，释放资源，返回ack响应
3. 协调者收到ack 响应，完成事务提交或中断

阶段3中，无论协调者或者参与者出现网络问题，都会导致参与者无法接受到协调者的 do Commit 请求或 abort 请求，此时，参与者都会在等待超时之后，继续执行事务提交。

问题：数据不一致问题，也就是上面说的问题

参考的原文章