分布式理论（三）—— 一致性协议之 2PC
前言
为了使系统尽量能够达到 CAP，于是有了 BASE 协议，而 BASE 协议是在可用性和一致性之间做的取舍和妥协。
人们往往需要在系统的可用性和数据一致性之间反复的权衡。于是呢，就产生我们标题中的一致性协议，而且还不止一个呢。
为了解决分布式问题，涌现了很多经典的算法和协议，最著名的就是二阶段提交协议，三阶段提交协议，Paxos 算法。
本文重点介绍二阶段提交协议，简称 2PC。
1. 什么是 2PC
在分布式系统中，会有多个机器节点，因此需要一个 “协调者” ，而各个节点就是 “参与者”，协调者统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点就是 “参与者”。
协调者最终决定这些参与者是否要把事务真正进行提交。正式基于这个思想，有了二阶段提交和 三阶段提交。
2PC ，不是 2 个 pc 机的意思，而是 Two-Phase Commit 。可以认为是一种算法，也可以认为是一种协议，主要目的就是为了保证分布式系统数据的一致性。
协议说明：顾名思义，二阶段提交就是讲事务的提交过程分成了两个阶段来进行处理。流程如下：
2. 2PC 阶段一
1. 事务询问
协调者向所有的参与者询问，是否准备好了执行事务，并开始等待各参与者的响应。
2. 执行事务
各参与者节点执行事务操作，并将 Undo 和 Redo 信息记入事务日志中
3. 各参与者向协调者反馈事务询问的响应
如果参与者成功执行了事务操作，那么就反馈给协调者 Yes 响应，表示事务可以执行；如果参与者没有成功执行事务，就返回 No 给协调者，表示事务不可以执行。
从上面可以感觉到，这个一个 所谓的 “投票阶段”，什么意思呢？所有的节点都投票决定是否执行事务操作。
3. 2PC 阶段二
在阶段二中，会根据阶段一的投票结果执行 2 种操作：执行事务提交，中断事务。
执行事务提交步骤如下：
- 发送提交请求：协调者向所有参与者发出 commit 请求。
- 事务提交：参与者收到 commit 请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。
- 反馈事务提交结果：参与者在完成事务提交之后，向协调者发送 Ack 信息。
- 协调者接收到所有参与者反馈的 Ack 信息后，完成事务。
中断事务步骤如下：
- 发送回滚请求：协调者向所有参与者发出 Rollback 请求。
- 事务回滚：参与者接收到 Rollback 请求后，会利用其在阶段一种记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
- 反馈事务回滚结果：参与者在完成事务回滚之后，想协调者发送 Ack 信息。
- 中断事务：协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。
从上面的逻辑可以看出，二阶段提交就做了2个事情：投票，执行。
核心是对每个事务都采用先尝试后提交的处理方式，因此也可以将二阶段提交看成一个强一致性的算法。
整个事务的执行过程如图（可能不是太直观。。。。）
4. 优点缺点
优点：原理简单，实现方便
缺点：同步阻塞，单点问题，数据不一致，过于保守
- 同步阻塞：
在二阶段提交的过程中，所有的节点都在等待其他节点的响应，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。
- 单点问题：
协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转，更重要的是：其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。
- 数据不一致：
假设当协调者向所有的参与者发送 commti 请求之后，发生了局部网络异常或者是协调者在尚未发送完所有 commit 请求之前自身发生了崩溃，导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题。
- 过于保守：
如果在二阶段提交的提交询问阶段中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的化，这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，显然，这种策略过于保守。换句话说，二阶段提交协议没有设计较为完善的容错机制，任意一个节点是失败都会导致整个事务的失败。
5. 总结
由于 Base 理论需要在一致性和可用性方面做出权衡，因此涌现了很多关于一致性的算法或者说协议，这些协议设计的目的，就是能让分布式系统能够在可用性和一致性之间取得一个很好的平衡，能够基本可用。 比如 2PC，two-phase commit，分为两个阶段提交一个事务：投票，执行。通过协调者和各个参与者的配合，实现一致性协议。
当然，他也是有去缺点的，比如同步阻塞的时候性能较低，协调者的单点问题，网络故障可能引起的数据不一致的问题，执行策略过于保守的问题等等。
这些问题，将在另一个算法 3PC 中解决。我们将在下一篇文章中详细说明。
good luck！！！
