分布式事务Seata的理解，分布式事务面试题

学习分布式事务之前，先了解一下什么是分布式事务

1. 什么是分布式事务及作用？

分布式事务
分布式事务是指事务的参与者，支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上，且属于不同的应用，分布式事务需要保证这些操作要么全部都执行成功，要么都执行失败。本质上来说，分布式事务就是为了保证不同的数据库的数据一致性。

本地事务
单一的服务操作做为一个事务，那么整个服务操作只能涉及一个单一的数据库资源，这类基于单个服务单一数据库资源访问的事务，被称为本地事务

数据库事务（Transaction）
事务就是用户定义的一系列的数据库操作，这些操作可视为一个完整的逻辑处理工作单元，要么全都执行，要么全都不执行，是不可分割的工作单元

例如：转成操作，用户A向用户B转账1个亿，用户A账户减掉1个亿余额，用户B增加1个亿的余额

• update user set money - 1个亿 where usernmae = ‘用户A’
• update user set money + 1个亿 where username = ‘用户B’

这两条sql语句要么同时成功，要么同时失败。如果第一条sql执行失败，则回滚事务，用户A的还原。否则数据将会丢失，用户A丢失1个亿。

2. 分布式事务相关理论

2.1 CAP定理

分布式系统有三个指标

• Consistency：一致性
• Availability：可用性
• Partition tolerance：分区容错性

这三个指标不可能同时满足，这个定理就叫CAP定理，分区容错性是必须满足的，可用性和一致性可用按需求选择。

分区容错性 Partition tolerance
理解：分布式系统集群中，一个服务挂掉了不影响其他的服务
可用性 Availability
理解：一个请求，必须返回一个响应，意思就是只要收到用户的请求，服务器就必须给出回应
一致性 Consistency
理解：一定能够读到最新的数据，意思是写之后的读操作，必须返回该写入的值

一致性分类

• 强一致性：要求更新过后的数据能被后续的访问都能够看到
• 弱一致性：能容忍后续部分或者全部访问不到
• 最终一致性：经历过一段时间后，要求更改访问到更新后的数据
  CAP中说的一致性指的是强一致性

一致性和可用性的矛盾
一致性和可用性为什么不能同时成立呢？因为可能出现通信失败（即分区容错性）
举例：
一致性问题：用访问数据库A修改了一条数据，数据库A需要通知数据库B同步数据，这个过程中，数据库B是锁住的，用户就会获取不到数据。

可用性问题：用访问数据库A修改了一条数据，用户下一次请求到数据库B，这条数据还没更新过来，拿到的就不是最新的数据，如果采用了一致性，则这时候数据库B可能会上了锁，拿不到数据返回，这就没有可用性这么一说了，这两个指标不可能同时达成，只能根据需要选择一种
如果CAP三个特性都满足，那么是单机系统，不是集群，不是分布式

2.2 BASE理论

全称：Basically Available（基本可用），Soft state（软状态），和 Eventually consistent（最终一致性）三个短语的缩写，BASE理论是对CAP中一致性和可用性权衡的结果，核心思想是：即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性

基本可用（Basically Available）
理解：允许服务降级或者允许响应的时间受到一定的损失
软状态（Soft state）
理解：允许同步数据的时候出现一定的时间延迟
最终一致性（Eventually consistent）
理解：经过一段时间的同步数据之后，最终都能达到一个一致的状态

3. 分布式事务解决方案

• AT
• TCC
• XA
• SAGA

使用MQ解决分布式事务（消息最终一致性）
使用MQ，发送异步消息，把分布式事务拆分称本地事务，只要两边事务确保执行成功，就没有问题。生产者确保消息发送成功，消费者确保消息消费成功，如果失败，则进行重试，如果一直重试失败，则是代码上或者业务上的处理出了问题，需要人工介入。

AT 模式分布式事务概念
通过一张undo_log表来记录回滚日志信息，在执行更新的sql语句之前，先通过这个sql语句生产一条查询语句，查询出前镜像，再执行更新的sql，执行完之后，通过前镜像的id查询出后镜像，把前后镜像加上业务逻辑的sql生产一条回滚日志信息的记录，插入到回滚日志信息表。将来需要回滚数据，就是通过这张表的数据来进行回滚，通过这个回滚日志信息，生产一个update语句，把数据更新回来，这样就完成了回滚的操作。 回滚的方式是反向补偿。

XA 模式分布式事务概念
利用本地事务的机制，回滚是本地事务回滚，提交是本地事务提交。由TC通知统一进行回滚，由TC通知统一进行提交。是真正的数据库回滚操作。

TCC 模式分布式事务概念
AT和TCC的区别：

AT 需要支持本地事务，提交和回滚的操作不需要自己操作

• 一阶段 prepare 行为：本地事务中，一并提交业务数据更新和相应的回滚日志记录
• 二阶段 commit 行为：马上成功结束，异步批量删除回滚记录，（自动）
• 二阶段 rollback 行为：通过回滚日志记录，生成补偿策略，（自动）

TCC 不需要支持本地事务，提交和回滚的操作需要自己实现

• 一阶段 prepare 行为：调用自定义的 prepare 的逻辑 （手动）
• 二阶段 commit 行为：调用自定义的 commit 的逻辑 （手动）
• 二阶段 rollback 行为：调用自定义的 rollback 的逻辑（手动）

理解：所谓的TCC模式，就是把自定义分支事务纳入到全局事务中来管理，如果当前系统不支持本地事务，可用采用TCC模式。

SAGA模式分布式事务概念
SAGA是一个长事务解决方案

使用场景：

• 业务流程多，业务流程长
• 参与者包含其他公司或遗留系统服务，无法提供TCC模式的3个接口

优势：

• 一阶段本地提交，无锁，高效率
• 事件驱动架构，参与者可异步执行，高吞吐
• 补偿服务易于实现

缺点：无法保证隔离性