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 将根据事务最终状态和事务组的信息 来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。
网友评论