开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第26天，点击查看活动详情
[论文阅读]Dissecting the Performance of Strongly-Consistent Replication Protocols （一）
剖析强一致性复制协议的性能
令人惊讶的是，作者抽象出了一个一致性框架，实现了相当多的paxos协议：
值得关注和学习。我非常想知道raft vs paxos，性能上是怎样的表现呢？遗憾的是，这篇论文没有告诉答案，因为这里说的一致性协议的性能，是指复制性能，而paxos vs raft ，在天花板上，前者更强，也就是说，可以针对业务逻辑做更多的扩展和优化，raft非常明显，比较难做扩展了。 本文综合讨论和比较了在一致性协议层，不同paxos的性能表现：请注意，Basic-Paxos一次日志确认，需要至少2次磁盘写操作(prepare,promise)和2次网络RTT(prepare,promise)。Multi-Paxos利用一阶段提交(省去Prepare阶段)，将一次日志确认缩短为一个RTT和一次磁盘写。 论文地址：cse.buffalo.edu/~demirbas/p…
ABSTRACT
许多分布式数据库采用共识协议，以确保数据以强一致性的方式在多台机器上进行复制，尽管存在故障和并发。不幸的是，这些协议在不同的网络、工作负载和部署条件下表现出广泛不同的性能，而且以前的研究没有对其性能进行全面的剖析和比较。为了填补这一空白，我们研究了单领导、多领导、分层多领导和无领导（机会主义领导）共识协议，并对它们在局域网（LANs）和广域网（WANs）中的性能进行了全面评估。我们采取了一种双管齐下的系统方法。我们利用排队理论对协议进行了分析建模，并展示了不同控制参数下的模拟结果。为了交叉验证分析模型，我们还展示了我们的原型设计和评估框架Paxi的经验结果。我们把我们的发现提炼成最重要的参数的简单吞吐量和延迟公式。这些公式使开发者能够决定哪一类协议在给定的部署条件下是最合适的。
1 简介
协调服务和协议在现代分布式系统和数据库中起着关键作用。许多分布式数据库和数据存储[4, 7-10, 12, 13, 16, 18, 23, 24, 31, 40]使用共识来确保数据以强一致性的方式在多台机器上复制，尽管有故障和并发。
容错的分布式共识问题由Paxos[25]协议及其众多变化和扩展[1, 19-21, 26, 30, 33-35]解决。这些协议的性能对于分布式数据库的整体性能变得非常重要。这些协议在不同的条件下表现出广泛不同的性能：网络工作（延迟和带宽），工作负载（命令干扰和定位），部署规模和拓扑结构（LAN/WAN，法定人数大小），以及故障（领导者和副本崩溃和重新覆盖）。遗憾的是，还没有一项研究对各种共识协议进行全面比较，并对其性能进行剖析和解释。
1.1 贡献
我们对局域网（LANs）和广域网（WANs）中的共识协议进行了全面评估，并研究了许多单领导、多领导、高层次多领导和无领导（机会主义领导）的共识协议。我们采取双管齐下的系统化方法，从分析和经验上研究这些协议的性能。
对于分析部分，我们设计了一个基于排队理论的模型来研究控制工作负载和部署特性的协议，并提出了协议的高保真模拟。我们的模型捕获了影响吞吐量的参数，如节点间延迟、节点处理速度、网络带宽和工作负载特性。我们将我们的分析模型的Python实现作为开放源码提供。
对于我们的实证研究，我们开发了Paxi，一个用于共识和复制协议的原型和评估框架。Paxi为协议的评估和比较提供了一个leveled proground。这些协议
图1：两阶段协调的状态转换
使用通用的网络、信息处理、四元组等构建模块，开发者只需要填写两个模块来描述分布式协调协议。Paxi包括支持基准测试，以评估协议的性能、可用性、扩展能力和一致性。我们用Go[17]编程语言实现了Paxi，并在github.com/ailidani/pa…，将其作为开放源代码提供。
分析模型和Paxi实验框架是互补的。Paxi的实验交叉验证了分析模型。而且，分析模型允许对使用实验框架难以安排和控制的不同的部署条件进行试验。
1.2 结果
有了分析模型的模拟结果和Paxi平台实现的实验结果，我们将性能结果提炼成简单的吞吐量和延迟公式，并在第6节中介绍。这些公式提供了一个简单的强一致性复制的统一理论
因此，这些公式使开发人员能够进行事后分析。
性能预测。在第6节中，我们详细讨论了这些结果，并提供了一个流程图，作为确定哪些共识协议适合给定部署环境的指南。这里我们强调了这些公式的一些重要推论。
考虑到Protocol parameters，为提高吞吐量和延迟，一个有效的协议级修改是增加协议中的领导者数量，同时尽量避免增加冲突数量。增加领导者的数量对可用性也有好处。在Paxos中，单个领导者的失败会导致不可用，直到选出一个新的领导者，但在多领导者协议中，大多数请求不会经历任何可用性的中断，因为失败的领导者不在他们的关键路径上。另一个有助于提高吞吐量和延迟的协议修订是减少Q，即法定人数的大小，但仍需满足容错要求。
就工作量参数而言，减少冲突概率和增加地方性（在有多个领导人的情况下）是有益的。然而，领导者的数量和冲突概率之间存在着相互影响。
增加领导者的数量（这有助于提高吞吐量和延迟）可能会导致冲突的增加（这损害了吞吐量和延迟）。EPaxos[30]协议就存在这个问题。学习和适应地方性的多领导协议，如WPaxos[1]和WanKeeper[2]，不太容易受到这个问题的影响。
最后，部署参数，到领导者的距离和从领导者到法定人数节点的距离，对广域网部署中的延迟也有很大影响。请注意，这些部署参数对协议参数、领导者的数量和法定人数的大小有影响。在广域网中，其他因素也会影响延时。数据中心之间的不对称距离、访问模式的地域性和不平衡的法定人数距离使预测广域网部署的性能变得复杂。
1.3 paper其余部分的大纲
在第2节中，我们简要介绍了我们研究的协议。我们在第3节讨论了我们的分析模型，在第4节讨论了我们的原生类型/评估框架。我们在第5节中介绍了评估，在第6节中讨论了研究结果，并在第7节中总结了本文。
2 方案
许多协调和复制协议具有类似的状态转换模式，如图1所示。这些协议通常分两个阶段运行。在第1阶段，一些节点通过向其他节点宣布自己的情况并获得共同的同意，将自己确立为一个领导者。在这个阶段，在位的领导者也会获取与任何先前未完成的命令有关的信息，以便在下一阶段恢复这些命令。第二阶段负责将状态/命令从领导者复制到各节点。
利用这种两个阶段的模式，我们在下面的研究中对协议进行了简要的描述。这些协议为分布式数据库的数据复制提供了强大的一致性保证。
Paxos* 。**Paxos共识协议[25]通常被用来实现容错的复制状态机。(RSM)，其中每个节点执行相同的命令，在相同的顺序，以达到相同的状态。Paxos通过3个不同的阶段实现这一目标：提议（阶段1）、接受（阶段2）和提交，如图2所示。在第1阶段，一个节点通过提出一个投票号码*，试图成为一个命令的领导者。其他节点只有在之前没有看到更高的选票时，才会承认这个节点领导这个提议。在提议阶段达到多数票数后，"领导者 "进入第二阶段，告诉跟随者接受该命令。该命令要么是领导者提出的新命令，要么是在第一阶段学到的旧命令。（如果领导者在第一阶段学到了一些旧的未决/未提交的命令，它必须指示追随者接受票数最高的未决命令。）一旦大多数追随者承认接受了一个命令，这个命令就会被固定下来，不会丢失。在收到确认后，领导者会发送一个提交消息，允许追随者在其尊重的状态机中提交并执行该命令。
在这个基本方案的基础上，采用了一些优化措施。提交阶段通常是捎带着从领导节点广播的下一个消息，减轻了对额外消息的需求。另一个流行的优化，被称为多Paxos或multi-decree Paxos[37]，通过允许同一个领导节点指示在不同的槽中接受多个命令而不重新运行提议阶段，进一步减少了对额外消息的需求，只要其投票数仍然是跟随者看到的最高的。在本文的其余部分，我们用Paxos来指代多Paxos的实现。
作为使用Paxos的数据库的例子，FaunaDB[16]使用Raft[33]（一种Paxos实现）来实现共识，Gaios[7]使用Paxos来实现存储服务，WAN-Disco[8]使用Paxos进行active-active复制。Bizur[19]键值存储使用Paxos在独立键上达成共识，pg_paxos[13]采用Paxos在PostgreSQL中进行容错、一致的表复制，Clustrix[10]分布式SQL数据库使用Paxos进行分布式事务解决。
图2：Paxos算法的概述
Flexible Paxos :灵活的quorums Paxos，或称FPaxos[20]，观察到在阶段1和阶段2中不需要多数法定人数。相反，FPaxos表明，只要第1阶段的所有quorums与第2阶段的所有quorums相交，Paxos的特性就成立。这一结果使得多协议的Paxos协议在第2阶段的法定人数较少，以减少容错为代价提供更好的性能。
Vertical Paxos. （VPaxos）[26]分离了控制面与数据面的关系。VPaxos将一个主Paxos集群置于一些Paxos组之上，以控制任何配置的变化，并实现配置之间的快速和安全的过渡，而不会产生任何停止时间：一个Paxos组完成以前配置中提出的命令，而另一个Paxos组开始执行新配置的命令。安全切换配置的能力在地理复制的数据存储中很有用，因为它允许将数据/目标重新定位/分配到不同的领导节点，以适应访问位置的变化。Spanner[12]和CockroachDB[24]是数据库的例子，它们使用Paxos组在分区/分片上工作，上面有另一个解决方案，用于重新定位/分配数据到另一个Paxos组。
WanKeeper: WanKeeper[2]是一个由两个共识/Paxos层组成的分层协议。它采用了一个to-
ken代理架构来控制广域网部署中的命令发生地。主控层位于第2层，控制所有令牌的移动，而位于全球不同数据中心的第1层Paxos组，只有在拥有相应对象的令牌时才执行命令。当多个一级Paxos组需要访问同一个对象时，二级的主控层会从下级收回令牌，自己执行命令。一旦访问位置稳定在一个单一的re-gion，主控层就可以把令牌传回给那个一级Paxos组，以提高延迟。
WPaxos: WPaxos[1]是一个为广域网设计的多领导Paxos变体。它利用了灵活的quorums理念
以提高广域网的性能，特别是在存在访问定位的情况下。在WPaxos中，每个节点都可以拥有一些对象，并对这些对象进行独立操作。与垂直Paxos不同，WPaxos不认为改变对象的所有权是一种重构操作，也不需要一个外部的共识小组。相反，WPaxos通过在广域网上执行阶段1，在领导者之间进行对象迁移，命令通过阶段2在区域或邻近区域内提交。由于在领导者之间移动所有权的过程是使用核心的Paxos协议进行的，所以WPaxos的运行是安全的，不需要像垂直Paxos或WanKeeper那样需要一个外部主控。FleetDB[9]采用WPaxos来实现广域网中多个数据中心部署的分布式事务。
Egalitarian Paxos。Egalitarian Paxos[30]，或称EPaxos，是一种无领导的解决方案，每个节点都可以机会性地成为某个命令的领导并提交。当一个命令不干扰其他并发的命令时，它在收到快速法定人数（约为所有节点的3/4）的acks后，在一个回合内提交。从某种意义上说，在没有冲突的情况下，EPaxos将第二阶段压缩为第一阶段的一部分。然而，如果快速法定人数检测到命令之间的冲突，EPaxos默认回到传统的Paxos模式，继续进行第二阶段，以建立冲突命令的秩序。EPaxos的主要优点是能够在单个往返时间内提交无干扰的命令。这当集群对许多对象进行操作，并且任何两个节点对相同对象进行操作的概率较小时，该方法效果良好。作为像EPaxos这样的无领导方法的一个例子，MDCC[23]已经使用Fast Paxos和General-ized Paxos（在EPaxos之前）来实现多数据中心强一致复制。
