一、理论基础
（一）分布式事务
1、事务的ACID原则
2、分布式事务的事务问题
每一个服务都是独立的，当库存服务出现问题，其他服务并不知道。每一个服务都是独立的，它对应的事务也是独立的，订单和账户服务完成后，直接提交了，库存服务出现问题也没办法让它们俩回滚。
在分布式系统下，一个业务跨越多个服务或数据源，每个服务都是一个分支事务，要保证所有分支事务最终状态一致，这样的事务就是分布式事务。
（二）理论基础
1、CAP定理
1998年，加州大学的计算机科学家 EricBrewer提出，分布式系统有三个指标，但无法同时满足这三个指标，这个结论就叫CAP定理
-
Consistency(一致性)：用户访问分布式系统中的任意节点，得到的数据必须一致。
例如，用户 A 在节点 1 更新了数据，用户 B 在节点 2 立即读取，必须能看到 A 更新后的结果。
-
Availability(可用性)：用户访问集群中任意健康节点，必须能得到响应，而不是超时或拒绝。
- Partition tolerance(分区容错性)：因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接形成独立分区。
思考:elasticsearch集群是CP还是AP?
ES集群出现分区时，故障节点会被剔除集群，数据分片会重新分配到其它节点，保证数据一致。因此是低可用性，高一致性，属于CP
2、BASE理论
是对CAP的一种解决思路，包含三个思想：
Basically Available(基本可用):分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。Soft state(软状态):在一定时间内，允许出现中间状态，比如临时的不一致状态Eventually Consistent(最终一致性):虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
而分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论:
- AP模式:允许出现结果不一致，然后采用弥补措施恢复数据即可，实现
最终一致。 - CP模式:各子事务分别执行和提交，各个子事务执行后互相等待，同时提交，同时回滚，达成
强一致。但事务等待过程中，处于弱可用状态，
3、分布式事务模型
解决分布式事务，各个子系统之间必须能感知到彼此的事务状态，才能保证状态一致，因此需要一个事务协调者来协调每一个事务的参与者(子系统事务)。
这里的子系统事务，称为分支事务;有关联的各个分支事务在一起称为全局事务。
（三）Seata
seata:https://seata.apache.org/blog
1、seata架构
TC(Transaction Coordinator)-事务协调者 :维护全局和分支事务的状态，协调全局事务提交或回滚。
TM(Transaction Manager)-事务管理器 :定义全局事务的范围、开始全局事务、提交或回滚全局事务.
RM(Resource Manager)-资源管理器:管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚，
二、XA模式（强一致）
（一）原理
seata的XA模式做了一些调整，但大体相似:
RM一阶段的工作:
- 注册分支事务到TC
- 执行分支业务sql但不提交
- 报告执行状态到TC
TC二阶段的工作: - TC检测各分支事务执行状态
- 如果都成功，通知所有RM提交事务,如果有失败，通知所有RM回滚事务
RM二阶段的工作 : - 接收TC指令，提交或回滚事务
优势： - 事务的强一致性，满足ACID原则
- 常用数据库都支持，实现简单，并且没有代码侵入
缺点： - 因为一阶段需要锁定数据库资源，等待第二阶段才释放，性能较差
- 依赖关系型数据库实现事务
（二）实现
1、修改application.yml文件（每个参与事务的微服务），开启XA模式
2、给发起全局事务的入口方法添加@GlobalTransactional注解
3、重启服务并测试
三、AT模式（最终一致）
（一）原理
分阶段提交的事务模式，不过弥补了XA模型中资源锁定周期过长 的缺陷。
简述AT模式与XA模式最大的区别是什么?
- XA模式一阶段不提交事务，锁定资源;AT模式一阶段直接提交，不锁定资源。
- XA模式依赖数据库机制实现回滚;AT模式利用数据快照实现数据回滚
- XA模式强一致;AT模式最终一致
（二）AT模式赃写问题
在事务一第一阶段需要获取锁，才能进行操作，不会出现问题，但是在事务2第一阶段也进行了操作，此时事务一第二阶段决定按照快回滚，此时就出现了问题。
（三）实现
AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，因此实现非常简单。1、导入Sql文件:seata-at.sal，其中lock table导入到TC服务关联的数据库，undo log表导入到微服务关联的数据库。
2、修改application.yml文件，将事务模式修改为AT模式。
3、重启服务并测试。
四、TCC模式
（一）原理
上述两种模式都加了锁，加了锁就会有性能的损耗。
优点：
- 一阶段完成直接提交事务，释放数据库资源，性能好
- 相比AT模型，无需生成快照，无需使用全局锁，性能最强
- 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库
缺点： - 有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
- 软状态，事务是最终一致
- 需要考虑Confirm和Cancel的失败情况，做好幂等处理
（二）空回滚和业务悬挂
1、空回滚
2、业务悬挂
try和cancel要执行互相的判断的，只能执行其一。
对金额冻结，判断当前事务状态。
（三）实现
声明：
实现：
五、SAGA模式（长事务解决方案）
一阶段:直接提交本地事务（操作事务本身）
二阶段:成功则什么都不做;失败则通过编写补偿业务来回滚
因为没有事务隔离，所以可能出现事务脏读问题。
优点:
- 事务参与者可以基于事件驱动实现异步调用，吞吐高
- 一阶段直接提交事务，无锁，性能好
- 不用编写TCC中的三个阶段，实现简单
缺点: - 软状态持续时间不确定，时效性差
- 没有锁，没有事务隔离，会有脏写
五、高可用
实现高可用：搭建集群。TC服务作为Seata的核心服务，一定要保证高可用和异地容灾。
