DDBS 2PC

为了使系统尽量能够达到 CAP，于是有了 BASE 协议，而 BASE 协议是在可用性和一致性之间做的取舍和妥协。

人们往往需要在系统的可用性和数据一致性之间反复的权衡。于是呢，就产生我们标题中的一致性协议。为了解决分布式问题，涌现了很多经典的算法和协议，最著名的就是二阶段提交协议，三阶段提交协议，Paxos 算法。

2PC（二阶段提交）

2PC ，不是 2 个 pc 机的意思，而是 Two-Phase Commit 。可以认为是一种算法，也可以认为是一种协议，主要目的就是为了保证分布式系统数据的一致性。顾名思义，二阶段提交就是讲事务的提交过程分成了两个阶段来进行处理。

在分布式系统中，会有多个机器节点，因此需要一个 “协调者” ，而各个节点就是 “参与者”，协调者统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点就是 “参与者”。

协调者最终决定这些参与者是否要把事务真正进行提交。正是基于这个思想，有了二阶段提交和 三阶段提交。

阶段一

1. 事务询问
   协调者向所有的参与者询问，是否准备好了执行事务，并开始等待各参与者的响应。
2. 执行事务
   各参与者节点执行事务操作，并将 Undo 和 Redo 信息记入事务日志中。
3. 各参与者向协调者反馈事务询问的响应
   如果参与者成功执行了事务操作，那么就反馈给协调者 Yes 响应，表示事务可以执行；如果参与者没有成功执行事务，就返回 No 给协调者，表示事务不可以执行。

阶段二

在阶段二中，会根据阶段一的结果执行 2 种操作：执行事务提交或者中断事务。

执行事务提交步骤如下：

1. 发送提交请求：协调者向所有参与者发出 commit 请求。
2. 事务提交：参与者收到 commit 请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。
3. 反馈事务提交结果：参与者在完成事务提交之后，向协调者发送 Ack 信息。
4. 协调者接收到所有参与者反馈的 Ack 信息后，完成事务。

中断事务步骤如下：

1. 发送回滚请求：协调者向所有参与者发出 Rollback 请求。
2. 事务回滚：参与者接收到 Rollback 请求后，会利用其在阶段一种记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
3. 反馈事务回滚结果：参与者在完成事务回滚之后，想协调者发送 Ack 信息。
4. 中断事务：协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。

2PC不足之处

缺点：同步阻塞，单点问题，数据不一致，过于保守

• 同步阻塞：
  在二阶段提交的过程中，所有的节点都在等待其他节点的响应，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。

• 单点问题：
  协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转，更重要的是：其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。

• 数据不一致：
  假设当协调者向所有的参与者发送 commit 请求之后，发生了局部网络异常或者是协调者在尚未发送完所有 commit 请求之前自身发生了崩溃，导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题。

• 过于保守：
  如果在二阶段提交的提交询问阶段中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，显然，这种策略过于保守。换句话说，二阶段提交协议没有设计较为完善的容错机制，任意一个节点是失败都会导致整个事务的失败。