paxos算法之粗浅理解

最新推荐文章于 2020-07-14 19:54:42 发布

yann.bai

最新推荐文章于 2020-07-14 19:54:42 发布

阅读量176

点赞数

分类专栏：大数据

大数据专栏收录该内容

53 篇文章 0 订阅

订阅专栏

转自：https://www.nndev.cn/archives/96

paxos出身

paxos出身名门，它爹是没多久前获得图灵奖的在分布式领域大名鼎鼎的Leslie Lamport。

paxos为何而生

那么Lamport他老人家为什么要搞这个东东呢，不是吃饱了撑的，而是为了解决分布式系统的大难题。分布式系统一般要求具有高可用性，高可用性一般又是通过冗余也就是多副本来解决，多副本接着又带来了一致性问题，所以分布式系统要解决的问题可简单归结为多副本的一致性问题。怎么解决一致性问题呢？抢答：用事务。何为事务？抢答：

多个操作序列的原子性。何为原子性？抢答：还需要您自己去多看书吧。实现事务的方案有两阶段提交协议，和在这个基础上进行了增强的三阶段提交协议。这两个方案都涉及到两个角色，即协调者(coordinator)和参与者(cohort)，协调者要保证操作序列的原子性来实现事务，但它们都存在一些问题，因此一些著名的系统如Google的Chubby和Yahoo的Apache ZooKeeper都使用了paxos算法。

两阶段提交协议的消息流程：

Coordinator                                         Cohort
                              QUERY TO COMMIT
                -------------------------------->
                              VOTE YES/NO           prepare*/abort*
                <-------------------------------
commit*/abort*                COMMIT/ROLLBACK
                -------------------------------->
                              ACKNOWLEDGMENT        commit*/abort*
                <--------------------------------  
end

两阶段提交协议包含投票(Vote)和提交(Commit)两个阶段，它是一个阻塞的协议，如果参与者给协调者发送YES消息后协调者永久性地挂了，那么参与者将陷入无限等待中，并且会带来数据不一致的问题。

三阶段提交协议的消息流程：

三阶段提交协议在二阶段提交协议的基础上增加了准备提交(Prepared to commit)阶段，解决了协调者挂掉后参与者无限阻塞和数据可能不一致的问题，但仍然无法解决网络分区的问题。

相对于上面两个协议，由于多数派的特性，paxos可以在节点失效、网络分区、网络延迟等各种异常情况下保证所有节点都处于同一状态，它的结构图大致如下：

Basic paxos architecure. A picutre from:paxos-by-example

一个典型的paxos应用场景

分布式系统中有多个节点，一般每个节点都是参与者，而其中一个节点既是参与者又是协调者。但是这样还会有单点故障的问题，即如果协调者节点挂了，那么将无法进行任何事务，系统也就停止了正常运转。如何在还存活的其它节点中选择一个来担当协调者的角色，使系统可以照常运行，达到山不转水转的目标呢？真的好难，但是有了paxos算法，我们可以解决这个难题。如果还觉得这个问题抽象，那么可以换一种表述方式，即：如何在分布式系统中确定某一个变量的值。在这个具体的场景中，这个变量的值指定了哪个节点将被选出来担当新协调者的角色。

paxos角色和规则

从上面的结构图中，我们看到paxos主要涉及三个角色，分别为Acceptor、Proposer和Learner，在实践中，往往每个节点都具备这三个角色，这里为了让我们大脑少些迷糊，暂且以每个节点只具备一种角色来讨论。

paxos算法主要分为两个阶段：

1. Prepare:

Proposer向所有Acceptor发送Prepare申请访问权，并携带一个提案号(epoch)，Acceptor赋予访问权或拒绝，并且返回该Acceptor已经接受的值和对应的提案号。如果Proposer获得超过半数Acceptor的访问权，那么会进入第二阶段；

2. Accept:

1) 如果所有的Acceptor返回值都为空，则Proposer将携带自己预设的值v和自己的epoch号向获取到访问权的Acceptor发送请求;

2)如果Proposer第一阶段获得某些Acceptor的返回值不为空，则将epoch号最大的提案号对应的值f作为自己的预设值，和自己的提案号一起向Acceptor发送请求(如果第一阶段返回f的Acceptor已经超过了半数，则表示已经形成确定性取值，此时直接返回成功，不需要进行Accept请求了)；

对于Acceptor来说，当它接收到Proposer请求时，需要应用一系列规则来决定如何响应，我们对这些规则可以进行如下概括：

1)喜新厌旧

当Acceptor接收到Prepare请求时，它将当前自己发放了访问权的epoch号和该Prepare请求携带的epoch进行比较，如果前者小于后者，则将访问权赋予新请求的这个Proposer，否则拒绝发放访问权。这里我们认为epoch值越大的越新。

2) 一视同仁

当Acceptor接收到Accept请求时，它将当前自己发放了访问权的epoch号和该Prepare请求携带的epoch进行比较，如果前者大于后者，则拒绝该请求。如果这两个epoch号相等，并且Acceptor当前接受的取值为空，则接受该Acceptor请求，同时将该Accept请求的值设置为接受值。如果之后又更大的epoch号申请到访问权，并发出Accept请求，该值也不会改变，即Acceptor在确定了值之后不再改变，谁先设置就用谁的值。虽然在发放访问权时是喜新厌旧，但在取值这个问题上一视同仁，不会因为新epoch号大而改变取值。这就像某些人，其他女人可以访问他，但老婆只要定了就不会变。

paxos正确性

假设有N个Acceptor，多数派个数至少为N/2+1。如果有一个以上的Proposer获取到超过半数Acceptor的访问权，那么至少有一个Acceptor是相同的。具体来说，假设Proposer A在Prepare阶段获取到J个Acceptor的访问权，Proposer B在Prepare阶段获取到K个Acceptor的访问权，J>=N/2+1，K>=N/2+1，那么必然有这样一个Acceptor C，C既属于J又属于K，这种情况就是在C给某个Proposer发放访问权后，接着被另一个Proposer抢占到了访问权时发生。
我们假设Proposer A的取值为V1，Proposer B的取值为V2。在Accept阶段，对于Acceptor C来说，它根据访问权来决定接受谁的Accept请求，如果当前是B获得了访问权，则接受B的取值V2，这样A在Accept阶段将失败，失败之后它可能会继续生成新的epoch值重新进入Prepare阶段，但是这回它拿到了返回值V2，这样它之后进入Accept阶段时，会将V2作为它的取值向Acceptor发送申请，最终Proposer A和Proposer B都达成了一致，即V2为最终取值。

以上是本人目前对paxos算法的一点理解，还将继续深入和不断纠正…….

感觉不错的资料，推荐参考：

前百度牛人李海磊的课程：

http://www.tudou.com/programs/view/e8zM8dAL6hM/

这个视频里还讲到了活锁，我看了启发不小：

https://www.youtube.com/watch?v=JEpsBg0AO

http://angus.nyc/2012/paxos-by-example/

http://blog.csdn.net/chen77716/article/details/6166675