分布式事务

事务的ACID原则

• 原则性：事务中的所有操作要么全部成功，要么全部失败
• 一致性：要保证数据库内部完整性约束、声明性约束
• 隔离性：对同一资源操作的事务不能同时发生
• 持久性：对数据库做的一切修改将永久保存

产生的原因
几个服务不能够同时生效

CAP理论

• Consistency（一致性）
• Availability（可用性）
• Partitong tolerance（分区容错性）
  一致性：用户访问分布式系统的任意节点得到的数据必须一致
  可用性：用户访问集群中的任意健康节点，必须能得到响应不能超市或者拒绝
  分区：因为网络故障或者其他原因导致分布式系统中的部分节点与其他节点失去连接。形成独立的分区。
  容错：在集群出现分区时整个系统也要持续对外提供服务
  简述cap定理的内容
• 分布式系统节点通过连接网络一定会出现分区问题（p）
• 当分区出现时系统的一致性和可用性就无法同时满足

BASE理论

• 基本可用：分布式系统出现故障时允许失去部分可用性，即保证核心可用
• 软状态：在一定时间内允许出现的中间状态，比如临时的不一致状态
• 最终一致：虽然无法保证强一致性，但是在软状态之后最终也可以保持数据一致。

AP：各子事务分别执行和提交，允许出现结果不一致然后采用弥补措施恢复数据即可实现最终一致。
CP：各个自事务执行后相互等待同时提交同时回滚，达成强一致。但事务在等待过程中处于弱可用状态。
解决分布式事务的思想和模型

• 全局事务：整个分布式事务
• 分支事务：分布式事务中包含的每个子系统的事务
• 最终一致思想：各个分支事务分别执行提交，如果有不一致在恢复数据
• 强一致思想：各个分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚

Steata架构

Seata事务管理中三个重要角色

TC：事务协调者：维护全局和分支事务的状态 协调全局事务提交或者回滚
TM：事务管理器定义全局事务的范围、开始全局事务、提交或回滚全局事务
RM：资源管理器：管理分支事务处理的资源、与TC交谈以注册分支事务和报告粉质食物的状态、并驱动分支事务提交或回滚。

XA模式（强一致性事务）

原理：
第一阶段：tc告诉rm执行自己 的事情但是别提交
第二阶段：告诉rm提交事务或者回滚事务
如果第一阶段中有任何一个事务失败 那么另一个事务就要回滚数据恢复到以前的状态失败的那个事务就不管
具体的实现
seata的xa模式
RM第一阶段：
注册粉质食物到tc执行分支业务的sql不提交报告执行状态到tc
TC第二阶段：
TC检测各个分支的执行状态
都成功通知所有的rm提交事务
有失败通知所有的rm回滚事务

R,M二阶段工作
接收到TC指令提交或者回滚事务
优点：

• 事务的强一致性满足ACID原则
• 常用的数据库都支持没有代码的侵入

缺点：

• 因为一阶段要锁定数据库的资源等二阶段结束才能释放 性能较差
• 依赖关系型数据库实现事务

AT模式（）

分阶段提交的事务模型
第一阶段TM开启全局事务开启全局事务完成事务注册调用每个分支 rm注册分支事务执行sql并提交由rm拦截记录更新前后的快照undolog 报告事务的状态到tc

第二阶段提交或者回滚全部事务 检查分支事务状态提交事务成功删除log失败恢复log数据删除log

优点：

• 一阶段完成直接提交事务释放数据库资源性能好
• 利用全局锁实现隔离
• 没有代码侵入 框自动回滚和提交
  缺点：
• 两阶段之间属于软状态属于最终一致
• 框架的快照会影响性能，但是比XA模式要好很多

AT模式和XA模式最大的区别

• XA模式一阶段不提交事务锁定资源；AT模式一阶段直接提交不锁定资源
• XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚
• XA模式强一致，AT模式最终一致

脏写问题

解决方案：全局锁

TCC模式（最终一致）

• try ：资源的检测和预留
• confirm：完成资源操作业务 要求try成功confirm一定要成功
• cancel：预留资源释放，可以理解为try的反向操作

TCC有点：

• 一阶段完成直接提交事务释放数据库资源性能好
• 相比at模型无需生成快照，无需使用全局锁性能最强
• 不依赖数据库事务 而是依赖补偿操作 可以用于非事务性数据库
  Tcc缺点
• 有代码侵入需要人工编写try confirm和cancel接口太麻烦
• 需要考虑confirm和cancel的失败情况做好幂等处理
• 软状态，事务是最终一致
  Tcc空回滚和业务悬挂