原子性：事务中的所有操作，要么全部成功，要么全部失败一致性：要保证数据库内部完整性约束、声明性约束隔离性：对同一资源操作的事务不能同时发生持久性：对数据库做的一切修改将永久保存，不管是否出现故障
编辑切换为居中
添加图片注释，不超过 140 字（可选）
一、理论基础 1）CAP理论 1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标：
  • Consistency（一致性）
  • Availability（可用性）
  • Partition tolerance （分区容错性）
Eric Brewer 说，分布式系统无法同时满足这三个指标。 这个结论就叫做 CAP 定理。
编辑切换为居中
添加图片注释，不超过 140 字（可选）
CAP定理- Consistency Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致
编辑切换为居中
添加图片注释，不超过 140 字（可选）
CAP定理- Availability Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝
编辑切换为居中
添加图片注释，不超过 140 字（可选）
CAP定理-Partition tolerance
  • Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
  • Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务
编辑切换为居中
添加图片注释，不超过 140 字（可选）
2）BASE理论 BASE理论是对CAP的一种解决思路，包含三个思想：
  • Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
  • Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
  • Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
而分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论：
  • AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
  • CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态
二、分布式事务Seata 1）初识seata Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。 致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。 官网地址：http://seata.io/，其中的文档、播客中提供了大量的使用说明、源码分析。
编辑切换为居中
添加图片注释，不超过 140 字（可选）
2）Seata架构 Seata事务管理中有三个重要的角色：
  • TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
  • TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
  • RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
编辑切换为居中
添加图片注释，不超过 140 字（可选）
Seata提供了四种不同的分布式事务解决方案：
  • XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
  • TCC模式：最终一致的分阶段事务模式，有业务侵入
  • AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
  • SAGA模式：长事务模式，有业务侵入
3）微服务集成seata 1、首先，引入seata相关依赖： <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-seata</artifactId> <exclusions> <!--版本较低，1.3.0，因此排除--> <exclusion> <artifactId>seata-spring-boot-starter</artifactId> <groupId>io.seata</groupId> </exclusion> </exclusions> </dependency> <!--seata starter 采用1.4.2版本--> <dependency> <groupId>io.seata</groupId> <artifactId>seata-spring-boot-starter</artifactId> <version>${seata.version}</version> </dependency> 2、然后，配置application.yml，让微服务通过注册中心找到seata-tc-server：
编辑切换为居中
添加图片注释，不超过 140 字（可选）
三、XA模式 1）XA模式原理 XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准， XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持
编辑切换为居中
添加图片注释，不超过 140 字（可选）
编辑切换为居中
添加图片注释，不超过 140 字（可选）
2）seata的XA模式
  • seata的XA模式做了一些调整，但大体相似：
RM一阶段的工作：
  • 注册分支事务到TC
  • 执行分支业务sql但不提交
  • 报告执行状态到TC
TC二阶段的工作：
  • TC检测各分支事务执行状态
  • 如果都成功，通知所有RM提交事务
  • 如果有失败，通知所有RM回滚事务
RM二阶段的工作：
  • 接收TC指令，提交或回滚事务
编辑切换为居中
添加图片注释，不超过 140 字（可选）
六、Saga模式 Saga模式是SEATA提供的长事务解决方案。也分为两个阶段：
  • 一阶段：直接提交本地事务
  • 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚
Saga模式优点：
  • 事务参与者可以基于事件驱动实现异步调用，吞吐高
  • 一阶段直接提交事务，无锁，性能好
  • 不用编写TCC中的三个阶段，实现简单
缺点：
  • 软状态持续时间不确定，时效性差
  • 没有锁，没有事务隔离，会有脏写
编辑切换为居中
添加图片注释，不超过 140 字（可选）
四种模式对比
编辑切换为居中
添加图片注释，不超过 140 字（可选）