今天面了一个java工程师，问他什么是分布式事务，感觉他没懂，希望他能看到吧

🍬博主介绍
👨‍🎓 博主主页：喵的主页
✨主攻领域：【大数据】【java】【python】【面试分析】

---

只用你能听懂的方式来讲

1. 分布式事务介绍

对一个数据库进行操作。但是当业务越来越复杂，数据量越来越大的时候，将会进行分库分表。特别是在微服务的场景下，每个服务都有自己的数据库。之前的单体事务无法处理跨库事务，这需要分布式事务来处理。

2. 分布式事务的重要性

案例流程演示

画图介绍

1）上图为下订单的一个流程，下订单成功后，从账户扣余额，从库存扣除商品数量

2）模拟在下单后，从账户扣除余额，但是在到减除库存时由于某种原因抛出异常

3）订单创建成功，账户余额扣除成功，但是库存回滚了没有扣除成功，发现管理单体事务的 @Transactional 在当前分布式事务中场景下并没有生效。没有让各个操作一起完成或一起失败。
所以分布式事务很重要

3. 分布式事务的 CAP 定理

CAP 原则又称 CAP 定理，又被称为布鲁尔定理（Brewer’s theorem），指的是在一个分布式系统中，不可能同时满足以下三点：

一致性（Consistency）

在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性（Availability）

在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

分区容错性（Partition tolerance）

大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。 分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务 器放在美国，这就是两个区，它们之间可能无法通信。

一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们， 剩下的 C 和 A 无法同时做到。
为什么P是总成立的呢？ 又为什么C 和 A 无法同时做到呢？

1. 假设你公司有两个数据中心，北京一个，纽约一个，这个就是P，它是总成立的；
2. 满足了C（一致性），就没法保证A（可用性），假如 北京 和 纽约网络出现了异常，数据不能同步了，那为了保证我的数据一致性，我必须停掉我一个中心对外提供服务，那就是要牺牲掉我一个中心的可用性了。
3. 同样的道理，如果出现了第2点的情况，我要保障我的A（可用性）那必然数据是C(不一致)的。

补充知识：
现在大部分公司都要求服务可用性达到 99.9999%好多9啊，那必然要舍弃了C（一致性）了。

为了在C（一致性）和A（可用性）之间做权衡，就诞生了BASE理论。

3. BASE介绍

BASE模型包含个三个元素：

BA：Basically Available，基本可用
系统出现了不可预知的故障，但还是能用，相比较正常的系统而言会有响应时间上的损失和功能上的损失。

S：Soft State，软状态，状态可以有一段时间不同步
什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。

软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

E：Eventually Consistent，最终一致，最终数据是一致的就可以了，而不是时时保持强一致。
上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

5. 分布式事务两种方案

5.1 XA模式

数据库支持的 2PC【2 phase commit 二阶提交】，又叫做 XA Transactions。

MySQL 从 5.5 版本开始支持，SQL Server 2005 开始支持，Oracle 7 开始支持。 其中，XA 是一个两阶段提交协议，该协议分为以下两个阶段：

第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是 否可以提交。

第二阶段：事务协调器要求每个数据库提交数据。 其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务 中的那部分信息。

优势
XA 模式比较简单，而且一旦商业数据库实现了 XA 协议，使用分布式事务的成本也比较低。
劣势
XA 性能不理想，特别是在交易下单链路，往往并发量很高，XA 无法满足高并发场景。
XA 目前在商业数据库支持的比较理想，在 mysql 数据库中支持的不太理想，mysql 的 XA 实现，没有记录 prepare 阶段日志，主备切换回导致主库与备库数据不一致。
许多 nosql 也没有支持 XA，这让 XA 的应用场景变得非常狭隘。

5.2 柔性事务-TCC 事务补偿型方案

​TCC 的基本概念​

​TCC是Try-Confirm-Cancel 的简称:

​Try阶段：​

​完成所有业务检查（一致性），预留业务资源(准隔离性)​

​Confirm阶段：​

确认执行业务操作，不做任何业务检查， 只使用Try阶段预留的业务资源。

​Cancel阶段：​

取消Try阶段预留的业务资源。

---

5.3 XA和TCC的区别

XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。

XA事务中的两阶段提交内部过程是对开发者屏蔽的，回顾我们之前讲解JTA规范时，通过UserTransaction的commit方法来提交全局事务，这只是一次方法调用，其内部会委派给TransactionManager进行真正的两阶段提交，因此开发者从代码层面是感知不到这个过程的。而事务管理器在两阶段提交过程中，从prepare到commit/rollback过程中，资源实际上一直都是被加锁的。如果有其他人需要更新这两条记录，那么就必须等待锁释放。

TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。

​TCC中的两阶段提交并没有对开发者完全屏蔽，也就是说从代码层面，开发者是可以感受到两阶段提交的存在。开发者明显的感知到了两阶段提交过程的存在。try、confirm/cancel在执行过程中，一般都会开启各自的本地事务，来保证方法内部业务逻辑的ACID特性。