分布式事务概览
分布式理论
- 前置理论知识：
- CAP
- C 强一致性 主节点写入新的数据，必须能从从节点读到最新数据，否则错误
- A 可用性 保证每个服务尽可能都能响应结果
- P 分区容忍性 正常情况下，服务节点之间通信是正常的，可能因为网络原因，节点之间通信失败，将整个服务分成了多个区，仍然可以保证整个服务的运行
- BASE
- basically Available 基本可用 系统出现故障，保证核心功能可用
- Soft state 软状态 出现一个中间状态，表示动作进行中
- eventually consistent 最终一致性
- CAP
2pc 两阶段提交（协议）
主要角色
事务管理器（协调者 tm）
事务管理器作为全局事务的协调管理者，与每个资源管理器通信，完成分布式事务的管理。
资源管理器 （参与者 rm ）
资源管理器管理每个参与者的事务资源，其应该具有提交和回滚的能力，如数据库。
解决方案
XA方案（实现） 适用于实现了xa协议的数据库，像oracle，mysql5.0之后的版本都实现了xa协议
- 开启xa connection 全局事务
- tm 发送 xa start命令给rm，rm执行各自的逻辑，rm执行完各自的逻辑
- tm再次发送 xa end和 xa prepare，如果rm都响应ok, 表示各个rm已达到准备状态，tm发送commit命令，如果有rm响应失败，则发送rollback命令回滚
缺点：
- 要求rm必须实现XA协议
- tm会对修改资源进行锁定，知道两个阶段结束才会释放锁资源。
- 因为网络不稳定，也会导致部分数据未执行commit或rollback命令
分布式事务
- 原因：分布式情况下，多个服务需要执行自己的本地事务来完成一个大的整体事务，因为网络不稳定等原因，会出现服务之间数据不一致情况
- 如何解决分布式下数据的一致性
- 强一致性 XA
- 弱一致性
- 不使用事务，业务侧采用补偿方式，最终保证一致性
- 柔性事务，最终保证一致性
- tcc
- 概念：tcc相当于把xa的逻辑放到了业务侧来做，分为三个阶段，每个阶段需要业务代码实现，对代码的侵入性高
- 三个阶段
- try 完成业务检查，预留业务资源 （拿转账举例，A给B转账100，先冻结A的100,100就是预留的业务资源）
- confirm 执行真正业务，只是用try阶段预留的业务资源，所以只要try能成功，confirm必定成功
- cancel 取消try阶段预留的业务资源
- 注意问题
- 允许空回滚：当多个rm执行try时，某个rm有可能出现异常或者超时导致try没有执行成功，那么需要将所有rm进行cancle操作，那没有执行try的rm不能执行cancle了，只能要求空回滚。
- 防悬挂控制：try和cancle的乱序问题 ，因为网络的原因，cancle操作可能会比try更早来到执行，cancle因为有空回滚所以不会执行，而try阶段也不需要执行，这个就叫悬挂。
- 接口幂等性：因为try，confirm，cancle可能都有重试的可能，所以需要保证接口幂等性
- 场景：高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景
- saga
- 概念：对于tcc，没有try阶段，直接执行事务，如果其中一个rm错误，那么当前rm开始回滚。
- 场景：适合长事务，复杂业务的场景
- at
- 两阶段提交模式
- 第一阶段，执行业务sql之前，备份旧数据，然后执行业务sql（或者在执行业务数据的时候生成反向sql）
- 第二阶段，如果没问题则直接提交，如果有问题，则利用旧数据或反向sql回滚
- 场景：无侵入，不希望对业务改造的场景
- 两阶段提交模式
- tcc
seata流程
如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。
在 Seata 中，分布式事务的执行流程：
- TM 开启分布式事务（TM 向 TC 注册全局事务记录）；
- 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）；
- TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；
- TC 汇总事务信息，决定分布式事务是提交还是回滚；
- TC 通知所有 RM 提交/回滚 资源，事务二阶段结束；