XA(强一致)分布式事务协议

A.定义

现在的关系数据库都是可支持的，

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

B.XA接口

1. xa_start :负责开启或者恢复一个事务分支
2. xa_end: 负责取消当前线程与事务分支的关联
3. xa_prepare:询问 RM 是否准备好提交事务分支
4. xa_commit:通知 RM 提交事务分支
5. xa_rollback: 通知 RM 回滚事务分支
6. xa_recover : 需要恢复的 XA 事务

C.XA事务处理过程

1.整个XA

2.单个MySQL内部操作

D.主流XA框架

E.注意事项

• 注意:XA 默认不会改变隔离级别
  1.同步阻塞问题
  全局事务内部包含了多个独立的事务分支，这一组事务分支要不都成功，要不都失败，各个事务分支的ACID特性共同构成了全局 事务的ACID特性。也就是将单个事务分支的支持的ACID特性提升一个层次(up a level)到分布式事务的范畴。即使在非分布式事务中(即本地事务)，如果对操作读很敏感，我们也需要将事务隔离级别设置为SERIALIZABLE。而对于分布式事务来说，更是如此，可重复读隔离级别不足以保证分布式事务一致性。 也就是说，如果我们使用mysql来支持XA分布式事务的话，那么最好将事务隔离级别设置为SERIALIZABLE。地球人都知道， SERIALIZABLE(串行化)是四个事务隔离级别中最高的一个级别，也是执行效率最低的一个级别

2.单点故障
由于协调者的重要性，一旦协调者TM发生故障，参与者RM会一直阻塞下去，尤其在第二阶段，协调者发生故障，那么所有的参 与者还处于锁定事务资源的状态中，而无法继续完成事务操作。(如果协调者挂掉，可以重新选举一个协调者，但是无法解决因 为协调宕机导致的参与者处于阻塞状态的问题)。

3.数据不一致
在二阶段提交的阶段二中，当协调者向参与者发功commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者 发生了故障，这回导致只有一部分参与者接收到了commit请求，而在这部分参与者接到commit请求之后就会执行commit操 作。但是其他部分未接到commit请求的机器则无法执行事务提交，于是整个分布式系统便出现了数据不一致的现象。

BASE柔性事务

A.定义

• 基本可用(Basically Available)保证分布式事务参与方不一定同时在线。
• 柔性状态(Soft state)则允许系统状态更新有一定的延时，这个延时对客户来说不一定能够察觉。
• 而最终一致性(Eventually consistent)通常是通过消息传递的方式保证系统的最终一致性。
在 ACID 事务中对隔离性的要求很高，在事务执行过程中，必须将所有的资源锁定。 柔性事务的理念 则是通过业务逻辑将互斥锁操作从资源层面上移至业务层面。通过放宽对强一致性要求，来换取系 统吞吐量的提升。

a.常见模式

1.TCC：通过手动写代码补偿的方式来实现
2.AT：通过自动补偿处理

b.事务特性

• 原子性(Atomicity):正常情况下保证。
• 一致性(Consistency)，在某个时间点，会出现 A 库和 B 库的数据违反一致性要求的情况，但是最终是一致的。
• 隔离性(Isolation)，在某个时间点，A 事务能够读到 B 事务部分提交的结果。
• 持久性(Durability)，和本地事务一样，只要 commit 则数据被持久。

c.隔离级别

• 一般情况下都是读已提交(全局锁)、读未提交(无全局锁)。

B.TCC模式

a.定义：

TCC 模式即将每个服务业务操作分为两个阶段，第一个阶段检查并预留相关资源，第二阶段根据所有 服务业务的 Try 状态来操作，如果都成功，则进行 Confirm 操作，如果任意一个 Try 发生错误，则全部 Cancel。
TCC 不依赖 RM 对分布式事务的支持，而是通过对业务逻辑的分解来实现分布式事务，不同于 AT 的是就是需要自行定义各个阶段的逻辑，对业务有侵入。

b.使用要求的三段逻辑

TCC 使用要求就是业务接口都必须实现三段逻辑，这三段逻辑是三个独立的事务。

1. 准备操作 Try：完成所有业务检查，预留必须的业务资源。(prepare)
2. 确认操作 Confirm：真正执行的业务逻辑，不做任何业务检查，只使用 Try 阶段预留的业务资源。 因此，只要 Try 操作成功，Confirm 必须能成功。另外，Confirm 操作需满足幂等性，保证一笔分 布式事务能且只能成功一次。
3. 取消操作 Cancel：释放 Try 阶段预留的业务资源。同样的，Cancel 操作也需要满足幂等性。

c.TCC处理流程

d.注意事项

1. 允许空回滚：扣张三100块钱时没成功，回滚的时候就不能给他充100
2. 防悬挂控制：因为网络抖动导致的乱序。AP发起try，TM没收到就cancle，之后才收到try，就导致张三冻结的100块钱就悬挂起来不cancle了。所以后续到达的try应该直接拒绝掉。
3. 幂等设计

C.SAGA模式

Saga 模式没有 try 阶段，直接提交事务。 复杂情况下，对回滚操作的设计要求较高。要求每一步都要做幂等。
由于不需要像TCC一样拆解中间prepare冻结层，对业务的侵入性相对于TCC来说简单得多。

D.AT模式

对SAGA框架做了优化，使用中间件对执行SQL进行解析，自动生成反向SQL。

E.主流框架

a.Seata分布式事务框架

生命周期：

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

b.hmily分布式事务框架

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