1.分布式事务概论

1.常规事务

1.1事务特性（刚性事务）

A(Atomicity)：原子性
C(Consistency)：一致性
I(Isolation)：隔离性
D(Durability)：持久性

1.2事务形式

编程式：
使用 TransactionTemplate 或者直接使用底层的 TransactionManager 来操作事务 commit 或者 rollback。
声明式：
建立在 AOP 基础上，通过对方法前后进行拦截，加入编程式事务里的流程控制逻辑。使用的时候只需要在方法前面加上@Transactional 注解

2.分布式事务

2.1 概念

就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用。在这种环境中，我们之前说过数据库的 ACID 四大特性，已经无法满足我们分布式事务。

本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

2.2 CAP理论

一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。

在一个分布式系统中，最多只能满足 C、A、P 中的两个，不可能三个同时满足。

分布式系统中，网络无法 100% 可靠，分区(P)其实是一个必然现象。
任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性(CP)与可用性(AP)之间做出选择。

2.3 BASE理论

往往在分布式系统中无法实现完全一致性，于是有了 BASE 理论，它是对 CAP 定律的进一步扩充

Basically Available(基本可用) : 分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用
Soft state(软状态) : 允许系统中存在中间状态，这个状态不影响系统可用性
Eventually consistent(最终一致性) : 经过一段时间后，所有节点数据都将会达到一致

BASE和ACID对比：
BASE 和 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

2.4 2PC

流程图

image.png

第一阶段：
每个请求发出预备提交请求，并作出相应的应答，如果都成功，进行第二阶段。
第二阶段：
每个请求发出提交请求，并作出相应应答，如果成功，代表commit完成，有一个不成功，回滚。

优点：
尽量保证了数据的强一致，实现成本较低，在各大主流数据库都有自己实现，对于 MySQL 是从 5.5 开始支持。

缺点：

单点问题 : 事务管理器在整个流程中扮演的角色很关键，如果其宕机，比如在第一阶段已经完成，在第二阶段正准备提交的时候事务管理器宕机，资源管理器就会一直阻塞，导致数据库无法使用。

同步阻塞 : 在准备就绪之后，资源管理器中的资源一直处于阻塞，直到提交完成，释放资源。

数据不一致 : 两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能。
比如在第二阶段中，假设协调者发出了事务 Commit 的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了 Commit 操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。

两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。

2.5 3PC

2PC改进版本，将事务的提交过程分为CanCommit、PreCommit、do Commit三个阶段来进行处理

image.png

第一阶段CanCommit（这一阶段主要是确定分布式事务的参与者是否具备了完成 commit 的条件，并不会执行事务操作）
询问是否可以提交事务CanCommit，如果可以反馈YES，否则反馈NO。

第二阶段PreCommit
1.当所有参与者均反馈YES，即执行事务预提交（PreCommit）
2.任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务。

第三阶段do Commit
1.所有参与者均反馈Ack响应，即执行真正的事务提交
2.任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务

3PC对比2PC:
注意:在阶段三，可能会出现 2 种故障:协调者出现问题/协调者和参与者之间的网络故障,一段出现了任一一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针对这种情况，参与者都会在等待超时之后，继续进行事务提交。
优点：
最大的优点是减少了参与者的阻塞范围(第一个阶段是不阻塞的)，能够在单点故障后继续达成一致(2PC 在提交阶段会出现此问题，而 3PC 会根据协调者的状态进行回滚或者提交)。
缺点：
如果参与者收到了 preCommit 消息后，出现了网络分区，那么参与者等待超时后，都会进行事务的提交，这必然会出现事务不一致的问题

2.6 TCC

TCC 其实就是采用的补偿机制，其 核心思想 是:
针对每个操作，都要注册一个与其业务逻辑对应的确认和补偿(撤销)操作。其将整个业务逻辑的每个分支显式的分成了 Try、Confirm、Cancel 三个操作。

Try 部分完成业务的准备工作
confirm 部分完成业务的提交
cancel 部分完成事务的回滚

image.png

优点:
跟 2PC 比起来，实现以及流程相对简单了一些，但数据的一致性比 2PC 也要差一些
缺点:
TCC 属于 应用层 的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，而且补偿的时候也有可能失败，在一些场景中，一些业务流程可能用 TCC 不太好定义及处理。

3.分布式事务框架

3.1 LCN

LCN 并不生产事务，LCN 只是本地事务的协调工
TX-LCN 定位于一款事务协调性框架，框架其本身并不操作事务，而是基于对事务的协调从而达到事务一致性的效果

原理：
TX-LCN 由两大模块组成： TxClient、TxManager
原理流程图：

image.png

1.创建事务组
是指在事务发起方开始执行业务代码之前先调用 TxManager 创建事务组对象，然后拿到事务标示 GroupId 的过程。
2.加入事务组
添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息通知给 TxManager 的操作。
3.通知事务组
是指在发起方执行完业务代码以后，将发起方执行结果状态通知给 TxManager,TxManager 将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。