Paxos算法进阶

Posted 2021-04-17 武力程序猿

“ 很多读者看完了paxos算法，只知道算法这么做可以达到一致性，但是不知道为什么。”

本文翻译自youtube上讲解paxos的视频，适用于对Paxos算法有基本了解的同学。

有条件的同学也可以戳“阅读原文”观看视频。

https://www.youtube.com/watch?v=JEpsBg0AO6o&t=3575s

01

—

Basic Paxos 算法: 

使用场景：

    1. 多个server提出value 

    2. 系统必须同意唯一的value 

要求: 

1. Safety 

    1）只有一个value最终会被chosen

    2）别的server只能学习到chosen的value 

2. Liveness 

    1）会有value最终被chosen （结合上边一条就是有且仅有一个value会被chosen）

    2）如果有value被chosen，其他的server可以学习到它 

02

—

为什么需要Paxos？

        对于单个acceptor的情况，是不安全的！因为acceptor服务器崩溃之后保存的value就丢失了。

        对应的解决方法是quorum，也就是建立多个acceptor。当多数acceptor同意的时候value才会被chosen。这样一个acceptor崩掉之后，value仍然可以被读取。

        但是quorum并不简单。我们想象一下以下三种情况：

        1. 假设每个acceptor accept了他们收到的第一个value，就会像下边这张图出现“脑裂”现象，就没法达成一致。 

        

    

这意味着acceptor有时候需要改变他们的想法。 

        2. 假如每个acceptor accept了他们收到的每一个value，就会造成多个value都被chosen的情况。如下图 

这意味着一旦一个value被chosen，其他的proposal必须propose那个被chosen的value。这需要two-phase protocal来实现。

 

        3. 假如仅仅有two phase protocal，也是不行的，因为像下图一样，会造成两个value被选择了。 

这意味着我们需要对proposal进行排序，拒绝更早的proposal 

03

—

Paxos过程

上一节通过对quorum的分析所得出的结论，我们再回顾一下Paxos的过程。

每个proposal都有一个唯一数字标识，数字越大优先级越高。

Phase 1: prepare ，这个过程有两个目的

    1）找到任何已经被chosen的value 

    2）block其他older并且尚未完成的proposal 

Phase 2: Accept 

    通知acceptor去accept一个特定的value 

几点需要注意的： 

    a) 在1），每一次n必须都是不一样的 

    b) 在2），proposer向所有的acceptor广播prepare请求，但是在4），proposer在收到majority的返回之后就会做出反应。majority意味着任意两个proposal之间肯定有重叠的server。 

    c) 在3），一旦acceptor收到了prepare请求，意味着他承诺永远不会accept比n小的proposal。这一个承诺的实现方式是acceptor保存了minProposal

    d) 在4），如果有多个acceptor返回他们所accept的值，proposer会选取最大的acceptedProposal对应的acceptedValue。

    e) 在6），如果n<minProposal，acceptor就会reject。reject的方式是返回一个比n更大的值。 

    f) 整个过程中acceptor需要在硬盘上保存minProposal, acceptedProposal, acceptedValue 

04

—

Paxos举例说明

为了理解Paxos，最关键的部分是理解在有竞争的proposal时，第二个proposal的prepare阶段。 

定义：P3.1 表示serve收到了一个n=3.1的proposal。其中3.1的3是第三轮proposal，1是server1提出的请求。 

    Case 1: 第二个proposal到来之前，第一个proposal已经被chosen了 

        在上图中，S1提出了X值，S5提出了Y值，而S3在收到P4.5的时候，告诉了S5：我已经同意了X值！ 

        所以S5转而提出了X值。事情解决了。 

    Case 2: 第二个proposal到来之前，前一个proposal没有被chosen，但是被部分acceptor accept了。第二个proposer恰好看到了！ 

        同样，第二个proposer会被说服，转而提出X值。 

    Case 3:第二个proposal到来之前，前一个proposal没有被chosen，但是被部分acceptor accept了。第二个proposer没有看到!

    在这个情况下，最终Y会被chosen。 

    关键是S3的选择。S3在收到P4.5的时候，会把自己的minProposal改成4.5，因此在收到A3.1X的时候，会拒绝！拒绝的方式是把自己的的minProposal=4.5返回给proposal的提出者也就是S1.接下来S1会开始新的一轮proposal，并且在prepare阶段发现Y已经被chosen了。 

    解决这种情况的关键是两个proposal必须有overlap的acceptor。 

05

—

Paxos死锁

这种情况下会造成死锁。 

防止死锁的方法是：在每次Accept被拒绝之后，delay一段时间，让别的proposal完成。 

在multi-paxos中，可以通过选举leader来避免死锁。 

06

—

额外注意

    a)在Basic Paxos过程中，只有proposer知道哪个value被chosen了 

    b)如果别的server想知道哪个value被chosen了，那就需要自己run一边Basic Paxos流程 

这里我们只分享了Basic Paxos的基本流程，下一篇文章我们会分享如何拓展到Multi Paxos，并用Multi Paxos进行log同步。