分布式系统理论：一致性协议Paxos

　　Paxos算法是莱斯利·兰伯特(Leslie Lamport)于1990年提出的一种基于消息传递的一致性算法。 Paxos 算法是一个解决分布式系统中，多个节点之间就某个值(注意是某一个值，不是一系列值)达成一致的通信协议。能够处理在少数派离线的情况下，剩余的多数派节点仍然能够达成一致。 Lamport是通过故事的方式提出Paxos 问题：

　　希腊岛屿Paxon 上的执法者在议会大厅中表决通过法律(一次paxos过程)，并通过服务员(proposer)传递纸条的方式交流信息，每个执法者会将通过的法律记录在自己的账目上。问题在于执法者和服务员都不可靠，他们随时会因为各种事情离开议会大厅(服务器拓机或网络断开)，并随时可能有新的执法者进入议会大厅进行法律表决(新加入机器)，使用何种方式能够使得这个表决过程正常进行，且通过的法律不发生矛盾(对一个值达成一致)。 注意：paxos过程中不存在拜占庭将军问题(消息不会被篡改)和两将军问题(信道可靠)。 paxos 协议中有四种角色：

　　client 议题产生者，产生一个待分布式系统达成一致的值v

　　proposer 提议者，用client产生的值v，向acceptor发出提议

　　acceptor 决策者，决定是否接受proposer的提议，大多数接受了提议，结果达成一致，达成一致的结果不可更改

　　learner 决策学习者，学习最终达成一致的结果。一旦学习成功，关闭对应的paxos过程(paxos instance)，并通知acceptor(或acceptor主动向learner获取)。

　　这四种角色中，proposer和acceptor比较重要，协议主要的交互逻辑都在这两种角色中。

　　paxos 是一个两阶段的通信协议：

　　第一阶段 Prepare

　　client产生一个值v，并告知proposer，我这里产生了一个待accept的值。

　　proposer收到通知后，生成一个全局唯一并且递增的提案ID，带着这个ID(不需要携带v)向集群中的所有acceptor发送PrepareRequest请求。 acceptor收到PrepareRequest请求后，检查一下之前接收到的提案ID(包括第一阶段和第二阶段)，新接收的提案ID用n表示,之前接收到的提案ID用N表示。如果n = N，返回拒绝，并携带N的值。如果n N，把n记录下来，以后不再接收提案ID比n小的提议，这时分两种情况：

　　之前没有accept任何值v，返回可以接收提议

　　之前已经accept过值，返回可以接收提议，并携带已经accept的，并且提案ID最大的值

　　第二阶段 Accept

　　如果proposer收到大多数acceptor的拒绝应答，回到第一阶段，根据接收到的最大的N，把提案ID增大，继续发送PrepareRequest。

　　如果proposer收到大多数acceptor可以接收提议的应答，从多个应答中选出提案ID最大的值(第一阶段如果acceptor已经accept过值，会返回提案ID最大的值)，作为提案值。如果应答中没有值，选择client产生的值v作为提案值。然后携带当前的提案ID，一起向集群中所有acceptor发送AccpetRequest请求。 对这段话进行解释：第一阶段client产生的值v，不一定作为Accept阶段的提案值。为了更快的达成一致，如果之前已经accept了值，那么proposer会倾向于把提案值修改为之前接受的值。各个proposer不是针锋相对，而是合作共赢。 acceptor收到AccpetRequest后，检查请求中携带的提案ID，如果此提案ID大于或等于acceptor记录的提案ID(在第一阶段和第二阶段，acceptor记录最大的提案ID)，接受提议并记录提案ID和提案值。否则拒绝，并返回记录的提案ID。 proposer收到大多数acceptor接受提案的应答，形成决议，达成一致。

　　如果proposer收到大多数acceptor拒绝的应答，回到第一阶段，把提案增大(增加幅度依据acceptor返回的提案ID)，发送PrepareRequest。

　　举个例子帮助理解paxos协议，把整个paxos协议的流程想象成一次竞标。有两个老板(client)，每个老板都有一个属于自己的秘书(proposer)，还有3个政府官员(acceptor)。

　　第一阶段

　　两个老板(client)分别提出议题：“XXX项目我要中标”，各自的秘书(proposer)带着现金(提案ID)，去找政府官员(acceptor)。

　　作为政府官员(acceptor)，谁给的钱多答应给谁中标(只是口头答应，并没有签约)。钱少的直接拒绝。

　　场景1：秘书p1带着10000美金去找3个官员a1、a2、a3，这时候还没有人来找过a1、a2、a3，所以这3个官员直接就答应了p1，并告诉p1他们之前没有接受过任何提议。这样p1在一阶段获得了全票支持。过一会，秘书p2带着8000美金去找3个官员，3个官员一看只有8000美金，直接拒绝p2，告诉p2别人已经出价10000。

　　场景2：p1的行为和第一个场景相同。p2带着12000美金去找3个官员，3个官员一看p2给的钱比p1多，把p2的钱记下来，很高兴的告诉p2，可以接收p2的提议。这样在第一阶段p1和p2都获得了全票支持。

　　场景3：p1和p2同时带着10000美金去找3个官员，p1先找到了a1、a2，此时没有人找过a1和a2，a1和a2答应p1，告诉p1他们之前没有接受过任何提议。p2在p1之前找到了a3，之前没有人找过a3，a3答应p2，告诉p2他之前没有接受过任何提议。这时候p1也找到了a3，a3一看和之前收到的钱一样多，拒绝了p1。同样，在p2找到a1和a2时，应为钱数一样，也被拒绝。最终，在第一阶段，p1获得2票(a1和a2)，超过半数，p1可以进入第二阶段。p2获得1票，少于半数，p2被打回第一阶段。

　　第二阶段

　　场景1：在第一阶段p1获得了全票支持，p1带着老板的议题去找官员签合同，并告诉官员之前已经给了10000美金。官员看了一下收款记录，没错是10000美金，3个官员和p1成功签约，达成一致。在第一阶段p2被拒绝，这时p2回到第一阶段，带了12000美金去找官员。官员一看12000比刚才接受的10000多，告诉p2，你的钱多，可以接受你的议题，但是之前已经接受了p1的议题，p1的议题内容为“XXXXXX”。p2看了下p1的议题，觉得自己的老板没前途，干脆跟着p1的老板干算了，于是把自己的议题修改为p1的议题(为了更快达成一致)。p2带着修改之后的议题去找官员，告诉官员之前给了12000。官员看了一下记录，没错是12000，接受了p2的议题(这时p2的议题和p1一样，虽然官员同时接受了p1和p2，但是系统仍然是一致的)。

　　场景2：在第一阶段p1获得了全票支持，p1带着老板的议题去找官员签合同，并告诉官员之前已经给了10000美金。官员看了一下收款记录，记录上写的是12000，于是告诉p1，已经有人出了12000，我们不能accept你的提议。在第一阶段p2也获得了全票支持，这时候p2来找官员，告诉官员之前给了12000，官员核实了一下记录，发现没错，接受了p2的议题。p1被拒绝后，回到第一阶段，带了14000美金去找官员。官员一看14000比刚才接受的12000多，告诉p1，你的钱多，可以接受你的议题，但是之前已经接受了p2的议题，p2的议题内容为“XXXXXX”。p1看了下p2的议题，觉得自己的老板没前途，干脆跟着p2的老板干算了，于是把自己的议题修改为p2的议题(为了更快达成一致)。p1带着修改之后的议题去找官员，告诉官员之前给了14000。官员看了一下记录，没错是14000，接受了p1的议题(这时p1的议题和p2一样，虽然官员同时接受了p1和p2，但是系统仍然是一致的)。

　　场景3-1：在第一阶段p1获得a1、a2的应答，p1带着老板的议题去找a1、a2签合同，并告诉a1、a2之前已经给了10000美金。核实之后，a1和a2接受了p1的议题。由于大多数官员接受了p1的议题，所以p1的议题被确定接受。

　　场景3-2：在第一阶段p1获得a1、a2的应答，p1带着老板的议题去找a1、a2签合同。但是p2在被打回第一阶段后，以很快的速度带着12000美金，赶在p1之前再次找到a1和a2以及a3。a1、a2、a3答应p2，并把记录金额修改为12000，并告诉p2，我们没有接受任何议题(p1还在签约途中)。这时p1终于找到了a1和a2，准备签约，但是a1和a2告诉p1，我们刚才收了12000，比你给的10000要多，拒绝接受你的议题，p1被打回第一阶段。在第一阶段p2获得全票，于是带着议题去找a1、a2、a3签约，a1、a2、a3核实金额之后，成功签约，达成一致。

　　paxos协议中的活锁问题

　　在上边描述的场景中，如果在官员签约之前，p1和p2一直不停的往上加金额，就算进入第二阶段，也会因为有更高的报价，导致签约失败被打回第一阶段。就像拍卖会中，多个买家一直往上飙价格，最后一件东西都没有卖出去。这种情况称为活锁，没有产生阻塞，但是一直无法达成一致。

　　有三种解决方案：

　　在被打回第一阶段再次发起PrepareRequest请求前加入随机等待时间。

　　设置一个超时时间，到达超时时间后，不再接收PrepareRequest请求。

　　在proposer中选举出一个leader，通过leader统一发出PrepareRequest和AcceptRequest。

　　multi paxos

　　一次paxos过程(paxos instance)只能对一个值达成一致。multi paxos是运行多个paxos instance来对多个值达成一致。

　　下边以MySQL组复制为例，说明multi paxos。

　　MySQL组复制中存在多个master，可以同时接受client写入和读取数据，并且可以保证多个master中数据一致，每一次写入数据都会生成一条log日志，通过paxos协议进行一致性处理，达成一致之后完成log复制。针对一系列操作，需要运行多次paxos过程(paxos instance)，需要引入一个ID来标识相应的paxos instance，这里用logID表示。每一次写入操作，都生成一个logID与log日志对应，也同时与paxos instance对应，logID全局唯一且自增。

　　有了logID之后，每个paxos instance独立运行，可以对每条log日志达成一致。这样问题貌似已经解决了，但是还有优化的空间。

　　每一次paxos instance都是一个两阶段过程(prepare和accept)，所有proposer地位平等，都可以提出议题。在有多个proposer同时提出议题时，有很大概率冲突，每次冲突都会重新执行prepare阶段，网络和性能开销较大。同时paxos协议本身存在活锁问题，有可能导致一个议题始终无法达成一致。为了解决这两个问题，multi paxos中引入了leader的概念，从多个proposer中选举出一个leader作为提议代表，每个提议都通过leader发出。这样的话，解决了活锁问题(活锁问题的第三个解决方案)。因为提议都是通过leader发出，只要leader保证提案ID自增，就可以跳过prepare阶段，直接进行accept阶段(两阶段变为一阶段)。

　　那么问题来了，如何选举leader?运行一次paxos instance，提议的v就是“选举自己为leader”。但是还有问题，一次paxos instance只能对一个值达成一致。举个例子：A、B、C三台机器，运行paxos选举leader。第一次选举产生结果，A是leader。之后A拓机，再次运行paxos，选举的结果还是A是leader。运行多个paxos instance(multi paxos)可以选举出不同的leader，但是multi paxos需要选举出一个leader来优化网络损耗和活锁的问题，这里产生一个问题递归依赖。

　　换个思路，给每一个达成一致的值v一个过期时间，达到过期时间清空v，这样用一个paxos instance就可以选出不同的leader。每台机器上都启动一个倒计时T，leader在存活状态下，不断重置T，T在倒计时为零时清空上次选举的结果，并发起选举。

　　上边简单说明了一种选举leader的算法，通过选举leader，可以提高paxos的性能(两阶段变为一阶段)，并解决活锁问题。paxos的正确性不依赖于选举结果，在选举失败或者同时选出多个leader的情况下，退化为普通paxos。

　　总结

　　paxos协议可以归纳为几个原则：

　　不接受旧值(通过递增ID确定新旧)

　　为了更快达成一致，proposer会把值修改为最有可能达成一致的值

　　只有多数派接受了值，值才达成一致

　　一旦一个值达成一致，不可更改

　　paxos是一致性协议的基础，其他的协议(raft、zab等)都是paxos的改进版本。paxos侧重理论，实现paxos非常困难。谷歌chubby论文中提到，从paxos出发，在实现过程中处理了很多实际中的细节之后，已经变成另外一个算法了，这时候正确性无法得到理论的保证。所以才出现了许多基于paxos的改进算法。

​