Zookeeper理论基础之Paxos算法

1、Zookeeper理论基础

1.3 Paxos算法

       对于zk的学习，最重要的也是最难的就是Paxos算法学习。所以首先我们需要学习Paxos算法。

1.3.1 算法简介

       Paxos算法是莱斯利.兰伯特1990年提出的一种基于消息传递的、具有高容错性的一致性算法。Google Chubby的作者Mike Burrows说过，世上只有一种一致性算法，那就是Paxos，所有的其他的一致性算法都是Paxo算法的不完整版本。Paxos算法是一种公认的晦涩难懂的算法，并且工程实现上也有很大的困难。较有名的Paxos工程实现有Google Chubby、ZAB、微信的PhxPaxos等。

 

       Paxos算法是用于解决什么问题呢？Paxos算法要解决的问题是，在分布式系统中就某个决议达成一致。

 

1.3.2 Paxos与拜占庭将军问题

       拜占庭将军问题是由Paxos算法作家莱斯利.兰伯特提出的点对点通信的基本问题。该问题要说明的含义是，在不可靠信道上试图通过消息传递的方式达到一致性是不可能的。所以，Paxos算法的前提是不存在拜占庭问题，即信道是安全的、可靠的，集群间传递消息是不会被篡改的。

       一般情况下，分布式系统中各节点间采用两种通讯模式：共享内存（Shared Memory）、消息传递（Messages Passing）。而Paxos是基于消息传递通讯模型的。

 

1.3.3 算法描述

（1）三种角色

       在Paxos算法中有三种角色，分别具有三种不同行为。很多时候一个进程充当多种角色，比如：提案者、表决者、学习者。

• Proposer：提案者
• Acceptor：表决者
• Learner：学习者

 

（2）Paxos算法的一致性

       Paxos算法一致性主要体现在以下几个方面：

【1】每个提案者在提出提案时都会首先获得一个全局唯一性的、递增的提案编号N，即在整个集群中是唯一的编号N，然后将该编号赋予它要提出的提案。

 

【2】每个表决者在accept某提案后，会将该提案编号N记录在本地，这样每个表决者都会在本地保存一个最大的提案编号，其编号为maxN。每个表决者只会接受比自己本地大的maxN编号。

 

【3】在众多提案中只能有一个提案被选定。

 

【4】一旦一个提案被选定，则其他服务器会主动同步（Learn）该提案到本地。

 

【5】没有提案被提出则不会有提案被选定。

 

（3）算法描述过程

       Paxos算法的执行过程划分为两个阶段：准备阶段（Prepare）和接受阶段（Accept）。

A、prepare阶段

提案者（Proposer）准备提交一个编号为N的提案，于是向所有的表决者（Acceptor）发送prepare（N）请求，用于试探集群是否支持该编号的提案。

表决者（Acceptor）都保留着自己曾经accept过的最大编号maxN的提案，当一个表决者接受到来自其他主机发送过来的prepare（N）请求时，它会比较N与maxN的大小。有以下几种情况：

1）当N<maxN时，则说明该提案已经过时，当前表决者采取不回应或者回应Error的方式来拒绝prepare请求；

 

2）当N>maxN时，则说明该提案是可以接受的，当前表决者会首先将该N记录下来，并将自己曾经接受过的最大编号maxN的提案Proposal（myid，maxN，value）反馈给提案者，以向提案者展示自己支持提案的意愿。其中第一个参数myid表示表决者（Acceptor）的标识id，第二个参数表示自己曾经接受过的最大编号maxN的提案，第三个参数表示提案的真正内容value。当然，若表决者还未接受过任何提案，则会把Proposal（myid，null，null）反馈给提案者。

 

3）在prepare阶段是不可能存在N = maxN的情况。者是由N的生成机制所决定的。要想获取N的值，必须在原来的值基础上加1。

 

B、accept阶段

1)当提案者发出prepare（N）时，如果收到超过半数的表决者（Acceptor）的反馈，那么该提案者就会将其真正的提案Proposal（myid，N，value）发送给所有的表决者。

 

2）当表决者（Acceptor）接收到提案者发送的Proposal（myid，N，value）提案后，会再次拿出自己曾经accept过的提议中最大的编号maxN，或者曾经记录下的prepare的最大编号，让N与它们比较，若N大于等于这两个编号，则表决者接受该提案，并反馈给提案者。若N小于这两个编号，则表决者采取不回应或者回应Error的方式来拒绝该提案。

 

3）若提案者没有接受超过半数表决者accept反馈，则有两种可能的结果产生。一是放弃该提案，不再提出；二是重新进入prepare阶段，递增提案编号，重新提出prepare请求。

 

4）若提案者接受到的反馈数量超过半数，则会向外广播两类信息：

       a)向曾经accept其提案的表决者发送“可执行数据同步信号”，即让它们执行曾经接受到的提案。

       b）向曾经未accept其提案的表决者发送“Proposal（myid，maxN，value）和可执行数据同步信号”，即让它们接受到该提案后立即执行。

 

1.3.4 Paxos算法的活锁问题

     前面所述的Paxos算法在实际的工程应用过程中，根据不同的实际需求存在诸多不便之处，所以就出现了很多对与Paxos算法的优化算法，以对Paxos算法改进，例如：Multi Paxos、Fast Paxos、EPaxos。

 

       Paxos存在的“活锁问题”，Fast Paxos算法对Paxos进行了改进：只允许一个进程提交提案，即该进程对N的唯一操作权。该方式解决了“活锁问题”。

 

       活锁问题演示：

       第一步：

第二步：

第三步：

第四步：

第五步：同上所述，ProposerA和ProposerB如此反复替换新提案编号N，尝试-失败-再尝试-再失败……