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
原理流程图：