世上有很多选举算法，但最完美的莫过于Paxos，但把paxos用于master选举与用于value的选举有用众多不同之处，主要一点是二者执行频率不同。value选举需要频繁、高密度地执行paxos算法，每instance选举一个value。因此，原生的paxos算法无法满足高性能的要求；另一个问题是，paxos理论上存在活锁，lamprot推荐大家通过选举Leader避免这个问题。

所有的实现都指向一个Leader/Master，但Master的选举又该如何实现？如果继续采用paxos那性能和活锁又该如何解决？这个似乎是个递归问题，用paxos解决paxos遇到的问题。能实现吗？能，Keyspace的PaxosLease算法给出了答案。

1. Lease

Master选举的过程是这样的：从众多的Node中选择一个作为Master，如果该Master一致alive则无需选举，如果master crash，则其他的node进行选举下一个master。选择正确性的保证是：任何时刻最多只能有一个master。

逻辑上Master更像一把无形的锁，任何一个节点拿到这个锁，都可成为master，所以本质上Master选举是个分布式锁的问题，但完全靠锁来解决选举问题也是有风险的：如果一个Node拿到了锁，之后crash，那锁会导致无法释放，即死锁。一种可行的方案是给锁加个时间（Lease），拿到锁的Master只能在Lease有效期内访问锁定的资源，在Lease timeout后，其他Node可以继续竞争锁，这就从根本上避免了死锁。

Master在拿到锁后，如果一直alive，可以向其他node”续租“锁，从而避免频繁的选举活动。关于Lease更多的请参考：http://research.microsoft.com/en-us/um/people/blampson/58-consensus/webpage.html

2. Master选举

Master选举与value选举存在几个不同的地方：

• 执行频率低（正常情况下，Node失败概率不会太高）
• 无Paxos的持久化，重启后状态丢失

为了保证选举正确性，还要保证：

• 保证算法纯正性，不依赖与其他算法

3. PaxosLease

PaxosLease是Kespace开发的基于Paxos、Lease的Master选举算法，算法的角色与Paxos一样，也分Proposer、Acceptor、Learn，各角色的行为也与paxos基本一致，但除下面两个重要的区别：

• 不要求acceptor持久化数据
• 不存在Leader

PaxosLease把Paxos的accept阶段重新命名为propose，因此存在prepare、propose2个阶段。

再引入几个符号：

• T：每个Master的Lease时间（秒）
• M：全局Lease时间，要确保 M > T
• ballot number：每次发送的proposal编号

算法过程

1. proposer启动定时器Timer1，等待T秒便超时
2. proposer向acceptor发送(ballot number，proposer id，T）
3. acceptor接收到prepare消息后，判断：
   • 如果msg.ballot_number < local.promisedBallotNumber，则发送拒绝消息
   • 否则，发送accept，包含的内容已经promise的最大编号和T
4. proposer接收acceptor的response
   • 如果多数派accept，则进入promise阶段
   • 否则，随机等待一段时间，提高编号重启prepare过程
5. proposer执行promise阶段
   • 如果prepare阶段接收的value不为空，则终止promise
   • 否则，发送(ballot number,proposer id ,T）
6. acceptor接收到promise请求
   • 如果msg.ballot_number < local.promisedBallotNumber，则回应拒绝消息
   • 否则，启动定时器Timer2，等待T秒超时
7. proposer接收acceptor的response
   • 如果接收到多数派的回应
     • 删除Timer1
     • 启动extend Timer3，等待时间T1 < T
     • 发送Learn消息，转入8
   • 否则，重启prepare过程
8.  Learn接收到proposer的learn消息
   • 停止Timer1
   • 重新启动Timer1

因为proposer、acceptor、learn三位一体，所以上述提到的Timer1、Timer2、Timer3其实位于同一Node，同一进程。

• Timer1：等待时间T，超时便发起prepare请求
• Timer2：等待时间T，超时便清空本次paxos instance状态，继续下一次
• Timer3：等待时间T1 < T，超时便执行prepare

Timer1运行于所有的Node，任何一个Node的Timer1超时便发起prepare请求

Timer2仅运行与参与选举过程的Node，如果超期则清空本次选举状态

Timer3仅运行于获得lease的节点，目的是在lease超期之前续租

4. Paxos

移除lease相关部分，上述过程其实就是一次paxos instance，但第5步与原始paxos算法稍有不同：

• 原始的paxos规定，如果接收的value v不为空，则使用v继续accept阶段，以保证每次选举仅选出一个决议；

• PaxosLease选举的目的是使其他node接受自己作为master，当接收的value不为空时，自己应该退出选举，而不是继续提交其他Node的value。也就是说，只要当前node知道其他Node可能会优先自己成为master，则退出选举，成就他人。

因为每个节点都始终运行着Timer1，只要超时便开始prepare，因此paxosleas不存在静态死锁问题，但动态死该怎么解决？之前关于paxos算法的介绍得知，在paxos中存在活锁，也即动态死锁，表现为在prepare阶段2个proposer会转而提出更高编号的proposal，PaxosLease提供的解决办法就是在失败重新提交proposal时随机等待一段时间，因为各Node等待时间的不一致，只要运行足够长的时间，活锁总能避免。

传统的Paxos是否可以采取这样的方法避免活锁？答案是否定的，之前说过，value选举的频率高、延迟低，不能容忍提交proposal时等待几秒。而Master选举因为频率低，却可以容忍上述方法带来的性能损失。

因为运行PaxosLease的所有节点都没有持久化，当Node重启时所有的状态都会丢失，这样重新加入的节点可能会扰乱前面的paxos过程，因此强制Node在重新加入前必须等待M秒，因为M > T，所以只要等待M秒便可以越过本次paxos选举。其实即使等待M秒，也不能从理论上完全保证PaxosLease能正确执行，要搞清楚这个我问题，我们必须知道新加入的Node是如何扰乱了paxos过程：

假如存在三个Acceptor A、B、C，已经promised的最高编号分别为A =(1),B =(1),C =(1)；存在两个proposer P1,P2

1. 初始状态A=(1)、B=(1)、C=N/A# P1 提交编号(3,v3)到A、B成功完成了prepare、accept阶段，编号3,v1被选为最终决议
2. B宕机重启，状态丢失回到初始状态、A宕机、C重启，则A=N/A、B =(1)、C=(1)# P2提交编号(2,v2)到B、C也可成功完成preapare、accept阶段，编号2,v2被选为最终决议

存在v2、v3两个最终决议，违反了paxos的安全属性。如果B重启能记住之前的状态B=(3,v3)，P2则不会提交成功，从而能保证paxos的安全属性。这个错误发生要几个条件：

• 节点重启前作为多数派回应了prepaer、accept消息
• 其他节点也重启，并与当前节点构成最少多数派
• 之前的instance未结束，又回答了其他proposer的prepare、accept消息

反观M秒的设定，其实等待多少秒并不重要，重要的是重加入后不能立即参加paxos过程。在实际中因为选举的过程非常快，节点重加入的过程也可监控，这些理论上的错误是很难发生的。

Catch Up机制是否适用于PaxosLease？

在讨论paxos的实现时，曾提到如果节点磁盘失败，当重新加入时需要使用catch up，节点参与paxos过程，但不做任何回应，直至一次paxos过程完成。

但这个并不适合于PaxosLease，因为master选举的频率很低，如果等待一次paxos过程完成，节点要等很长的时间才能重新加入。

5. 正确性证明

PaxosLease是由3个精妙配合的Timer来工作的，Paxos算法的正确性是显然的，PaxosLease会不会在引入Timer之后改变其安全假设？请看下面简短证明：

首先引入几个符合：

• b：ballot number
• t_start：proposer启动Timer1的时间
• t_now：proposer在prepare阶段接收到多数派响应空value的时间
• t_acquire：proposer在propose阶段接收到多数派的accept时间
• A1：在prepare阶段回应proposer的多数派
• A2：在propose阶段回应proposer的多数派

假如proposer p已经获得了lease，则在t_end=t_start+T之内，其他proposer不会获得多数派acceptor响应空value，也即其他proposer不会获得lease。

Part1：不存在任何proposer q，编号b1<b，在[tacquire,tend]之间获得lease

假如q也在此期间获得了lease，则存在多数派A4在propose阶段回应了q，令a是A2和A4的公共成员，因为b1<b，a必定先接受了q的proposal，然后发送回应给p，因为p在propose阶段接收到了空value，说明q的Timer2已经超时，因此q的timer也肯定超时(b1<b，q的timer启动的更早)，因此p、q的lease并无重叠

Part2：不存在任何propose q，编号b1>b，在[t_acquire,t_end]之间获得lease

证明与上类似。

6. 结论

其实PaxosLease的正确性是有Paxos算法保证的，PaxosLease只是在Paxos的基础上限定了一个时间。在时间T之内，任何Node都不能申请lease，因此master宕机后重新选择master的最大时间为T，也即服务不可用的最大时间为T。

T设的过小会减少服务不可用的时间，但会产生更多的内部消息；设的过大内部消息减少，但会导致更长的宕机时间。

PaxosLease是一个节点之间不存在依赖的简洁的选举算法，就像其论文所说每个节点都有两个状态：

• 我不是master，也不知道谁是master
• 我是master

正因为如此，PaxosLease的缺点就是无法做到负载均衡，无法按权重选择master。