分布式数据一致性算法paxos解析及几个问题,收敛(含参考文献)

人人都是分布式专家 paxos csdn

 

paxos 用来干嘛的?

    解决分布式环境下的决议问题,大家接受同一个方案. (提案者每个人都可以提案,决策者来接受).

   一阶段先try, 二阶段再提交, 如果得不到半数认可, 用最大的序号的value提交. 为什么要两阶段, 本质是 一阶段尝试获取1/2节点支持,  二阶段通过提交来验证是否前面的支持是否依旧在支持.

     

核心流程

(from 分布式一致性算法 Paxos是什么梗？Paxos 是解决分布式环境下多节点的数据一致性问题，先看下一致性问题)

Paxos要求满足的前置假设只有一个：消息内容不会被篡改；更正式的说是无拜占庭将军问题。

主流程

 从上述流程可知，并发情况下，可能会出现第4步或者第7步频繁重试的情况，导致性能低下，更严重者可能导致永远都无法达成一致的情况，就是所谓的“活锁”，如下图所示：

paxos为什么说是分布式数据一致性的算法?

   分布式数据一致的另外一个描述就是 每个client都在向存储集群发送数据,要求存储他的数据,这个存储系统需要决议,这个数据存还是不存? 如果只有一条数据到简单. 超过半数,存.  如果存在并发,先存哪个的问题. 本质上即决议这次存哪个数据?  需要有个算法来解决这个问题,一个数据过来了,问下每个系统存还是不存? (可以对client提交规则有限制.)

      因为paxos对client (proposer)有要求,所以将proposer角色集成到存储系统中. 每个client只管发数据. 每个client依次提交这些数据即每个client每次仅提交一个数据. 实现一个循环后,再次提交数据(如果上一个被接受,那么就提交下一个,如果没有被接受,依旧提交)

   分布式一致性算法 Paxos是什么梗？也有类似说法

   如果真心觉得Paxos的原文不知所云，也不知道能拿来干嘛，可以从阅读Raft的论文开始，如果真的有兴趣，强推Raft作者Diego Ongaro那篇300页的博士论文《CONSENSUS: BRIDGING THEORY AND PRACTICE》，不只是讲解了Raft协议，而且系统的论述Paxos类似的一致性协议，不仅从原理，也从工程角度出发，涉及方方面面，在写毕设中了就是写不动就翻翻的良作。

fast-paxos

multi - paxos 和paxos区别?

     是对多个提案达成一致. 先产生一个leader , 然后其他的都转交给leader来提交.

     分布式存储可以用这个算法来决策leader,然后基于leader执行读写操作,实现分布式数据的一致性. 例如zoonKeeper.  然后ZK又从分布式存储中独立出来,作为专门的分布式选举系统. 提案者就是每个分布式存储的节点机器.

Multi-paxos算法

    Paxos是对一个值达成一致，Multi-Paxos是连续多个paxos instance来对多个值达成一致，这里最核心的原因是multi-paxos协议中有一个Leader。Leader是系统中唯一的Proposal，在lease租约周期内所有提案都有相同的ProposalId，可以跳过prepare阶段，议案只有accept过程，一个ProposalId可以对应多个Value，所以称为Multi-Paxos。

1. 若集群中没有Leader，则在集群中选出一个节点并声明它为第M任Leader。
2. 集群的Acceptor只表决最新的Leader发出的最新的提案
3. 其他步骤和Basic Paxos相同

 选举

   首先我们需要有一个leader，其实选主的实质也是一次Paxos算法的过程，只不过这次Paxos确定的“谁是leader”这个值。由于任何一个节点都可以发起提议，在并发情况下，可能会出现多主的情况，比如A，B先后当选为leader。为了避免频繁选主，当选leader的节点要马上树立自己的leader权威(让其它节点知道它是leader)，写一条特殊日志(start-working日志)确认其身份。根据多数派原则，只有一个leader的startworking日志可以达成多数派。leader确认身份后，可以通过了lease机制(租约)维持自己的leader身份，使得其它proposal不再发起提案，这样就进入了leader任期，由于没有并发冲突，因此可以跳过prepare阶段，直接进入accept阶段。通过分析可知，选出leader后，leader任期内的所有日志都只需要一个网络RTT(Round Trip Time)即可达成一致。

新主恢复流程

   由于Paxos中并没有限制，任何节点都可以参与选主并最终成为leader，这就无法保证新选出的leader包含了所有日志，可能存在空洞，因此在真正提供服务前，还存在一个获取所有已提交日志的恢复过程。新主向所有成员查询最大logId的请求，收到多数派响应后，选择最大的logId作为日志恢复结束点，这里多数派的意义在于恢复结束点包含了所有达成一致的日志，当然也可能包含了没有达成多数派的日志。拿到logId后，从头开始对每个logId逐条进行paxos协议，因为在新主获得所有日志之前，系统是无法提供服务的。为了优化，引入了confirm机制，就是将已经达成一致的logId告诉其它acceptor，acceptor写一条confirm日志到日志文件中。那么新主在重启后，扫描本地日志，对于已经拥有confirm日志的log，就不会重新发起paxos了。同样的，在响应客户端请求时，对于没有confirm日志的log，需要重新发起一轮paxos。由于没有严格要求confirm日志的位置，可以批量发送。为了确保重启时，不需要对太多已提价的log进行paxos，需要将confirm日志与最新提交的logId保持一定的距离。

性能优化

   Basic-Paxos一次日志确认，需要至少2次磁盘写操作(prepare,promise)和2次网络RTT(prepare,promise)。Multi-Paxos利用一阶段提交(省去Prepare阶段)，将一次日志确认缩短为一个RTT和一次磁盘写；通过confirm机制，可以缩短新主的恢复时间。为了提高性能，我们还可以实现一批日志作为一个组提交，要么成功一批，要么都不成功，这点类似于group-commit，通过RT换取吞吐量。

安全性(异常处理)

1.Leader异常
Leader在任期内，需要定期给各个节点发送心跳，已告知它还活着(正常工作)，如果一个节点在超时时间内仍然没有收到心跳，它会尝试发起选主流程。Leader异常了，则所有的节点先后都会出现超时，进入选主流程，选出新的主，然后新主进入恢复流程，最后再对外提供服务。我们通常所说的异常包括以下三类：
(1).进程crash(OS crash)
Leader进程crash和Os crash类似，只要重启时间大于心跳超时时间都会导致节点认为leader挂了，触发重新选主流程。
(2).节点网络异常(节点所在网络分区)
Leader网络异常同样会导致其它节点收不到心跳，但有可能leader是活着的，只不过发生了网络抖动，因此心跳超时不能设置的太短，否则容易因为网络抖动造成频繁选主。另外一种情况是，节点所在的IDC发生了分区，则同一个IDC的节点相互还可以通信，如果IDC中节点能构成多数派，则正常对外服务，如果不能，比如总共4个节点，两个IDC，发生分区后会发现任何一个IDC都无法达成多数派，导致无法选出主的问题。因此一般Paxos节点数都是奇数个，而且在部署节点时，IDC节点的分布也要考虑。
(3).磁盘故障
前面两种异常，磁盘都是OK的，即已接收到的日志以及对应confirm日志都在。如果磁盘故障了，节点再加入就类似于一个新节点，上面没有任何日志和Proposal信息。这种情况会导致一个问题就是，这个节点可能会promise一个比已经promise过的最大proposalID更小的proposal，这就违背了Paxos原则。因此重启后，节点不能参与Paxos Instance，它需要先追上Leader，当观察到一次完整的paxos instance时该节点结束不能promise/ack状态。
2.Follower异常(宕机，磁盘损坏等)
对于Follower异常，则处理要简单的多，因为follower本身不对外提供服务(日志可能不全)，对于leader而言，只要能达成多数派，就可以对外提供服务。follower重启后，没有promise能力，直到追上leader为止。

Q&A
1.Paxos协议数据同步方式相对于基于传统1主N备的同步方式有啥区别？

  一般情况下，传统数据库的高可用都是基于主备来实现，1主1备2个副本，主库crash后，通过HA工具来进行切换，提升备库为主库。在强一致场景下，复制可以开启强同步，Oracle和Mysql都是类似的复制模式。但是如果备库网络抖动，或者crash，都会导致日志同步失败，服务不可用。为此，可以引入1主N备的多副本形式，我们对比都是3副本的情况，一个是基于传统的1主2备，另一种基于paxos的1主2备。传统的1主两备，进行日志同步时，只要有一个副本接收到日志并就持久化成功，就可以返回，在一定程度上解决了网络抖动和备库crash问题。但如果主库出问题后，还是要借助于HA工具来进行切换，那么HA切换工具的可用性如何来保证又成为一个问题。基于Paxos的多副本同步其实是在1主N备的基础上引入了一致性协议，这样整个系统的可用性完全有3个副本控制，不需要额外的HA工具。而实际上，很多系统为了保证多节点HA工具获取主备信息的一致性，采用了zookeeper等第三方接口来实现分布式锁，其实本质也是基于Paxos来实现的。

      我这里以MySQL的主备复制一套体系为例来具体说明传统的主备保持强一致性的一些问题。整个系统中主要包含以下几种角色：Master，Slave，Zookeeper-Service(zk)，HA-Console(HA)，Zookeeper-Agent(Agent)
Master,Slave:分别表示主节点和备节点,主节点提供读写服务，备节点可以提供读服务，或者完全用于容灾。
Zookeeper-Service(zk):分布式一致性服务，负责管理Master/Slave节点的存活信息和切换信息。zk基于zab协议，zab协议是一种一致性协议，与paxos，raft协议类似，它主要有两种模式，包括恢复模式(选主)和广播模式(同步)。一般zk包含N个节点(zk-node)，只要有超过半数的zk-node存活且相互连通，则zk可以对外提供一致性服务。
HA-Console:切换工具，负责具体的切换流程
Zookeeper-Agent(Agent):Master/Slave实例上的监听进程，与监听的实例保持心跳，维护Master/Slave的状态，每个实例有一个对应的Agent。大概工作流程如下：
(1).Master/Slave正常启动并搭建好了复制关系，对应的Agent会调用zk接口去注册alive节点信息，假设分别为A和B。
(2).如果此时Master Crash，则实例对应的Agent发现心跳失败，如果重试几次后仍然失败，则将调用zk接口注销掉A节点信息。
(3).HA工具通过zk接口比较两次的节点信息，发现少了A节点，表示A可能不存在了，需要切换，尝试连接A，如果仍然不通，注册A的dead节点，并开始切换流程。
(4).HA工具读取配置信息，找到对应的Slave节点B，(更改读写比配置信息，设置B提供写)，打开写。
(5).应用程序通过拉取最新的配置信息，得知新主B，新的写入会写入B。
前面几部基本介绍了MySQL借助zk实现高可用的流程，由于zk-node可以多地部署，HA无状态，因此可以很容易实现同城或者是异地的高可用系统，并且动态可扩展，一个HA节点可以同时管理多个Master/Slave的切换。那么能保证一致性吗？前面提到的Agent除了做监听，还有一个作用是尽可能保持主备一致，并且不丢数据。
(6).假设此时A节点重启，Agent检测到，通过zk接口发现A节点在dead目录下，表示被切换过，需要kill上面的所有连接，并回滚crash时A比B多的binlog，为了尽可能的少丢数据，然后再开启binlog后，将这部分数据重做。这里要注意rollback和replay都在old-Master上面进行，rollback时需要关闭binlog，而replay需要开启binlog，保证这部分数据能流向new-Master。
(7).从第6步来看，可以一定程度上保证主备一致性，但是进行rollback和replay时，实际上是往new-Slave上写数据，这一定程度上造成了双写，如果此时new—Master也在写同一条记录，可能会导致写覆盖等问题。
(8).如果开启半同步呢？old-Master crash时，仍然可能比old-Slave多一个group的binlog，所以仍然需要借助于rollback和replay，依然避免不了双写，所以也不能做到严格意义上的强一致。

2.分布式事务与Paxos协议的关系？
     在数据库领域，提到分布式系统，就会提到分布式事务。Paxos协议与分布式事务并不是同一层面的东西。分布式事务的作用是保证跨节点事务的原子性，涉及事务的节点要么都提交(执行成功)，要么都不提交(回滚)。分布式事务的一致性本质上是数据库acid里的原子性, 通常通过2PC来保证(Two-Phase Commit, 2PC)，这里面涉及到一个协调者和若干个参与者。第一阶段，协调者询问参与者事务是否可以执行，参与者回复同意(本地执行成功)，回复取消(本地执行失败)。第二阶段，协调者根据第一阶段的投票结果进行决策，当且仅当所有的参与者同意提交事务时才能提交，否则回滚。2PC的最大问题是，协调者是单点(需要有一个备用节点)，另外协议是阻塞协议，任何一个参与者故障，都需要等待(可以通过加入超时机制)。Paxos协议用于解决多个副本之间的一致性问题。比如日志同步，保证各个节点的日志一致性，或者选主(主故障情况下)，保证投票达成一致，选主的唯一性。简而言之，2PC用于保证多个数据分片上事务的原子性，Paxos协议用于保证同一个数据分片在多个副本的一致性，所以两者可以是互补的关系，绝不是替代关系。对于2PC协调者单点问题，可以利用Paxos协议解决，当协调者出问题时，选一个新的协调者继续提供服务。工程实践中，Google Spanner，Google Chubby就是利用Paxos来实现多副本日志同步。

3.如何将Paxos应用于传统的数据库复制协议中？
    复制协议相当于是对Paxos的定制应用，通过对一系列日志进行投票确认达成多数派，就相当于日志已经在多数派持久化成功。副本通过应用已经持久化的日志，实现与Master节点同步。由于数据库ACID特性，本质是由一个一致的状态到另外一个一致的状态，每次事务操作都是对应数据库状态的变更，并生成一条日志。由于client操作有先后顺序，因此需要保证日志的先后的顺序，在任何副本中，不仅仅要保证所有日志都持久化了，而且要保证顺序。对于每条日志，通过一个logID标示，logID严格递增(标示顺序)，由leader对每个日志进行投票达成多数派，如果中途发生了leader切换，对于新leader中logID的“空洞”，需要重新投票，确认日志的有效性。

4.Multi-Paxos的非leader节点可以提供服务吗？
     Multi-Paxos协议中只有leader确保包含了所有已经已经持久化的日志，当然本地已经持久化的日志不一定达成了多数派，因此对于没有confirm的日志，需要再进行一次投票，然后将最新的结果返回给client。而非leader节点不一定有所有最新的数据，需要通过leader确认，所以一般工程实现中，所有的读写服务都由leader提供。

5.客户端请求过程中失败了，如何处理？
     client向leader发起一次请求，leader在返回前crash了。对于client而言，这次操作可能成功也可能失败。因此client需要检查操作的结果，确定是否要重新操作。如果leader在本地持久化后，并没有达成多数派时就crash，新leader首先会从各个副本获取最大的logID作为恢复结束点，对于它本地没有confirm的日志进行Paxos确认，如果此时达成多数派，则应用成功，如果没有则不应用。client进行检查时，会知道它的操作是否成功。当然具体工程实践中，这里面涉及到client超时时间，以及选主的时间和日志恢复时间。

paxos分布式算法的几个问题.

算法就是流程+实体(属性). 并且能最终得到结果. (面向不是人的产品)

关键字,选举投票.

1. 为什么要有两阶段提交?

2. 怎么证明当咨询者(proposor)知道半数的人认可某观点后(accepted),就可以认为该观点就是最终观点,自己不用再重新下一轮提出议案了,不会被后面的人改变?

3. 怎么证明paxos是会收敛的.

答案:

1. 为什么要有两阶段提交?

     提交提案的人和决定者分开时.

     可能有新的提案者会冒出来. 那么他需要先问下决定者是不是已经有观点了. 当超过半数都是同一个观点时他就不需要再提新的议案了. 这就是prepare阶段.

     这个是 paxos 算法最创新的部分, 原有加锁表面上是一步, 本质上是两步. 1. 加锁 2.选举..

    分布式下.

            1.  先 预加锁

            2.  返回加锁结果,如果超过半数的法官都认可加锁才能继续提交3, 否则重新走1 ,如果法官告知的结果有一个结果超过半数. 走到4

            3.  提交自己的议案

            4.  结束,接受结果

   在multi paxos的过程中, zk 和raft 根本上都利用了这个两阶段概念,实现了最终算法. 所有的paxos instance共用同一个prepare 阶段.[1 ]

2. 怎么证明当咨询者(proposor)知道半数的人认可某观点(accpted)后,就可以认为该观点就是最终观点,不会被后面的人改变?

     反证法. 如果还能被修改,说明被别人半数预加锁(prepare阶段)成功了. 如果被别人半数预加锁(prepare阶段)成功 ,那么就不可能被被半数accpted

    材料:  promiseIndex用来try锁,每次promise时变更;accpetedIndex用来收敛value,在每次接受时更改.

                           promise阶段半数原则结合acccpted阶段超半数原则用来证明此结论.

                      半数的作用是对集群的一种变相锁. 由于是集群的非原子的,用两次锁的模式来实现类似与锁单机的原理. 这是proxy精妙的地方.

    promise

    commit (获取最新的accptedIndex的value)

    接受accpted消息.

      当一个人接受到超过半数的accpted消息时,说明promise时的try锁至少成功维持了半数. 说明

      2.1. 这个accpetedIndex肯定是当前最新最大的. (因为已经锁住了半数的锁,能证明别人在这个promise和accpeted过程中没有commit过);

      2.2. 所以当其他人想再次promise的时候,拿到超过半数的提交许可,这里面肯定有上次最新的accpetedIndex和value(就是上面这个value),最终收敛到这个value上.

   反例说明: 1 A ，2A ，3B .某个人得到A,B. 认为没有超过半数票. 就重新发起了投票B,将A,B改成了B，B。

        上面例子里有个问题。因为一旦B的acceptN肯定小于A的acceptN。

       因为超过半数的已经接受了A，说明之前已经锁定了。后面不可能把3的acceptN更改为比1，2的更新

3. paxos算法的收敛怎么证明理解?

   因为最终commit都需要从已接受的value中选择一个promiseIndex最大的. 所以肯定是不会越来越多.通过几次偶然性就会收敛到某一个值.

   

我原本想的改进(其实是错误的): 可以在短期内不再接受新的promise,不再更改promisedIndex. (错误原因:这个会导致所有人都无法获得半数以上的index.)

附录:

  分布式一致性协议学习笔记（一）--Paxos

IT牛人博客聚合 - 图解分布式一致性协议Paxos

比较通俗易懂的视频：知行学社 paxos

(from http://codemacro.com/2014/10/15/explain-poxos/ or  知行学社——paxos和分布式系统_哔哩哔哩_bilibili)

每个节点拥有的三个关键值,各个阶段的读写. 算法就是流程+实体(属性). 并且能最终得到输出.

   -----

参考文档

https://ramcloud.stanford.edu/~ongaro/userstudy/paxos.pdf

http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/paper2-1.pdf
http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf
https://zhuanlan.zhihu.com/p/20417442
http://my.oschina.net/hgfdoing/blog/666781
http://www.cnblogs.com/foxmailed/p/5487533.html
http://www.wtoutiao.com/p/1a7mSx6.html

附录:

分布式理论之一：Paxos算法的通俗理解

维基的简介：Paxos算法是莱斯利·兰伯特（Leslie Lamport，就是 LaTeX 中的"La"，此人现在在微软研究院）于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。

Paxos算法目前在Google的Chubby、MegaStore、Spanner等系统中得到了应用，Hadoop中的ZooKeeper也使用了Paxos算法，在上面的各个系统中，使用的算法与Lamport提出的原始Paxos并不完全一样，这个以后再慢慢分析。本博文的目的是，如何让一个小白在半个小时之内理解Paxos算法的思想。小白可能对数学不感兴趣，对分布式的复杂理论不熟悉，只是一个入门级程序员。之所以想写这篇博文，是因为自己看了网上很多介绍Paxos算法的文章，以及博客，包括Lamport的论文，感觉还是难以理解，大多过于复杂，本人一直认为，复杂高深的理论背后一定基于一些通用的规律，而这些通用的规律在生活中其实我们早就遇到过，甚至用过。所以，我们先忽略Paxos算法本身，从生活中的小事开始谈起。

 假如有一群驴友要决定中秋节去旅游，这群驴友分布在全国各地，假定一共25个人，分别在不同的省，要决定到底去拉萨、昆明、三亚等等哪个地点（会合时间中秋节已经定了，此时需要决定旅游地）。最直接的方式当然就是建一个QQ群，大家都在里面投票，按照少数服从多数的原则。这种方式类似于“共享内存”实现的一致性，实现起来简单，但Paxos算法不是这种场景，因为Paxos算法认为这种方式有一个很大的问题，就是QQ服务器挂掉怎么办？Paxos的原则是容错性一定要很强。所以，Paxos的场景类似于这25个人相互之间只能发短信，需要解决的核心问题是，哪怕任意的一部分人（Paxos的目的其实是少于半数的人）“失联”了，其它人也能够在会合地点上达成一致。好了，怎么设计呢？

这25个人找了另外的5个人（当然这5个人可以从25个人中选，这里为了描述方便，就单拿出另外5个人），比如北京、上海、广州、深圳、成都的5个人，25个人都给他们发短信，告诉自己倾向的旅游地。这5个人相互之间可以并不通信，只接受25个人发过来的短信。这25个人我们称为驴友，那5个人称为队长。

先来看驴友的逻辑。驴友可以给任意5个队长都发短信，发短信的过程分为两个步骤：

第一步（申请阶段）：询问5个队长，试图与队长沟通旅游地。因为每个队长一直会收到不同驴友的短信，不能跟多个驴友一起沟通，在任何时刻只能跟一个驴友沟通，按照什么原则才能做到公平公正公开呢？这些短信都带有发送时间，队长采用的原则是同意与短信发送时间最新的驴友沟通，如果出现了更新的短信，则与短信更新的驴友沟通。总之，作为一个有话语权的人，只有时刻保持倾听最新的呼声，才能做出最明智的选择。在驴友发出短信后，等着队长回复。某些队长可能会回复说，你这条短信太老了，我不与你沟通；有些队长则可能返回说，你的短信是我收到的最新的，我同意跟你沟通。对于后面这些队长，还得返回自己决定的旅游地。关于队长是怎么决定旅游地的，后面再说。

对于驴友来说，第一步必须至少有半数以上队长都同意沟通了，才能进入下一步。否则，你连沟通的资格都没有，一直在那儿狂发吧。你发的短信更新，你获得沟通权的可能性才更大。。。。。。

因为至少有半数以上队长（也就是3个队长以上）同意，你才能与队长们进行实质性的沟通，也就是进入第二步；而队长在任何时候只能跟1个驴友沟通，所以，在任何时候，不可能出现两个驴友都达到了这个状态。。。当然，你可以通过狂发短信把沟通权抢了。。。。

对于获得沟通权的那个驴友（称为A），那些队长会给他发送他们自己决定的旅游地（也可能都还没有决定）。可以看出，各个队长是自己决定旅游地的，队长之间无需沟通。

第二步（沟通阶段）：这个幸运的驴友收到了队长们给他发的旅游地，可能有几种情况：

第一种情况：跟A沟通的队长们（不一定是全部5个队长，但是半数以上）全部都还没有决定到底去那儿旅游，此时驴友A心花怒放，给这些队长发第二条短信，告诉他们自己希望的旅游地（比如马尔代夫）；

可能会收到两种结果：一是半数以上队长都同意了，于是表明A建议的马尔代夫被半数以上队长都同意了，整个决定过程完毕了，其它驴友迟早会知道这个消息的，A先去收拾东西准备去马尔代夫；除此之外，表明失败。可能队长出故障了，比如某个队长在跟女朋友打电话等等，也可能被其它驴友抢占沟通权了（因为队长喜新厌旧嘛，只有要更新的驴友给自己发短信，自己就与新人沟通，A的建议队长不同意）等等。不管怎么说，苦逼的A还得重新从第一步开始，重新给队长们发短信申请。

第二种情况：至少有一个队长已经决定旅游地了，A可能会收到来自不同队长决定的多个旅游地，这些旅游地是不同队长跟不同驴友在不同时间上做出的决定，那么，A会先看一下，是不是有的旅游地已经被半数以上队长同意了（比如3个队长都同意去三亚，1个同意去昆明，另外一个没搭理A），如果出现了这种情况，那就别扯了，说明整个决定过程已经达成一致了，收拾收拾准备去三亚吧，结束了；如果都没有达到半数以上（比如1个同意去昆明，1个同意去三亚，2个同意去拉萨，1个没搭理我），A作为一个高素质驴友，也不按照自己的意愿乱来了（Paxos的关键所在，后者认同前者，否则整个决定过程永无止境），虽然自己原来可能想去马尔代夫等等。就给队长们发第二条短信的时候，告诉他们自己希望的旅游地，就是自己收到的那堆旅游地中最新决定的那个。（比如，去昆明那个是北京那个队长前1分钟决定的，去三亚的决定是上海那个队长1个小时之前做出来的，于是顶昆明）。驴友A的想法是，既然有队长已经做决定了，那我就干脆顶最新那个决定。

从上面的逻辑可以看出，一旦某个时刻有半数以上队长同意了某个地点比如昆明，紧跟着后面的驴友B继续发短信时，如果获得沟通权，因为半数以上队长都同意与B沟通了，说明B收到了来自半数以上队长发过来的消息，B必然会收到至少一个队长给他发的昆明这个结果（否则说明半数以上队长都没有同意昆明这个结果，这显然与前面的假设矛盾），B于是会顶这个最新地点，不会更改，因为后面的驴友都会顶昆明，因此同意昆明的队长越来越多，最终必然达成一致。

看完了驴友的逻辑，那么队长的逻辑是什么呢？

队长的逻辑比较简单。

在申请阶段，队长只会选择与最新发申请短信的驴友沟通，队长知道自己接收到最新短信的时间，对于更老的短信，队长不会搭理；队长同意沟通了的话，会把自己决定的旅游地（或者还没决定这一信息）发给驴友。

在沟通阶段，驴友C会把自己希望的旅游地发过来（同时会附加上自己申请短信的时间，比如3分钟前），所以队长要检查一下，如果这个时间（3分钟前）确实是当前自己最新接收到申请短信的时间（说明这段时间没有驴友要跟自己沟通），那么，队长就同意驴友C的这个旅游地了（比如昆明，哪怕自己1个小时前已经做过去三亚的决定，谁让C更新呢，于是更新为昆明）；如果不是最新的，说明这3分钟内又有其它驴友D跟自己申请了，因为自己是个喜新厌旧的家伙，同意与D沟通了，所以驴友C的决定自己不会同意，等着D一会儿要发过来的决定吧。

Paxos的基本思想大致就是上面的过程。可以看出，其实驴友的策略才是Paxos的关键。让我们来跟理论对应一下。

[1 ] Multi Paxos https://blog.csdn.net/fei33423/article/details/129040568