分布式事务

分布式事务

概念：在分布式系统环境下由多个服务通过网络通信协作去完成一次事务，这称之为分布式事务。可简单理解为一个分布式事务等于多个本地事务。

用户创建订单，客户端请求交易服务创建订单

创建订单成功，交易服务请求购物车服务清理购物车，请求库存服务空间库存

由于订单、购物车、商品分别是三个不同的微服务，而每个微服务都有自己独立的数据库，一次下单事务需要订单、购物车、商品服务分别执行自己的本地事务，是跨多个数据库完成这次下单的事务，像这种，就可以理解为分布式事务。

分布式事务的典型场景是：业务的数据分布再多个数据库，一次事务操作需要跨多个数据库完成，需要由多个服务远程调用协作去完成，远程调用依赖网络，由于网络问题会导致整体事务不能正常完成。

什么是本地事务

基于应用自己的关系型数据库的事务称为本地事务，再service方法通过添加@Transactional注解进行本地事务控制

什么是分布式事务

再分布式系统环境下有多个服务通过网络通信协作去完成一次事务，者称之为分布式事务。

分布式事务的场景：

多个微服务之间通过远程调用完成一次分布式事务，即：跨服务完成一次事务

单服务请求多数据库完成一次事务，即：跨数据源完成一次事务

多服务请求但数据库完成一次事务，即：跨服务完成一次事务

CAP原理

事务的特性（ACID）

原子性(atomicity)：“原子”的本意是“不可再分”，事务的原子性要求事务中的所有操作要么都执行，要么都不执行。

一致性(consistency)：一致指的是数据的一致，具体是指：所有数据都处于满足业务规则的一致性状态。一致性原则要求：一个事务中不管涉及到多少个操作，都必须保证事务执行之前数据是正确的，事务执行之后数据仍然是正确的。如果一个事务在执行的过程中，其中某一个或某几个操作失败了，则必须将其他所有操作撤销，将数据恢复到事务执行之前的状态，这就是回滚。

隔离性(isolation)：在应用程序实际运行过程中，事务往往是并发执行的，所以很有可能有许多事务同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏。隔离性原则要求多个事务在并发执行过程中不会互相干扰。

持久性(durability)：持久性原则要求事务执行完成后，对数据的修改永久的保存下来，不会因各种系统错误或其他意外情况而受到影响。通常情况下，事务对数据的修改应该被写入到持久化存储器中。

事务的隔离级别

事务并发引起一些读的问题
脏读：一个事务可以读取另一个事务未提交的数据;
不可重复读：一个事务可以读取另一个事务已提交的数据 单条记录前后不匹配;
幻读:：一个事务可以读取另一个事务已提交的数据 读取的数据前后多了点或者少了点

并发写：使用mysql默认的锁机制（独占锁）
解决读问题：设置事务隔离级别

事务的传播

CAP的原理：CAP是 Consistency、Availability、Partition tolerance三个词语的缩写，分别表示一致性、可用性、分区容忍性。

一致性：向系统写一个新数据再次读取到的也一定是这个新数据。如上图，请求订单服务下单，订单服务请求库存服务扣减库存，只要下单成功则库存扣减成功

可用性：任何时间都可以访问订单服务和库存服务，系统保证可用

分区容忍性：也叫分区容错性，分布式系统在部署时服务器可能部署在不同的网络分区，比如上图中订单服务在北京，库存服务在上海，由于处于不同的网络分区如果网络通信异常就会导致节点 之间无法通信，当出现由于网络问题导致节点 之间无法通信，此时仍然是对外提供服务的这叫做满足分区容忍性。

CAP理论要强调在分布式系统中C、A、P这三点不能全部满足。

由于是分布式系统，就要满足分区容忍性，因为分布式系统难免存在网络分区，不能因为网络异常导致整个系统不可用，所以p是一定要满足的。

满足P，那么A和C不能同时满足

CAP理论进行分布式事务控制要在C和A中做出取舍，进行分布式事务控制，要么保证CP要么保证AP。具体要根据应用场景进行判断

BASE定理
BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

Basically Available（基本可用）
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。

Soft state（软状态）
软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

Eventually consistent（最终一致性）
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
BASE模型是传统ACID模型的反面，不同于ACID，BASE强调牺牲高一致性，从而获得可用性，数据允许在一段时间内的不一致，只要保证最终一致就可以了。

安装Seata

解决分布式事务的方案有很多，但实现起来都比较复杂，因此我们一般会使用开源的框架来解决分布式事务问题。再众多的开源分布式事务框架中，功能最完善、使用最多的就是阿里巴巴再2019年开源的Seata了。

其实分布式事务产生的一个重要原因，就是参与事务的多个分支事务互相无感知，不知道彼此的执行状态。因此解决分布式事务的思想非常简单：

就是找一个统一的事务协调者，与多个分支事务通信，检测每个分支事务的执行状态，保证全局事务下的每一个分支事务同时成功或失败即可。大多数的分布式事务框架都是基于这个理论来实现的。

Seata也不例外，再Seata的事务管理中有三个重要的角色：

• TC(Transaction Coordinator)-事务协调者：维护全局和分值事务的状态，协调全局事务提交或回滚，相当于监控中心。
• TM (Transaction Manager)-事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
• RM (Resource Manager)-资源管理器：管理分支事务，与TC交谈已注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata的工作架构

其中，TM和RM可以理解为Seata的客户端部分，引入到参与事务的微服务依赖中即可。将来TM和RM就会协助微服务，实现本地分支事务与TC之间交互，实现事务的提交或回滚。

而TC服务则是事务协调中心，是一个独立的微服务，需要单独部署。

Seata支持四种不同的分布式事务解决方案：

• XA
• TCC
• AT
• SAGA

这四种方案可以满足CP和AP的需求，比如：XA可以实现CP即强一致性，AT可以实现AP最终一致性，四种模式中AT模式使用较多，本课程重点讲解AT模式。

根据Seata的结构首先需要安装TC事务协调器。

微服务集成Seata

1、引入依赖

<!--seata-->
  <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
  </dependency>

2、引入Seata配置

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    type: nacos # 注册中心类型 nacos
    nacos:
      server-addr: 192.168.101.68:8848 # nacos地址
      namespace: "" # namespace，默认为空
      group: DEFAULT_GROUP # 分组，默认是DEFAULT_GROUP
      application: seata-server # seata服务名称
  tx-service-group: hmall # 事务组名称
  service:
    vgroup-mapping: # 事务组与tc集群的映射关系
      hmall: "default"

3、在需要事务控制的地方加上@GlobalTransactional注解

@GlobalTransactional注解就是在标记事务的起点，将来TM就会基于这个方法判断全集事务范围，初始化全局事务

Seata工作模式

Seata支持四种不同的分布式事务解决方案，Seata默认使用的是AT模式。

• XA
• TCC
• AT
• SAGA

这里我们以XA模式和AT模式来给大家讲解其实现原理。

阶段一RM的工作：

• 注册分支事务
• 记录undo-log（数据快照）
• 执行业务sql并提交
• 报告事务状态

阶段二提交时RM的工作：

• 删除undo-log即可

阶段二回滚时RM的工作：

• 根据undo-log恢复数据到更新前

XA模式

XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。

XA是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。

正常情况下：

异常情况下：

一阶段：

• 事务协调者通知每个事务参与者执行本地事务
• 本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

二阶段：

• 事务协调者基于一阶段的报告来判断下一步操作
• 如果一阶段都成功，则通知所有事务参与者，提交事务
• 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务

Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：

XA模式的优点是什么？

• 事务的强一致性，满足ACID原则
• 常用数据库都支持，实现简单，并且没有代码侵入

XA模式的缺点是什么？

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

简述AT模式与XA模式最大的区别是什么？

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

TCC模式

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：

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

Seata中的TCC模型依然延续之前的事务架构，如图：

TCC模式的每个阶段是做什么的？

• Try：资源检查和预留
• Confirm：业务执行和提交
• Cancel：预留资源的释放

TCC的优点是什么？

• 一阶段完成直接提交事务，释放数据库资源，性能好
• 相比AT模型，无需生成快照，无需使用全局锁，性能最强
• 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

TCC的缺点是什么？

• 有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
• 软状态，事务是最终一致
• 需要考虑Confirm和Cancel的失败情况，做好幂等处理