PaxosLease

世上有很多选举算法，但最完美的莫过于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编号

算法过程

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

初始状态A=(1)、B=(1)、C=N/A# P1 提交编号(3,v3)到A、B成功完成了prepare、accept阶段，编号3,v1被选为最终决议
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，在[t_acquire,t_end]之间获得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。

PaxosLease相关推荐

想从事分布式系统，计算，hadoop等方面，需要哪些基础，推荐哪些书籍？--转自知乎...
作者:廖君链接:https://www.zhihu.com/question/19868791/answer/88873783 来源:知乎分布式系统(Distributed System)资料 & ...
分布式系统(Distributed System)资料
分布式系统(Distributed System)资料 <Reconfigurable Distributed Storage for Dynamic Networks> 介绍:这是一篇介 ...
盘点2013：21款最优秀的开源数据库
作为一名软件开发人员或DBA,其中一份必不可少的工作就是与数据库打交道,比如MS SQL服务器.MySQL.Oracle.PostgreSQL.MongoDB等等.众所周知,其中MySQL是目前使用最 ...
Paxos 算法浅析
Paxos 算法浅析 xiewen 关注 2016.07.19 17:24* 字数 3613 阅读 3740评论 0喜欢 22 持续更新如何浅显易懂地解说 Paxos 的算法? 参考资料 #8:知 ...
区块链快速入门（三）——CFT（非拜占庭容错）共识算法
一.CFT简介 CFT(Crash Fault Tolerance),即故障容错,是非拜占庭问题的容错技术. Paxos 问题是指分布式的系统中存在故障(crash fault),但不存在恶意(cor ...
五：分布式事务一致性协议paxos的应用场景
1.应用场景 (1)分布式中的一致性 Paxos算法主要是解决一致性问题,关于"一致性",在不同的场景有不同的解释: NoSQL领域:一致性更强调"能读到新写入的&quo ...
介绍的比较全面中国人最容易懂的paxos
Paxos算法的难理解与算法的知名度一样令人敬仰,从我个人的经历而言,难理解的原因并不是该算法高深到大家智商不够,而在于Lamport在表达该算法时过于晦涩且缺乏一个完整的应用场景.如果大师能换种思路 ...
21款最优秀的开源数据库
摘要:几乎所有软件项目的开发都需要数据库的支持,目前,随着开源技术的迅速发展,越来越多的数据供应商选择开源数据库,为开源事业添砖加瓦. 作为一名软件开发人员或DBA,其中一份必不可少的工作就是与数据库 ...
[转]Paxos算法-算法形成理论
paxos的作者自述paxos is simple,看了不少遍还没有读懂,说明真的不simple 还好有强大的网络,转篇齐全的原文地址:http://blog.csdn.net/chen77716/ ...