分布式事务专题

分布式事务理论

一、CAP定理

C ：Consistency 强一致性
A ：Availability 高可用性
P ：Partition tolerance 分区容错性

CAP定理强调的各个部分都是强制的。
例如：
1.强一致性可以通过MySQL主从同步时，锁定从库，保证读取数据一定为最新
2.高可用性，允许读出旧数据，但是必须要及时返回
3.网络分区，必须容忍节点有无法通信的情况，而使得整个系统仍旧可以对外服务，实现：使用主从方案和异步方案。

二、BASE理论

我们称满足BASE理论的事务为柔性事务。
BASE理论特点：
1.基本可用性：核心功能正常响应
2.最终一致性
3.软状态：允许存在中间状态（支付中）

分布式事务解决方案

虽然seata四种都有实现，但是它首推AT模式

一、2PC

期间维护undo和redo用于回滚和入库
seata采用before image 和 after image

2PC的问题：
1.同步阻塞问题 ，一阶段，完成了一系列操作，但是仍需要TM的提交命令，这期间资源是被占用的，是阻塞的。
2.单点故障，一阶段结束，TM故障，导致二阶段无法进行，使得资源被一直阻塞。
3.数据不一致问题，一个事务提交，一个未提交

二、Seata对2PC的扩展基本流程

梳理好三者层级关系。(向下，向上的关系)

1）Seata方案—XA

XA：各个数据库厂商遵循的2PC定义的统一接口
特点：
1.性能：低
2.模式：CP，强一致性（第二阶段等各个服务都完成才提交。其他方案是第一阶段先提交，之后通过补偿策略）

应用场景：
1.金融，并发量不大，但是数据重要的场景

2）Seata方案—AT

特点：
1.性能：高（一阶段提交，减少同步阻塞）
2.模式：AP，存在中间数据不一致（因为第一阶段就提交事务了）
3.使用：需要自己能掌控数据库，因为要建立undo log表
RM和TM嵌入应用程序，以jar包形式存在

应用场景：
1.允许数据短时不一致，对账，补录保证最终一致性。

一阶段：

官方：

二阶段提交：

二阶段回滚：

3）Seata方案—TCC

特点：
1.性能：好（不加锁）
2.模式：AP，存在中间数据不一致（有中间状态）
3.使用：需要自己能掌控数据库，因为要自定义字段和规则

应用场景：
1.支持异构数据库，允许短时数据不一致
注意：
1.一般不用，比较复杂，一般采用下面MQ的TCC模式

4）MQ实现—TCC

gulimall 死信队列 实现

5）Seata方案—SAGA

特点：
性能：不一定，取决于三方
模式：AP，有中间状态
1.在架构中引入状态机机制，类似工作流
场景：
1.三方交互考虑，如：调用支付宝接口–>库存扣减失败–>调用支付宝退款接口。
2.一般不用，状态机啥的不会啊

6）柔性事务-最大努力通知型方案

不保证数据一定能通知成功，但会提供可查询操作接口进行核对。这种
方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种方案也是结合 MQ 进行实现，例如：通过 MQ 发送 http 请求，设置最大通知次数。达到通知次数后即不再通知。

三、3PC

3PC基于2PC引入
1.超时重传机制
2.多引入准备阶段
由于3pc不方便实现，并且也不能完全保证一致性，就不细展开。

Seata快速实现–db版

1.seata连接数据库。
1）创建库和三张表
2）数据源地址配置（在seata压缩包内）

2.seata注册进nacos，配置加载进nacos

3.各个服务引入undo表