分布式事务理解
分布式事务是为了解决在微服务架构下，业务数据在跨进程执行时，需要保证业务的事务性。
分布式事务框架主要有Seata、atomikos、TX-LCN。其他方式处理我目前已知的有通过mq的方式(待研究);
基本原理
- CAP定理
- BASE理论
- ACID理论
CAP理论
CAP理论指的是在一个分布式系统中无法同时满足Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性)
- 一致性(Consistency)指的是同一时间，任意节点下的数据都是一样的
- 可用性(Availability)指的是同一时间，任意节点均可访问
- 分区容错性(Partition tolerance)指的是数据没有在一定的时间内完成数据的一致性
由于现有网络架构，分区容错性一定存在。因此实际系统中只能存在AP或CP两种情况。
BASE理论
BASE理论指的是Basically Available（基本可用）、Soft-state（ 软状态/柔性事务）、Eventual Consistency（最终一致性）。是根据CAP理论演化而来的，适合于对数据一致性要求不那么高的系统。
- Basically Available（基本可用）指的是允许系统在出现故障的适合保证核心业务允许而损失一些可用性
- Soft-state（ 软状态/柔性事务）指的是允许系统存在数据不一致的中间状态
- Eventual Consistency（最终一致性）指的是系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，不需要实时保证系统数据的强一致性。
柔性事务
柔性事务指的是数据库中的事务满足BASE理论而不是ACID理论的事务。
主要有一下四种：
- AT模式
- TCC模式
- Saga模式
- XA模式
2阶段提交
协调者:
- 让参与者进行执行事务
参与者:
2. 执行事务,将结果返回协调者
协调者:
3. 根据结果，向参与者发送commit或roback命令
- 二阶段提交的问题是
- 参与者长时间lock资源
- 协调者存在单点问题
- commit可能不成功
3阶段提交
3阶段提交相比于2阶段提交多了以下几个改进
- 允许超时取消
- 增加预提交阶段
AT模式
AT模式主要分为两个步骤：
- 事务发起者执行业务sql、保存after image、before image、生成行级锁
- 根据协调者判断事务是否提交还是回滚
TCC模式
TCC模式主要分为两个步骤：
- try 做资源检查
- 1 Confirm 提交资源
- 2 Cancel 回滚资源
TCC模式需要将业务代码改造成符合TCC模式的三个方法，对业务有侵入。
由于TCC模式不需要行级锁，因此并发性较高。
Saga模式
Saga模式指的是通过冲正补偿服务来实现事务的，适用的场景是业务流程长且需要保证事务最终一致性的业务系统。
XA模式
XA模式指的是一阶段预提交，并将提交结果反馈给==协调者==，协调者收到全部参与者的结果后，同一执行提交或回滚。
参考文档
