分布式事务两阶段提交

分布式事务两阶段提交。

一、分布式数据库的一致性

分布式数据库有所谓CAP理论，即一致性（ Consistency）、可用性（ Availability）、分区容错性（分区耐受性， Partition Tolerance）不可得兼，只能同时满足其中2个。

一致性： 在分布式系统中数据往往存在多个副本，一致性描述的是这些副本中的数据在内容和组织上的一致。

可用性： 描述系统对用户的服务能力，所谓可用是指在用户能够容忍的时间范围内返回用户期望的结果。

分区容错性：
分布式系统通常由多个节点构成，由于网络是不可靠的，所以存在分布式集群中的节点因为网络通信故障导致被孤立成一个个小集群的可能性，即网络分区，分区容错性要求在出现网络分区时系统仍然能够对外提供一致性的可用服务。

由于分布式数据库通过网络连接，要始终假设网络是不可靠的，所以分区容错性是硬性规定；可用性既是一个系统基本的要求，也是分布式数据库的卖点，不可或缺；因此，只有牺牲一致性了。所谓一致性，就是分布式数据库的各个节点数据可能不能同步。

但是，凡事无绝对。由于网络技术进步，网络环境越来越好，因此，未出现分区故障时，应当考虑满足一致性和可用性。二阶段提交就是一种保持一致性的算法。

二、两阶段提交协议

两阶段提交协议（2PC：Two-Phase Commit）

该协议将一个分布式的事务过程拆分成两个阶段： 投票 和 事务提交 。为了让整个数据库集群能够正常的运行，该协议指定了一个 协调者 单点，用于协调整个数据库集群各节点的运行。为了简化描述，我们将数据库集群中的各个节点称为 参与者。

1、第一阶段：投票
打探数据库集群中的各个参与者是否能够正常的执行事务，具体步骤如下：

1）协调者向所有的参与者发送事务执行请求，并等待参与者反馈事务执行结果；
2）参与者收到请求之后，执行事务但不提交，并记录事务日志；
3）参与者将自己事务执行情况反馈给协调者，同时阻塞等待协调者的后续指令。

2、第二阶段：事务提交
在经过第一阶段协调者的询盘之后，各个参与者会回复自己事务的执行情况，这时候存在 3 种可能性：

1）所有的参与者都回复能够正常执行事务。
2）一个或多个参与者回复事务执行失败。
3）协调者等待超时。

第1种情况，所有的参与者都回复能够正常执行事务，于是协调者让它们都提交事务，具体如下：
.
对于后面2种情况，则做回滚处理

3、两阶段提交协议的缺点
两阶段提交协议原理简单、易于实现，但是缺点也是显而易见的，包含如下：

1）单点故障
协调者

2）同步阻塞
参与者都需要听从协调者的统一调度，期间处于阻塞状态而不能从事其他操作，效率极其低下

3）数据不一致性
协调者发出的事务 commit 通知有可能因为网络原因无法传递到部分参与者，造成它们一直处于阻塞状态，导致数据不一致。

针对上述问题可以引入 超时机制 和 互询机制 在很大程度上予以解决。简单来说就是：

协调者如果超时未收到参与者的回复，可以发出回滚指令；但参与者如果超时未收到协调者commit指令，则不能擅自回滚，它可以转而咨询其他参与者。如果有参与者表示收到了commit指令或rollback指令，则它可以大胆跟随；如果有参与者尚未到达就绪状态，则说明协调者肯定因为超时发出了回滚指令；否则继续咨询另一个参与者。最坏的情况是，所有参与者都处于就绪状态，这样将陷入长时间的阻塞状态。

三、三阶段提交协议

三阶段提交协议（3PC：Three-Phase Commit）

针对两阶段提交存在的问题，三阶段提交协议通过引入一个 预询盘 阶段，以及超时策略来减少整个集群的阻塞时间，提升系统性能。三阶段提交的三个阶段分别为：预询盘（can_commit）、预提交（pre_commit），以及事务提交（do_commit）。

与两阶段提交相比，主要差别是多了一个预询盘阶段。协调者会首先咨询参与者是否能参与事务处理，参与者只需回答一个预估值即可，并不做什么处理，过程是轻量的。

四、两阶段提交协议 VS 三阶段提交协议

两阶段提交协议中长时间阻塞状态发生的几率还是非常低的，所以尽管三阶段提交协议对于数据强一致性更有保障，但因为效率问题，两阶段提交协议实际更受欢迎。

参考资料：
分布式事务：两阶段提交与三阶段提交