分布式事务

事务四大特性：

1、原子性：事务作为一个整体，要么全部成功要么全部失败
2、隔离性：多个事务并发执行时，事务与事务间相互独立，互不影响
3、一致性：数据库 *** 作的前后数据要保持一致
4、持久性：已经提交的事务对数据库的修该是永久的。

为什么要使用分布式事务

当一个服务中有多个数据库 *** 作，而且需要调用别的微服务的时候，本地的事务管理器无法管理本项目外的事务；
当本项目中出现异常需要回滚时，无法回滚本项目外的事务，这就导致的数据不一致，
本质上来说分布式事务就是为了保证数据库的数据一致性；

CAP定理

C:一致性：写 *** 作之后的读 *** 作，必须返回该值，比如说我数据库中，年龄从18变成19，我再次读取的时候，无论是从集群的那个节点读取都必须读到的是19；
A:可用性：只要收到用户的请求 ，服务器就必须给出回应
P:分区容错：大多数分布式系统都分布在多个子网络，每个网络就叫一个分区；
分区容错就是区间通信可能失败

网络传输是无法完全保障的，所以P是无法避免的，A和C无法共存，当满足可用性的时候必须牺牲掉一致性；
因此当我需要保证一致性的时候必定存在一定的阻塞，阻塞期间，用户无法读取该数据
如果我们要保证高可用，由于网络传输或者其他原因，数据同步不及时，这样用户读取就可能读取到未更新的数据

base理论：

核心思想是既然无法做到强一致性，但是每个应用都可以根据自身业务特点采用适当的方式来使系统达到最终一致性；

• 基本可用： 延时返回结果或者服务降级；
• 软状态：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个阶段的数据副本存在数据延时；
• 最终一致：保证最终能够达到数据的一致性状态。

分布式事务的两种解决方案

TM:Transition Manager：负责管理全局事务，分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等；
RM：Resource Manager：资源管理器，可以理解为访问数据库的服务
AP：Application：事务边界（定义事务开始和结束），访问事务边界的资源。

XA协议二阶段提交

一阶段：寻味RM是否有能力保证成功的提交事务，RM给出标识告诉TM是否可行；
二阶段：根据一阶段的答复，决定是否回滚事务，如果所有的RM都回复可以执行，TM通知所有RM提交事务，只要其中一个答复是NO则通知所有RM回滚事务；
优点：尽量保证了数据的强一致，适合对数据一致要求很高的关键领域（但也不能保证百分比的一致性）
缺点：实现复杂，牺牲了可用性，对性能影响较大，不适合高并发场景

TCC协议补偿机制

核心思想是针对每个 *** 作都注册一个预期对应的确认和补偿 *** 作
1、try阶段：主要是对业务系统检测及资源预留
2、confirm（确认）：主要是对业务系统做确认提交，try阶段执行成果并开始执行，默认confirm是不会出错的，即：只要try成果，confirm一定成功
3、cancel（取消）：在业务执行错误，需要回滚状态下执行任务（反向sql），释放资源
*** 有点像乐观锁

Seata： AT模式

特点：无侵入
事务协调器Transaction Coordinator(TC)：维护全局的运行状态，负责协调并驱动全局事务，并最终发起全局提交或者全局回滚的决议。
事务管理器Transaction Manage™：控制事务的边界，负责开启一个全局事务，并最终发起全局提交或者全局回滚决议。
资源管理器Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报，并接收TM的指令，驱动分支（本地）事务的提交和回滚；
对数据和版本的要求：MySQL5.6以上版本支持XA协议，其他数据库（如Oracle、DB2也实现了XA接口）

一阶段：

• 解析sql
• 提取数据
• 保存快照（执行sql前）
• 执行sql
• 保存快照（执行sql后）
• 生成行锁

二阶段：

• 无异常提交：删除前后快照，删除行锁
• 异常回滚：
  检验脏读：用前后快照和现在的数据库中的数据进行对比
  还原数据：读取到前快照执行逆向sql还原数据
  删除前后快照，删除行锁
  

TCC模式

该模式需要用户根据自己的业务场景（因此侵入性太强，但是整个过程不涉及锁，性能较高），实现Try、Confirm和Cancel三个 *** 作，事务发起方在一阶段执行Try方法，二阶段执行Confirm或Cancel方法。

Sage模式

Sage 是长事务解决方案，事务驱动
适用场景

• 业务流程长/多
• 参与者包含其他公司或遗留系统服务，无法提供 TCC 模式要求的三个接口
• 典型业务系统：如金融网络（与外部金融机构对接）、互联网微贷、渠道整合、分布式架构服务集成等业务系统
• 银行业金融机构使用广泛

三种异常
1、空补偿：原服务未执行，补偿服务执行了
出现原因：

• 原服务超时（丢包）
• Saga 事务触发回滚
• 未收到原服务请求，先收到补偿请求

2、悬挂：补偿服务比原服务先执行

• 原服务超时（拥堵）
• Saga 事务回滚，触发回滚
• 拥堵的原服务到达

3、幂等：原服务与补偿服务都需要保证幂等性

优点:

• 一阶段提交本地数据库事务，无锁，高薪能
• 补偿服务即正向服务的 “反向”，高吞吐
• 参与者可异步执行，高吞吐

XA模式

XA 模式是 Seata 将会开源的另一种无侵入的分布式事务解决方案
优点:

• 无侵入
• 将快照数据和行锁等通过 XA 指令委托给了数据库来完成