事务的ACID原则

事务的ACID原则

分布式事务：
在分布式系统下，一个业务跨越多个服务或数据源，每个服务都是一个分支事务，要保证所有分支事务最终状态一致

跨数据源的分布式事务
跨服务的分布式事务
综合情况

分布式系统有三个指标。

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致
Availability（可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝
Partition tolerance （分区容错性）：

Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。 Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

分布式系统无法同时满足这三个指标，这个结论就叫做 CAP 定理。

CAP定理：
•分布式系统节点通过网络连接，一定会出现分区问题（P）
•当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足
ES集群出现分区时，故障节点会被剔除集群，数据分片会重新分配到其它节点，保证数据一致。因此是低可用性，高一致性，属于CP
BASE理论是对CAP的一种解决思路，包含三个思想：
•Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
•Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
•Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
而分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论：
•AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
•CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。
解决分布式事务的思想和模型：
•全局事务：整个分布式事务
•分支事务：分布式事务中包含的每个子系统的事务
•最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据
•强一致思想：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚
Seata：是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的一站式的分布式解决方案。
官网地址：http://seata.io/
Seata事务管理中有三个重要的角色：
•TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
•TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
•RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata提供了四种不同的分布式事务解决方案：
•XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
•TCC模式：最终一致的分阶段事务模式，有业务侵入
•AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
•SAGA模式：长事务模式，有业务侵入
微服务集成Seata：
1）引入seata相关依赖：

<!--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>
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <!--seata starter 采用1.4.2版本-->
    <version>${seata.version}</version>
</dependency>

2）配置TC地址
在order-service中的application.yml中，配置TC服务信息，通过注册中心nacos，结合服务名称获取TC地址：

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

注册到Nacos中的微服务，确定一个具体实例需要四个信息：

namespace：命名空间
group：分组
application：服务名
cluster：集群名

XA规范：

一阶段：

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

二阶段：

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

seata的XA模式

XA模式的优点

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

XA模式的缺点

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

Seata的starter完成XA模式的自动装配步骤：
1）修改application.yml文件（每个参与事务的微服务），开启XA模式：

seata:
  data-source-proxy-mode: XA    # 开启数据源代理的XA模式

2）给发起全局事务的入口方法添加@GlobalTransactional注解:

3）重启服务并测试

AT模式原理：同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
Seata的AT模型

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

解决脏写：

AT模式的优点：

  - 一阶段完成直接提交事务，释放数据库资源，性能比较好
  - 利用全局锁实现读写隔离
  - 没有代码侵入，框架自动完成回滚和提交

AT模式的缺点：

  - 两阶段之间属于软状态，属于最终一致
  - 框架的快照功能会影响性能，但比XA模式要好很多

实现AT模式：AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，
只需要一个表来记录全局锁、另一张表来记录数据快照undo_log。
1）导入数据库表，记录全局锁
2）修改application.yml文件，将事务模式修改为AT模式：

seata:
  data-source-proxy-mode: AT # 默认就是AT

3）重启服务并测试

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

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

原理示例：

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

SAGA模式
分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

Saga也分为两个阶段：

     - 一阶段：直接提交本地事务
     - 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚

优点：

  - 事务参与者可以基于事件驱动实现异步调用，吞吐高
  - 一阶段直接提交事务，无锁，性能好
  - 不用编写TCC中的三个阶段，实现简单

缺点：

  - 软状态持续时间不确定，时效性差
  - 没有锁，没有事务隔离，会有脏写