分布式事务相关理论

聪明不完全决定于智商，更多在于是否能坚持刻意练习，尽可能多地建立优质的心理表征。

1. ACID

说到事务就不得不提事务的 ACID 特性，理解了事务的 4 个特性基本就理解了事务：

• A（Atomicity）：原子性，一个事务的所有操作要么同时成功，要么同时失败，不可能出现部分成功的情况。

假设事务的操作为从 A 账号向 B 账号转账 100元，则需要两个步骤：

1. A 账号扣除 100元
2. B 账号增加 100元

原子性保证步骤1和步骤2同时成功或同时失败，不会出现步骤1成功，步骤2失败的情况。

• C（Consistency）：一致性，事务提交前和提交后系统数据是一致的， 事务的 AID 保证了 C；

同样 A 账号向 B 账号转 100元，则事务前和事务后账号 A 和账号 B 的总金额一致。

• I（Isolation）：隔离性，多个事务并行读取和修改某块共享数据时，则事务之间的操作是隔离的；

假设 ticketId = 1 的门票初始化 ticketNum = 100，事务隔离级别为 RR

事务A	事务B
begin;	begin;
update set ticketNum = ticketNum -1 where ticketId = 1;
	update set ticketNum = ticketNum -1 where ticketId = 1;
rollback；	commit；

如果事务A 和 事务B 不隔离，则在只有事务B 执行成功的情况下，门票的数量就只剩 98，这在实际应用中是肯定不允许的。

• D（Durability）：持久性，事务一旦提交成功，结果一定会永久保存。

这个比较好理解，事务提交成功后，系统崩溃，除非硬盘损坏，否则系统恢复后，提交后的数据一定不会丢失。

MySQL 如何保证本地事务可参考：MySQL 如何保证 ACID

2. 分布式事务

随着互联网用户不断增长，以前集中式的计算机系统架构已不能适应当前互联网环境，近年来分布式系统架构越来越盛行，在提高系统容量的同时，也带来了很多问题。如：

• 通信异常：服务节点之间通过互联网通信，存在网络延迟过大、甚至无法通信（光纤被人为或意外挖断等）导致通信异常；
• 网络分区（脑裂）：服务节点之间通信异常会导致各服务器被分割在不同的网络分区内；
• 三态：在分布式网络中存在成功、失败和超时三种状态，成功和超时是确定的状态，超时是不确定的状态，存在以下 3 种可能：

1. 存在可能性：如处理成功，确认消息丢失；
2. 未收到消息，根本就没处理；
3. 处理失败，失败消息丢失。

• 节点故障：某个服务节点发生异常，不能对外提供服务。

2.1 相关理论

2.1.1 CAP 定理

• C（Consistency）：一致性，指多个数据副本对外始终保持一致；
• A（Availability）：可用性，指系统一直可用的状态；
• P（Partition tolerance）：分区容错性，指系统允许发生网络分区故障

Partition tolerance 比较难解释，这里用到的是 《A Critique of the CAP Theorem》 中的解释
Thus, we can interpret partition tolerance as meaning “a network partition is among the faults that are assumed to be possible in the system.” Note that this definition of partition tolerance is a statement about the system model, whereas consistency and availability are properties of the possible executions of an algorithm. It is misleading to say that an algorithm “provides partition tolerance,” and it is better to say that an algorithm “assumes that partitions may occur.”

CAP 定理指出我们只能同时满足 CAP 中的 2 者，即保证 CA、CP、AP：

• 保证 CA
  分布式系统的网络分区故障是无法避免的，所以只能保证发生分区故障时，各个独立分区系统内的一致性和可用性；
• 保证 CP
  在发生分区故障时，舍弃服务的可用性，即可保证各分区的数据一致性。如涉及到钱财相关，如支付系统、银行系统等，对一致性有严格的要求；
• 保证 AP
  在发生分区故障时，各个分区使用本地的数据对外提供服务，各分区之间的一致性无法得到保障。对于一般的展示信息，如商品信息、订单信息等，只要保证绝大多数情况下系统数据完全一致（一般要求 N 个 9），数据最终一致即可。

因分布式系统一定存在发生分区故障的风险，所以现在的分布式系统理论都在寻求 C 和 A 之间的平衡。银行等金融系统在发生分区故障时，必须严格保证 C，完全舍弃 A；电商系统可在损失一定 C 的情况下保证 A。

2.1.2 BASE 理论

BASE 理论即Basically Available、Soft state、Eventually consistent 3 个词组的缩写，即：

• BA（Basically Available）：基本可用，即在系统发生故障或资源紧张时，系统仍能提供有损的服务：

1. 功能的损失：淘宝双十一高峰期间不能查找历史订单等；
2. 响应时间的损失：原先接口的相应时间为 0.1s，系统故障发生时，响应时间可能延长到 1s 异常。

• S（Soft state）：软状态，允许系统中的数据在一定时间内处于中间状态，比如用户购买商品时，在扣除用户账户金额后，立即下单成功，商户账户余额增加金额可放到消息队列中，等系统压力小些时候处理；
• E（ Eventually consistent）：最终一致性，系统中的所有数据副本在一定时间后，一定能达到一致的状态。
  BASE 是对 CAP 中 C 和 A 权衡的结果，核心思想是即使无法保证强一致性，但每个应用可根据自身的业务特点，采用释放的方式来使系统达到最终一致性。

2.2 一致性协议

2.2.1 2PC：Two-Phase Commit

两阶段提交，即将事务的提交过程分成了两个阶段来处理，是最简单也是代价最小的（通信量为非事务的 4 倍）。

• preCommit 阶段，协调者发起事务，参与者评估是否可以完成，如果可以完成则锁住资源，写 redo、undo 日志，执行操作，但不提交；如果准备成功返回 yes，否则返回 no；
• doCommit 阶段，如果 preCommit 阶段所有的参与者都响应 yes，协调者发送提交事务命令，参与者执行提交操作，释放 preCommit 阶段锁住的资源；参与者响应是否提交成功，成功返回 yes，否则返回 no。

如果 preCommit 阶段任一参与者响应 no，则 doCommit 阶段协调者发送回滚事务命令

两阶段提交的问题：

• 同步阻塞：参与者在执行完 preCommit 阶段后，就一直锁住资源，直到 canCommit 阶段执行成功才会释放资源；
• 单点问题：事务依赖协调者，当参与者执行完 preCommit 阶段锁住资源，协调者发生故障，则所有参与者都一直阻塞；
• 数据不一致：当阶段一成功，在执行 canCommit 阶段时某个参与者故障未收到提交事务消息，其他参与者都提交了事务，则数据都不能

2.2.2 3PC：Three-Phase Commit

三阶段提交，过程如下：

• canCommit：协调者询问参与者是否可提交，如果可以提交，锁住资源，并返回 yes；

canCommit 阶段不会提交任何不做任何修改操作，只是询问和锁定资源

• preCommit：协调者收到所有参与者在 canCommit 阶段都返回 yes，则发送 preCommit 消息，参与者执行事务，但不提交，并返回 yes；
• doCommit：协调者收到所有参与者在 preCommit 阶段都返回 yes，则发送 doCommit（提交事务）消息，参与者提交事务，并返回 yes。

当 canCommit 阶段有参与者返回 false 或 超时未响应，则协调者发送中断事务的消息给参与者：

• 与协调者通信正常的参与者：收到中断消息中断事务
• 与协调者通信异常的参与者：过了超时时间未收到协调者的 preCommit 消息，自动中断事务
• 如果协调者在发送 canCommit 消息后发送故障，则所有参与者超时后自动中断事务

因 canCommit 阶段未做数据修改，因此直接中断即可

---

当 preCommit 阶段有参与者返回 false 或超时未响应，则协调者发送回滚事务消息：

• 与协调者通信正常的参与者：收到回滚消息回滚事务
• 与协调者通信异常的参与者：因网络故障无法收到回滚消息，超时时间后自动提交事务
• 如果协调者在发送 canCommit 消息后发送故障，则所有参与者超时后自动提交事务

---

从这里可以看出，3PC 并不能解决数据一致性的问题。

3PC 和 2PC 的区别：
参考 Three-phase commit protocol (3PC)：

• 3PC 引入超时自动中断事务或回滚事务机制：3PC 的 canCommit 阶段超时未收到 preCommit 消息只能选择中断事务，preCommit 阶段超时未收到 doCommit 消息，则大概率是继续提交事务，故超时够参与者会自动提交事务。引入超时机制，减少了 2PC 一直阻塞的问题。

为什么不直接在 2PC 引入超时机制呢？看下面这一条

• 3PC 将 2PC 的 preCommit 阶段拆分成 canCommit 和 preCommit 两个阶段：2PC 协议中参与者处于 preCommit 成功阶段，无法确定是否继续提交，还是回滚，所以如果部分参与者处于 preCommit 成功状态，部分参与者和协调者断开网络通信，则处于 preCommit 状态的参与者不能简单地做提交 或 回滚操作，所以只能阻塞等待，继续锁住资源。3PC 将 preCommit 阶段拆成 canCommit 和 preCommit 两个阶段，如果参与者处于 canCommit 成功阶段与协调者断开网络通信，因未修改数据，超时时间后只能选择中断事务，释放锁住的资源；如果参与者处于 preCommit 成功阶段与协调者断开网络通信，因 canCommit 阶段成功（canCommit 阶段已经成功锁住资源），可以认为 preCommit 阶段大概率都是成功的，因此在超时时间后，参与者会自动提交事务，并释放锁住的资源。引入超时自动中断或自动提交机制，解决了 2PC 的单点问题。
  

2.2.3 Paxos

2.3 常见分布式事务解决方案

https://zhuanlan.zhihu.com/p/78599954

2.2.3 TCC：Try-Confirm-Cancel

TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。
Try：预留资源
Confirm：
Cancel：

2.2.5 XA 协议

XA 协议是资源管理器（数据库）与事务管理器的接口标准，目前主要的数据库厂商都提供了对 XA 的支持。

XA 协议相关的一些基本操作（百度百科）：
1）xa_open,xa_close：建立和关闭与资源管理器的连接。
2）xa_start,xa_end：开始和结束一个本地事务。
3）xa_prepare,xa_commit,xa_rollback：预提交、提交和回滚一个本地事务。
4）xa_recover：回滚一个已进行预提交的事务。
5）ax_开头的函数使资源管理器可以动态地在事务管理器中进行注册，并可以对XID(TRANSACTION IDS)进行操作。
6）ax_reg,ax_unreg；允许一个资源管理器在一个TMS(TRANSACTION MANAGER SERVER)中动态注册或撤消注册。

基本组成：

3. 参考

1. 分布式事务——2PC、3PC 和 TCC
2. A Critique of the CAP Theorem
3. XA 分布式事务原理