[从Paxos到ZooKeeper][分布式一致性原理与实践]<二>一致性协议[Paxos算法]

Overview

• 在<一>有介绍到，一个分布式系统的架构设计，往往会在系统的可用性和数据一致性之间进行反复的权衡，于是产生了一系列的一致性协议。
• 为解决分布式一致性问题，在长期的探索过程中，涌现了一大批经典的一致性协议和算法，其中最著名的就是二阶段提交协议、三阶段提交协议和Paxos算法了。

2PC与3PC

• 分布式系统中，每个机器节点虽然都能明确知道自己在进行事务操作过程中的结果是失败or成功，但却无法直接获取到其他分布式节点的操作结果。
• 因此，当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的ACID特性，就需要引入一个称为“协调者(Coordinator)”的组件来统一调度所有分布式节点的执行逻辑。而被调度的分布式节点则被称为“参与者(Participant)”。
• 协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务真正进行提交。基于该思想，衍生出了二阶段提胶片和三阶段提交两种协议。

2PC

• 2PC，即Two-Phase Commit。是计算机网络尤其是数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性和一致性设计的一种算法。
• 简单来说，就是将一个事务的处理过程分为了投票和执行两个阶段。

协议说明

• 阶段一：提交事务请求：
  1. 事务询问：协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应；
  2. 执行事务：各参与者执行事务操作，并将Undo和Redo信息记入事务日志；
  3. 各参与者向协调者反馈事务询问的响应：
• 阶段二：执行事务提交：
  协调者根据各参与者的反馈情况来决定最终是否可以进行事务提交操作。
  
  • 执行事务提交
    1. 发送提交请求：协调者向所有参与者节点发出Commit请求；
    2. 事务提交
    3. 反馈事务提交结果：参与者完成事务提交后，向协调者发送Ack
    4. 完成事务
  • 中断事务
    1. 发送回滚请求：协调者向所有参与者节点发出Rollback请求；
    2. 事务回滚：参与者利用其在阶段一中记录的Undo信息来执行回滚操作；
    3. 反馈事务回滚结果
    4. 中断事务

优缺点：

• 优点：原理简单，实现方便
• 缺点：同步阻塞，单点问题，脑裂，太过保守。
  • 同步阻塞：2PC最大的问题，会极大地限制分布式系统的性能。因为在2PC执行过程中，所有该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中将无法进行其他任何操作。
  • 单点问题：一旦协调者出现问题，整个2PC都无法运转。更严重的是，如果协调者在phase2中出现问题的话，那么其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成事务操作。
  • 数据不一致：在phase2，如果协调者向所有的参与者发送Commit请求之后，发生了局部网络异常或是协调者在尚未发送完Commit请求之前自身发生崩溃，最终导致只有部分参与者收到了Commit请求，那么整个分布式系统就会出现数据不一致现象。
  • 太过保守：当协调者无法获取参与者的响应信息时，协调者只能依靠其自身的超时机制来判断是否需要中断事务，这样的策略过于保守。换句话说，2PC提交协议没有涉及较为完善的容错机制，任意一个节点的失败都会导致整个事务的失败。

3PC

协议说明

• Three-Phase Commit是2PC的改进版。
• 3PC是有CanCommit、PreCommit和DoCommit三个阶段组成的事务处理协议

 三阶段

• 阶段一：CanCommit
  • 事务询问：协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应；
  • 各参与者向协调者反馈事务询问的响应
• 阶段二：PreCommit
  该阶段协调者会根据上阶段各参与者的响应决定执行事务预提交 or 中断事务
• 阶段三：doCommit
  该阶段将进行真正的事务提交，存在执行提交 or 中断事务两种情况。

优缺点

• 优点：3PC最大的优点就是降低了参与者的阻塞范围，能够在出现单点故障后继续达成一致。
• 缺点：在参与者接收到preCommit消息后，如果出现网络分区，此时协调者所在的节点和参与者无法进行正常的通信，在这种情况下，该参与者依然会进行事务提交，这必然出现数据的不一致性。

Paxos算法

• Paxos算法是一种基于消息传递且具有高度容错特性的一致性算法，是一种非常重要的分布式一致性协议。
• 之前的介绍一致在提到，在常见的分布式系统中，总会发生诸如机器宕机或网络异常等情况。那么Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致，并且保证不论发生以上任何异常，都不会破坏整个系统的一致性。

追本溯源

• 理论上来说，在分布式计算领域，试图在异步系统和不可靠的通道上来达到一致性状态是不可能的，因此在一致性的研究过程中，都往往假设信道是可靠的。
• Lamport在1982年发表的论文中，用这样一个场景来试图描述一致性算法需要解决的问题：
  在一个叫Paxos的小岛上，岛上采用议会的形式来通过法令，议会中的议员通过信使进行消息的传递。同时要注意议员和信使随时有可能会离开议会厅，并且信使可能会重复传递消息，也可能一去不复返。因此，议会协议要保证在这种情况下法令仍然能够正确的产生，并且不会出现冲突。

Paxos算法详解

• Paxos作为一种提高分布式系统容错性的一致性算法，是十分晦涩的。
• Paxos算法的核心是一个一致性算法，也是论文中提到的“synod”算法。

问题描述

基于上述场景，一个一致性算法需要保证以下几点：

• 在这些被提出的提案中，只有一个会被选定；
• 若没有提案被提出，那么就不会有被选定的提案；
• 当一个提案被选定后，进程应该可以获取被选定的提案信息。

提案的选定

• 要选定一个唯一提案最简单的方式莫过于只允许一个Accpetor存在，这样的话，Proposer只能发送提案给该Acceptor，Acceptor会选择它接收到的第一个提案作为被选定的提案。该方法的问题是，单点故障。
• 因此，必然存在多个Acceptor。这样，我们可以在有足够多Acceptor批准该提案时才选定其（需要保证每个Acceptor最多只能批准一个提案）。

推导过程

• 详细内容请参考Paxos算法。