DPaxos : 如何降低Paxos延迟 | 前沿

Posted 2021-04-17 XEngine

Lamport 提出的paxos协议作为最经典的一致性协议，是现代分布式系统最流行的共识算法， Paxos能够确保不论发生任何进程或者消息异常，分布式系统都能就某个值达成一致。然而在Basic paxos以及很多的变种协议中都有多数派的前提， 这会导致协议共识的达成需要较长的时间。为了降低时延问题，16年 Howard Heidi等人提出了Flexible Paxos，在此基础上Nawab, Faisal等人提出的DPaxos， 提出一种针对节点众多且遍布全球的场景下如和高效运转一致性协议的方案，并发表于今年的SIGMOD18上。 本文回顾Flexible Paxos的贡献，并且对今年的DPaxos进行解读。

共识问题

共识问题是分布式系统中的老大难问题：多个参与者如何就某一个值达成一致。比如，小区门口的煎饼果子老板们对煎饼果子进行统一定价，期末考时几个徒有其名的学霸对答案等等；可是这有什么难的呢？老板们互相喊一声就好了，学霸把答案拍下来互相发一下就行了嘛。那我们就加上一些分布式系统的约束条件吧：

1.为了不让顾客知道他们的意图，煎饼果子老板们不能吼一嗓子或比划手势来对价格；

2.由于要给摊位前的顾客做煎饼果子，他们也走不开，因此不能聚起来合计合计；

4.定价4块还是5块不重要，重要的是各位老板的售价必须是一样的；否则，晚上收摊时，可能会认为定价不一样的老板耍心机而打起架来。

多年来，学者们为了解决这个煎饼果子老板定价问题，提出了众多的解决方案。其中lamport提出的基于majority quorum的paxos协议，就是比较流行的一种了。

Basic Paxos

paxos协议是解决分布式共识问题的著名算法。由Leslie Lamport于1998年提出。paxos解决了分布式环境下，多个参与者就一个值达成一致的问题。其分为如下四个步骤：

1.Prepare:一个提议者获取一个全局递增的序列号（proposal number）p，并将p附带在发给majority接受者的prepare请求中。

2.Promise: 若一个接受者接收到的prepare请求的序号p，比任何它已经回复的prepare请求的序号都要大，那么它记录下该序列号，并向这个提议者回复一个promise请求，表明它不会再接受任何比序号p更小的prepare请求。如果该接受者已经接受了一个提议，那么它同时也会向该提议者发送已接受的提议。

3.Propose: 如果提议者收到了其序列号为p的prepare请求的majority接受者的回复，那么提议者向这些发送promise请求的接受者发送一个accept请求。该请求的序列号为p，值为所有接收到的promise请求附带的提议中，序列号最大的提议的值v。

4.Accept:如果一个接受者接收到一个序列号为p的accept请求，并且它没有回复一个序列号比p大的prepare请求，那么该接受者就会接受这个accept请求。

一般而言，我们将上述Prepare和Promise步骤合称为Prepare阶段，而Propose和Accept步骤合称为Propose阶段。paxos保证了一旦一个值v被选中，那么最终大家都会对值v达成一致，而不会再选择v以外的值。

paxos利用majority quorum巧妙地解决了共识问题。不过，在许多paxos的应用中，majority quorum所产生的通信延迟成为了系统的瓶颈。比如，在状态机复制中，需要对一系列值进行一致性地复制。那么paxos的通信延迟很大层度上决定了状态机复制的性能。本文将阐述如何降低paxos协议延迟。特别的，通过减少Prepare或Propose阶段需要参与的节点数目来达到此目的。

FPaxos：Flexible Paxos

basic paxos的prepare和propose阶段都需要majority quorum。majority quorum保证了任意quorum之间交集不为空。该特性保证了paxos选择的值v的唯一性。两阶段paxos协议允许多个proposal被提出，但是任何被接受的两个proposal值必须是相同的。paxos的解决方法是: 后发起prepare阶段的提议者必须学习之前已经被接受的那些propose请求的值，并将该值作为自己propose请求的值。为了保证后发起prepare阶段的提议者不遗漏任何被接受的值v，paxos两个阶段的quorum需要彼此相交。

FPaxos认为，paxos的prepare阶段的quorum不需要相互相交，propose阶段的quorum也不需要相互相交；只需要Prepare-quorum（Q1）和Propose-quorum（Q2）相交。

在实际应用系统中，通常需要对一系列值达成一致，因此在basic paxos的基础上发展出了multi-paxos，第一个阶段（prepare）用来选出一个leader，该leader将在第二个阶段（propose）提出一系列的proposes。所以Q2比Q1执行的次数多得多。FPaxos根据上述发现，减小Q2大小，增大Q1大小。这样就减少了达成Q2的时间，提高了multi-paxos的性能。

将Q1的size记为|Q1|，Q2的size记为|Q2|，所有参与者的数目记为N。那么prepare阶段的fault-tolerance为N-|Q1|，propose阶段的fault-tolerance为N-|Q2|，减小|Q2|降低了达成Propose-quorum所需的时间，提高了fault-tolerance。但我们必须同时增大|Q1|（|Q1| ≥ N - |Q2| + 1），这使得prepare阶段的fault-tolerance降低了，亦即选主的fault-tolerance降低了。有趣的是，直到当前的leader crash，需要重新选举leader，即使N-|Q2|个节点crash（无法组成prepare-quorum），FPaxos仍然可以继续推进。如果在当前leader crash以前，已经crash的N-|Q2|个节点能够恢复使得在线节点达到|Q1|大小，那么FPaxos就可以表现得好像“这次大规模crash没有发生过一样”地正常工作下去。

基于上面的优化思路，FPaxos提出了3种实现方案：

1. Majority Quorums：当节点数目N为偶数时，multi-paxos要求|Q1|、|Q2|均至少为N/2+1。而对于FPaxos，我们可以将|Q2|降低到N/2，仍然保证两个阶段的quorums之间是相交的。

2. Simple Quorums：亦即上面提到的方案，其中每个节点都是对等的。

3.Grid Quorums：将N个节点组织为N2 * N1的grid。Q1必须为N2行中的一整行，Q2必须为N1列中的一整列。这样，任意的Q1和Q2必然是相交的。我们只需要调整grid的行列长度，即可调整|Q1|和|Q2|。注意，在Grid Quorums中，每个节点不是对等的。如，若当每一行均有一个节点crash，那么将没有合适的Q2。Grid Quorums的fault-tolerance不是一个固定的数值，而是区间[MIN(N1, N2), (N1-1)*(N2-1)]。

FPaxos的正确性通过确保只有一个值会被选中来保证。这可以通过证明任何的v'（p' > p）都与值v相等：

如果值v（序号p）已被选择，那么对于任意的v', p' > p，v'=v恒成立。

FPaxos给出了证明，在此不详细介绍了。在FPaxos论文的最后，作者提出了更进一步的优化，细心的读者或许已经通过上述介绍发现了这一优化：我们只要求序列号为p的propose的Q1和所有序列号< p的propose的Q2相交。如果一个quorum并不在任何Q2中，那么显然没有令Q1与其相交的必要。因此我们又将条件“任意的Q1$和Q2必须相交”进行了弱化。而这一潜在的优化方案，正是DPaxos的核心所在。

DPaxos：Dynamic Paxos

DPaxos发表于SIGMOD 2018， 为降低延迟，它发展了FPaxos文末所提到的进一步优化。DPaxos更适合移动应用、车载应用等场景。它们特点是，节点众多，且遍布世界各地。数据以分片的形式分布在这些边界节点上（edge nodes）。为了减少应用访问数据中心的延迟（100ms），DPaxos充分利用边界节点的计算资源，直接在边界节点进行事务处理。 而DPaxos实现的状态机复制（SMR）的延迟则极大地影响着系统的性能和用户体验。DPaxos针对性地解决这些场景下，multi-paxos协议延迟过大的问题，提出了Zone-centric Quorums和Dynamic Quorum Allocation。

Zone-centric Quorums

DPaxos将相邻的边界节点（edge nodes）组织为区（zone）。以zone作为quorum的单位，而zone本身的quorum单位则为其内部的edge nodes。以majority quorum为例，一次选举需要majority zones赞成，而每个zone则需要其内部的majority edge nodes赞成。根据FPaxos的发现，我们可以将replication quorums设置得很小，如一个zone，那么replication quorums的延迟可以被限制在一个zone的内部节点的通信延迟内，极大降低了频繁replication quorums的总延迟，提高了应用的性能表现。同时，为了尽量减小leader election quorums大小，DPaxos提出了Expanding Quorums（即dynamic quorum allocation）。

Expanding Quorums

expanding quorums是对FPaxos提出进一步优化的实现。由于leader election quorum（Q1）只需要和所有已经使用过的replication quorum（Q2）相交，DPaxos令所有leader在election阶段声明其将使用的Q2（DPaxos将其称为intent，intents随prepare消息一并发送），同时令所有Q1互相相交，这样就确保了后续的所有leader都能够学习到之前的所有Q2。DPaxos将FPaxos中Q1与Q2必须相交的情形称为Inter_Intersection，而DPaxos只需要所有Q1互相相交，称为Intra_Intersection。

正如上面提到的，DPaxos的leader只需要学习到之前使用过的Q2。为此，DPaxos对leader election阶段作出了如下的修改：

1.leader election的prepare步骤除去全局递增序列号p外，还包含该proposer（DPaxos称之为aspiring leader）将使用的Q2（DPaxos称其为intent），假如该proposer当选为新的leader的话。注意，prepare消息是发送给majority节点的，这是当前使用的Q1。

2. 对于promise步骤，接受者不仅按照paxos算法那样返回序号最大的接受的值及其序号，同时返回所有该节点曾经promise的那些intents。也就是说，接受者并没有投过票的那些proposer发送的intent并不包含在此间。

3. Q1必须与所有的intents相交。而在上面的两个步骤中，使用的Q1完全有可能与某个intent没有任何交集。如果这种情况出现，那么DPaxos需要首先扩展Q1得到Q1'，以使其与任意的intent相交，并重新发起额外的一轮election，以获得每个intent中至少一个节点的投票。显然，这样就达到了Q1与所有使用过的Q2（也就是intent）相交的目的。

那么如何保证，当一个proposer收到所有Q1的promise消息时，这些promise消息所包含的intents包含了所有曾经被使用的intents呢？这由所有的Q1互相相交所保证。

DPaxos的leader election算法如下

红色字体为DPaxos针对paxos的leader election phase的改变。

Expanding Quorums使得Q1与Q2不必相交，因此与FPaxos相比，|Q1|可以更小。这样提高了leader election的fault-tolerance，也降低了延迟。

类似于FPaxos，DPaxos针对Expanding Quorums亦给出了两种实现：Delegate Quorums和Leader Zone Quorums。

Delegate Quorums_将各个节点划分为zone，Q1使用majority zones，而单个zone本身的quorum是majority nodes。而Q2可以足够小，小到可以只包含一个zone。而Leader Zone Quorums则干脆指定某一个zone来做leader election，而Q1是zone内的mojority nodes。那么如果此zone内的节点因为partition等原因形成不了majority了，需要切换zone怎么办呢？DPaxos使用复杂的算法来实现这一过程，其分为3个步骤：

1.当前leader zone(zone_j)内run一次paxos instance，选出一个唯一的“下一个leader zone”。

2. 将新的leader zone(zone_i)加入到Leader Zone Quorums中，此时proposer的prepare消息需要两个majority quorums的promise确认（像不像raft的configuration change？），一个来自zone_j，一个来自zone_i。同时zone_j中的节点需要将目前已经接收到的intents发送给zone_i中的节点，并确保zone_i中的majority节点接收到了对应的intents。

3. 步骤2保证了所有的intents都由新的leader zone(zone_i)来管理。此时，就可以安全地向所有的zone广播新的leader zone为zone_i了。

这是一个复杂的算法，DPaxos并未给出其正确性的证明。感兴趣的同学可以参考DPaxos论文的4.3.2节。Expanding Quorums允许我们在减小|Q2|时，不必相应地增加|Q1|。如当设置Q2为一个zone时，不必设置Q1包含所有的zones，而只需要包含majority zones。

Leader Handoff

除了针对leader election quorum和replication quorum进行的优化外，DPaxos还针对移动应用等需要频繁变更leader location的应用提出了Leader Handoff的优化，能够不经过leader election阶段来主动切换leader。其主要思想是：paxos的leader是一个逻辑上的概念，并不一定要绑定到某个node。leader可以发送一个带有其状态的让渡消息来将leader角色转移给新的node。此让渡消息一经发送，原leader即告退位。若该消息丢失，则接收节点不会成为新的leader，此时就需要leader election步骤了。

总结

本文总结了FPaxos和DPaxos在降低paxos协议延迟时间上面的研究。FPaxos使得leader election quorums和replication quorums都不必各自相交；从而使得我们可以为执行次数多得多的replication操作选择更小quorum。 而DPaxos则更进一步，不需要leader election quorums与replication quorums相交，而只要求leader election quorums本身相互相交；这样，DPaxos进一步降低了leader election的延迟，并提高了leader election的fault tolerance。

分布式数据库系统通常通过paxos协议来保证多个数据副本之间的一致性。特别是OLTP系统，事务的延迟时间显得尤为重要。DPaxos的设计，对于需要多地、多数据中心部署的数据库系统具有更大的参考意义，因为跨城的消息延迟是巨大的，DPaxos减少了这样的消息的数目。再比如用户从zone_i搬家到了zone_j，我们可以将用户数据的写入点（leader）迁移到zone_j，以降低用户的请求时间等等。

FAQ

Q：应用FPaxos、DPaxos需要对multi-paxos做怎样的修改？

A：应用FPaxos是极其简单的，我们只需要显式地定义Q1和Q2，并在Prepare和Propose阶段独立使用Q1和Q2即可，只许确保Q1和Q2满足FPaxos提出的相交性条件。DPaxos则需要对multi-paxos协议作出较多的更改，甚至涉及到对每个参与者节点的intents的回收等等。

Q：FPaxos、DPaxos在降低延迟的同时，是否牺牲了其它的性质？

A：FPaxos的工作是弱化Paxos正确性成立的前置条件，即Q1和Q2不必均为majority quorum。这给了实现者以选择|Q1|、|Q2|大小的自由(|Q1| + |Q2| ≥ N+1)。例如对于simple quorums，系统可以选择较小的|Q2|，较大的|Q1|，降低复制延迟的同时，也降低了leader election的fault-tolerance。DPaxos在实现上则复杂地多，不过其能在减小|Q2|的同时，不必相应增大|Q1|（Q1会expand，不过选择合理的intents可以将|Q1|控制得较小）。

引用

[1]Lamport, Leslie. "The part-time parliament." ACM Transactions on Computer Systems (TOCS) 16.2 (1998): 133-169.

[2]Lamport, Leslie. "Paxos made simple." ACM Sigact News 32.4 (2001): 18-25.

[3]Howard, Heidi, Dahlia Malkhi, and Alexander Spiegelman. "Flexible paxos: Quorum intersection revisited." arXiv preprint arXiv:1608.06696 (2016).

[4]Nawab, Faisal, Divyakant Agrawal, and Amr El Abbadi. "DPaxos: Managing Data Closer to Users for Low-Latency and Mobile Applications." Proceedings of the 2018 International Conference on Management of Data. ACM, 2018.