分布式事务解决方案

1.0 ACID是传统数据库常用的设计理念，追求强一致性模型。

关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区：
Atomicity原子性：一个事务中所有操作都必须全部完成，要么全部不完成。
Consistency一致性. 在事务开始或结束时，数据库应该在一致状态。
Isolation隔离层. 事务将假定只有它自己在操作数据库，彼此不知晓。
Durability. 持久性 一旦事务完成，就不能返回。

2.0 CAP理论为：

一个分布式系统最多只能同时满足(分布式一般是满足AP)
Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性

3.0 BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。

基本可用（Basically Available）
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
软状态（ Soft State）
软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。
最终一致性（ Eventual Consistency）
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

4.0 分布式事务解决方案

1：LCN
2: rabbitMq
3：rocketMq
4：seata

5.0 rabbitMq 方案

最终一致性，例如：订单服务调派单服务，订单走MQ通知派单服务，派单服务假如异常，进行派单服务补偿，如果订单服务出问题，进行MQ订单服务补偿。

6.0 LCN方案

2pc阶段：：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。

2pc个人理解： 第一阶段，有一个协调者，向参与者发送请求，个参与者开始自己本地事务。第二阶段，协调者接收到参与者的失败和成功，然后通过各参与者提交和回滚。
3pc 比2pc
1、 引入超时机制。同时在协调者和参与者中都引入超时机制。
2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

重写了jdbc，假事务提交。然后执行完毕，通知全部协调者，事务提交
核心步骤
创建事务组
是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId的过程。

加入事务组
添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息通知给TxManager的操作。

通知事务组
是指在发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager,TxManager将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。

3pc阶段提交

3pc是2pc改进版，事务的提交过程分为CanCommit、PreCommit、do Commit三个阶段，引入了超时时间

1. CanCommit：事务询问，多了个事务询问的问题
2. PreCommit： 所有参与者均受到请求并返回YES。
3. do Commit：所有参与者均反馈Ack响应，即执行真正的事务提交。

优点：降低了阻塞范围（引用超时时间），在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段3中协调者出现问题时，参与者会继续提交事务。

缺陷：脑裂问题依然存在，即在参与者收到PreCommit请求后等待最终指令，如果此时协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

7.0 seata

2阶段提交（AT），seata 是先提交事务进去（mysql逆向数据库），然后通过逆向sql，来回滚。事务提交时，才会通知各个模块逆向数据删除。

从TC收到回滚请求后，开始本地事务，执行以下操作。
通过XID和分支ID检索UNDO LOG。
3:验证数据：将UNDO LOG中更新后的图像数据与当前数据进行比较，如果存在差异，则表示该数据已被当前事务以外的操作所更改，应采用不同的策略进行处理，其他将对此进行详细描述文件。
基于UNDO LOG中的前映像和业务SQL的相关信息生成回滚SQL语句。—如果有数据变更，回滚失败，需求手动或者关闭镜像的

5.0 设计分布式事务框架

第一步：先要解决spring事务的环绕功能

第二步：重写链接相关的提交和回滚功能
第三步：事务管理者TC
第四步：事务组id的传播