开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第28天，点击查看活动详情
[论文阅读]Dissecting the Performance of Strongly-Consistent Replication Protocols （三）
本章节讨论了paxi框架的设计：
paxi有一个贡献是，为了考虑如何测试在广域网上的复制协议性能，压测时需要考虑key的冲突特性： 工作负载的locality特性在广域网分布式协议测试中特别重要，因为每个区域都有一组它更可能访问的密钥。为了模拟具有可调整的跨区域locality（我称之为区域性）的访问模式的工作负载，Paxi使用正态分布来控制每个键上产生请求的概率，Paxi通过从正态分布中抽取冲突的钥匙，将locality引入到benchmark中。
对paxos的locality读写特性，密度，将会导致paxos的冲突，冲突后，将需要重复发送以期再达成一致。这在不同的paxos扩展中，有不同的处理方法，以及在不同的冲突概率密度下，各种paxos的性能，可以非常不同 论文原文见：论文地址：cse.buffalo.edu/~demirbas/p…
- 应该记住的价格结论：raft vs 常规paxos ，性能是差不多的，而且raft只是一种paxos的特例。
2.不同paxos在局域网表现
4 PAXI框架
为了在相同条件下对同一平台上的不同协议进行实证比较，我们开发了一个名为Paxi的协调/复制协议的原型框架。利用我们对强一致性复制协议共享部件的观察，Paxi为这些共享部件提供了实现方法。每个组件都驻留在它自己的松散耦合模块中，并为跨模块的交互+暴露了一个精心设计的API。只要新版本的模块符合接口要求，模块就可以很容易地被扩展或替换。我们在图5中展示了Paxi框架的架构概况。开发者可以通过填入阴影块所示的缺失组件，轻松地建立一个分布式协调/复制协议的原型。通常情况下，工程师只需要指定消息结构和编写复制代码来处理客户端请求。
4.1 组成部分
配置。 Paxi是一个高度可配置的框架，包括节点和基准。Paxi中的配置提供了关于被检查的协议及其环境的各种重要信息：peers的列表及其可达地址、法定人数配置、缓冲区大小、复制个数、消息序列化和网络参数以及其他可配置的设置。该框架允许以两种不同的方式管理配置：通过分布在每个节点上的JSON文件，或通过一个将配置参数分布到所有节点上的center master上。
法定人数系统。 法定人数系统是确保容错分布式计算的一致性的一个关键环节。各种各样的分布式协调算法都依赖于法定人数系统。典型的例子包括共识算法、原子存储、相互排斥和复制的数据库。Paxi实现并提供了多种类型的法定人数系统，如简单多数、快速法定人数、网格法定人数、灵活网格和群组法定人数。法定人数系统模块只需要两个简单的接口：ack() 和quorum satisfied() 。通过开箱即提供不同类型的法定人数系统，Paxi使用户能够在不改变代码的情况下轻松探究设计空间。
网络。 在设计Paxi框架时，我们避免了任何阻塞基元，如远程程序调用（RPC），并实现了一个简单的消息传递模型，使我们可以将任何算法逻辑表达为一组事件处理程序[36, 38]。网络模块通过一个简单的Send()、Recv()、Broadcast()和Multicast()界面来处理消息的编码、解码和传输。传输层实例化TCP、UDP或Go通道进行通信，而无需对上层的调用者进行任何修改。Paxi同时支持TCP和UDP，以消除对受益于不同传输协议的算法的任何偏见。例如，单一领导者的方法可能受益于TCP，因为消息是可靠地从领导者到追随者的顺序。而小消息中的无冲突更新没有从有序的传递中获得任何好处，并在拥堵控制中支付延迟罚款。这样的系统在UDP上可能表现得更好。Paxi还通过Go通道实现了进程内通信传输层，用于集群模拟，其中所有节点都在一个进程中并发运行。模拟模式简化了Paxi协议的调试，因为它避免了集群部署步骤。
这个点比较有意思
数据存储。 由于通用性和性能方面的原因，许多协议将协议级的output（如operation commits）从应用状态输出（如操作执行结果）分离。因此，对其中一个进行评估是不够的。Paxi可以用来衡量协议和应用状态的性能。为此，我们的框架在内存中的多版本键值数据存储，对每个节点都是私有的。数据存储被用作协调协议常用的确定性的状态机抽象。只要Paxi节点能够查询当前状态、提交状态转换操作并生成过去状态的有向无环图（DAG），任何其他数据模型都可以用于此目的。
RESTful客户端:Paxi客户端库使用一个RESTful API与任何系统节点的读写请求进行交互。这使得用户可以针对他们在Paxi中的实现运行任何基准测试（如YCSB[11]）或测试工具（如Jepsen[22]），而无需将客户端库移植到其他编程语言。
4.2 Paxi基准测试组件 基准测试。
Paxi的基准测试组件是我们基准测试能力的核心。基准器产生具有丰富功能的可调整工作负载，包括访问定位和动态性，并收集这些工作负载的性能数据。与YCSB[11]类似，Paxi提供了一个简单的读/写接口来与客户端库进行交互。工作负载生成器读取Configuration以加载工作负载定义参数，如表3所总结的。
基准组件可以通过调整读写比例、创建热目标、冲突对象和访问的位置性来产生各种工作负载。工作负载的定位特性在广域网分布式协议中特别重要，因为每个区域都有一组它更可能访问的密钥。为了模拟具有可调整的跨区域访问定位模式的工作负载，Paxi使用正态分布来控制每个键上产生请求的概率，并用每个区域的概率函数来表示K个公共键池，如图6所示。换句话说，Paxi通过从正态分布中抽取冲突的钥匙，将位置性引入到评估中。
图6：数据记录总数等于K时的概率分布
分布N(μ, σ2 )，其中μ可以针对不同的区域而变化，以控制区域性，而σ则在区域之间共享。区域性可以被看作是不重叠的区域
在图6的概率密度函数下。
Paxi基准测试器能够测试和评估协调/复制协议行为的四个不同方面：性能、可扩展性、可用性和一致性。
性能。 Paxi通过延迟和吞吐量指标来衡量性能。每个人的延时
请求被存储并输出到一个文件中供将来分析。由于展示一个协议在压力下的尾部延迟表现非常重要，Paxi支持通过增加基准吞吐量（通过增加工作负载生成器的并发水平），直到系统饱和，吞吐量停止增加或延迟开始攀升。用户可以用不同的工作负载进行这个基准层，以了解协议的性能，或者用相同的工作负载增加吞吐量，以找到协议的瓶颈。
可扩展性。 云原生协议最理想的特性之一是弹性可扩展性：当应用
在Paxi中，我们支持通过在系统配置中添加更多的节点和增加数据集（K）的大小来实现基准的可扩展性。在Paxi中，我们通过在系统配置中增加节点和增加数据集（K）的大小来支持基准的可扩展性。
可用性。 高可用性是分布式协议不可或缺的要求，因为它们被期望在合理数量的故障情况下保持进展。虽然可用性测试看起来很简单，但它需要大量的手工工作来模拟所有的故障组合。许多故障类型很难在一个不受控制的运行环境中产生，而不利用第三方的操作系统专用工具。典型的例子包括非对称网络分区、失序信息和随机信息丢失/延迟，这只是其中的几个例子。有几个项目有自动化的故障注入程序，但有局限性。例如，Jepsen[22]发出 "tc"（traffic con- trol）命令，在每个节点上操纵网络数据包，但只能在Linux系统上运行。ChaosMonkey[32]是一个弹性工具，只能随机终止虚拟机实例和容器。Paxi作为一个原型框架，可以轻松模拟任何节点或网络故障。我们在Paxi客户端库中提供了四个特殊的命令，并在网络模块中实现这些命令。
• Crash(t )将 "冻结 "节点t秒。
• Drop(i, j, t )函数丢弃从节点i发送到节点j的每条消息。
• Slow(i, j, t )函数将信息延迟到一个随机的时间。
• Flaky(i, j, t )函数会偶然丢弃信息。
在jepsen上，他们使用网络hook来模拟这些状态。以模拟不同网络分区下的拓扑结构，达成脑裂情况。
一致性。 对于Paxi的一致性检查组件，我们实现了Facebook TAO系统[28]中简单的离线读/写线性化检查器。我们的线性化检查器将每条记录的所有操作按调用时间排序的列表作为一个输入。检查器的输出是一个所有异常读取的列表，也就是那些在可线性化系统中无法返回结果的读取操作。我们的检查器维护一个图，其顶点是读或写操作，边是约束。它在向图中添加操作时检查是否有循环。如果该图是无周期的，那么至少存在一个满足所有约束条件的操作的总顺序。否则将报告违反线性化的情况。
与线性化检查器不同，我们的共识检查器验证每个状态转换的共识是否已经在复制的状态机中的节点之间达成。外部的、客户观察到的线性化可以在没有状态机之间达成共识的情况下达到，然而，满足共识对于共识算法，如Paxos，是至关重要的。为了测试共识，Paxi包括一个多版本数据存储作为状态机。我们在客户端库中实现了一个特殊的command，从每个系统节点收集一些数据记录的整个历史Hr ，然后验证所有来自节点i的历史Hr 是否共享一个共同的前缀。
图7：在Paxi与etcd中实施的单领导人共识协议
5 对协议的评价
我们使用我们的模型进行模拟实验，并使用Paxi框架在局域网和广域网进行部署实验，进行协议评估。在Paxi中，我们在AWS EC2 [5] m5.large实例上进行了所有的实验，这些实例有2个vCPUs和8GB的内存。对于广域网的评估，我们使用AWS的数据中心拓扑结构，包括北弗吉尼亚（VA）、俄亥俄（OH）、加利福尼亚（CA）、爱尔兰（IR）和日本（JP）地区。我们的建模工作是根据m5.large实例的CPU速度进行校准的，并使用与AWS区域内和跨区域的延迟相对应的通信延迟。
在WPaxos中，我们限制了可以作为领导者的节点数量，每个区域只有一个；在一个9个节点的3区域集群中，WPaxos只有3个领导者。这使得WPaxos的部署与WanKeeper相似，并具有可比性，因为WanKeeper的设计限制其在每个区域只有一个领导者。在EPaxos中，每个节点都可以成为一个机会主义领导者。通常，EPaxos模型对消息处理进行惩罚，以考虑到计算依赖性和解决冲突所需的额外资源。对于所有的协议，我们假设完全复制方案，其中一个领导者节点将命令复制给所有其他节点。
5.1 Paxi性能
Paxi框架的主要目的是在同一框架下，在相同的实现condition下，对许多不同的共识和复制协议进行比较。然而，为了表明我们的Paxi协议的实施是代表其他现实世界生产级系统中使用的Paxos变体的实现，我们比较了Paxos协议的实现是在Paxi针对Raft在etcd中实现。
因为paxos和raft应该是具有差不多的性能，所以如果我们用real-world的代码，etcd的raft来benchmark vs paxos，性能差不多，说明paxi的paxos没问题，代码表了现实中的paxos实现。
etcd 项目提供了一个独立的Go1示例代码，它使用Raft并为键值存储暴露了一个简单的REST API允许我们直接针对etcd运行Paxi基准测试，而不需要做任何改动。 如果不考虑重新配置和恢复的差异，Paxos和Raft基本上是相同的协议，由一个稳定的领导者驱动命令复制。因此，它们在正常情况下应该表现出类似的性能。我们在同一个可用性区域内用9个副本运行每个系统。为了与Paxi进行公平的比较，我们取消了持久性日志和快照，并将etcd中的最大在途信息(in flies)数量增加到10,000条。客户端请求只有在Raft中提交请求后才会被回复。在图7中，我们显示两个系统都收敛到了由于单一领导者的瓶颈，Paxi的最大吞吐量在每秒8000次左右，但在系统不饱和的情况下，Paxi表现出更低的延迟。延迟差异可能是由于etcd使用http而不是TCP套接字进行节点间通信，以及消息序列化的不同。
5.2 局域网中的协议比较
我们进行了一组实验，研究局域网中共识协议的性能。图8显示了从我们的局域网模型中得到的再结果。我们在图9中展示了Paxi的评估，使用均匀的随机工作负载，针对Paxi的内部键值存储的1000个对象进行50%的读取操作。两幅图都显示了协议的延迟如何随着吞吐量的增加而变化。
单一领导的瓶颈。 模型和Paxi的评估都指出了单一领导的可扩展性限制。
解决办法。有几篇论文[20, 27, 29, 39]观察到--但没有进一步分析--单一领导者成为Paxos协议的一个瓶颈，与发送/接收N**个消息和领导者的CPU利用率有关。瓶颈是由于领导者被每轮需要处理的消息所淹没。例如，从我们的建模工作来看，我们估计一个Paxos领导者需要处理N**个传入信息、一个传出信息和一个传出广播2，每轮总共有N+2个信息。同时，追随者节点每轮只处理2条消息，假设第3阶段被捎带到下一个第2阶段的消息。对于一个由9个节点组成的集群来说，这意味着每轮在领导者那里有11条消息，而在复制者那里只有2条消息，使领导者成为瓶颈。
多领导协议，如WPaxos和WanKeeper，比单领导协议表现更好。它们的优势来自于在不同节点上并行处理独立对象的命令的能力。虽然多领导者解决方案可以利用单领导协议副本未使用的容量，它们仍然受到要处理的消息数量相对较多的影响，所以它们不能线性扩展：3领导的WPaxos的性能不比Paxos好3倍。我们的模型显示，WPaxos的最大吞吐量大约提高了55%，这与我们在Paxi的实验观察结果一致。
2 对于广播，CPU只参与一次序列化，然后消息由网卡单独发送给其他节点（相当于N-1次传输）。由于网卡比CPU的处理速度快得多，对于小的消息，网卡的成本可以忽略不计。
图8：局域网中的模拟性能
图9：局域网中的实验性能
这些数字还表明，3个领导的WanKeeper比3个领导的WPaxos的表现更好。通过采取分层的方法，WanKeeper减少了每个领导者处理的信息数量，进一步缓解了领导者的瓶颈问题。
无领导的解决方案受到冲突的影响。 EPaxos是一个无领导共识的例子，其中每个节点可以只要来自不同节点的命令之间不发生冲突，就可以作为命令的机会主义领导者。命令冲突对这样的网络来说是个大问题。
机会主义方法。识别和解决冲突的能力增加了消息的大小和消息所需的处理能力。冲突解决机制还需要一个额外的阶段，使冲突轮回默认为两阶段的Paxos实现。这些导致EPaxos在Paxi LAN实验中表现最差。值得一提的是，在我们的模型中，即使有100%的冲突，EPaxos也显示出比Paxos更好的吞吐量（但不是延迟），因为它不存在单领导瓶颈问题。然而，当我们添加消息处理惩罚以考虑寻找和解决冲突的额外重量时，EPaxos的性能大大降低。
小规模灵活quorms的好处 我们的模型结果显示，平均延迟改进幅度不大，只有0.03毫秒，这是由于使用单领导灵活quorms的解决方案（FPaxos）。我们的Paxi评估显示，从Paxos到FPaxos的改善幅度略大。
5.3 广域网中的协议比较
在这组实验中，我们比较了在广域网上部署的协议。广域网的部署给共识和复制协议带来了许多新的挑战，这些挑战来自于数据中心和节点之间巨大而不均匀的延迟：数据中心之间的延迟可以从几毫秒到几百毫秒不等。
在图10中，我们展示了不同共识算法的建模吞吐量和延迟结果。
与局域网模型不同，广域网模型的平均延迟差别很大，最慢的（Paxos）和最快的（WPaxos）协议之间的延迟差别超过100ms。在这种环境下，灵活的quorums在延迟方面有很大的不同--它们允许WPaxos以接近本地的延迟提交许多命令，并减少FPaxos的整体quorum等待时间。
为了对抗广域网的对抗性影响，许多协议试图对这种环境下的各种常见操作进行优化：一些协议假设需要达成共识的对象很少从许多地方被访问到。
而其他的则可能走得更远，假设对象被严格放置在某些区域，以获得更好的访问位置。当这些假设被打破时，算法的性能往往会下降。我们设计了我们的实验来测试这些冲突和位置的假设。
冲突实验。 我们将冲突定义为从不同区域访问同一对象的命令。为了研究
在冲突工作负荷下的协议性能，我们创建了一个 "热 "冲突键，它将被所有客户访问。我们控制冲突请求的比例，让每个冲突请求对指定的冲突对象进行操作。例如，20%的冲突意味着基准客户机发出的20%的请求都是针对同一个对象的。
(1) 不容忍整个区域故障的协议（WPaxos fz = 0, WanKeeper, VPaxos）在每个位置都表现出相同的性能。这是因为当f**z = 0时，非干扰性的命令能够通过quoure提交。在同一区域的朗姆酒。干扰的命令被屏蔽到对象的当前领导区域。
(2) 当协议采用领导者/所有者概念时，冲突对象的领导者区域处于优势地位，并为其本地法定人数体验到最佳延迟。在这种情况下，俄亥俄州地区是冲突对象的领导者，因此有一个低的稳定延迟。相反，EPaxos，一个无领导的方法，甚至在俄亥俄州地区也经历了由于干扰命令造成的延迟。
(3) 在可以容忍整个区域故障的协议中，包括Paxos、EPaxos和WPaxos fz = 1，WPaxos的表现最好，直到100%的干扰命令，它开始提供与Paxos相同的延迟。
(4) 与其他协议不同，EPaxos的平均延迟是冲突率的一个非线性函数。这是因为即使冲突率很低，如20%，当新的请求到达时，前一个冲突的命令可能还没有被承诺，导致更多轮的RTT延迟来解决冲突。当该地区远离其他地区时，情况会变得更糟，例如我们实验中的加利福尼亚地区。
图11：冲突工作负载下的协议比较
图12：5个节点/区域部署中的EPaxos最大吞吐量模型
我们的模型还表明，EPaxos的最大吞吐量受到冲突率的严重影响 如图12所示，在没有冲突和完全冲突的情况下，能力下降了40%。
图13：WPaxos、WanKeeper和垂直Paxos在广域网中的定位工作负荷
locality实验。 在这些实验中，我们研究了利用locality的协议的性能(WPaxos, WanKeeper, 和我们的Vertical Paxos增强版)在广域网上的locality的工作负载。如前所述，我们使用的locality工作负载是由正态分布控制的对象访问locality率。我们在实验开始时，将所有对象放在俄亥俄州区域，然后运行locality工作负载60秒。所有三个协议都是以容错级别fz = 0和简单的三连续访问策略部署的，以适应最优的性能。图13a比较了每个区域的延迟，而图13b显示了操作延迟的CDF。
在WanKeeper中，俄亥俄州区域是更高层次的区域,这将为任何从另一地区访问的对象股份保留令牌。因此，俄亥俄州显示出最佳的平均延迟接近当地的RTT，但代价是在另一个地区遭受痛苦。
两个区域。WPaxos和VPaxos更加平衡，在这个部署中有着非常相似的性能。这是因为当稳定后，两个协议都以同样的方式平衡每个区域的对象数量，这一点被以下数据所证实图6.4中几乎相同的CDF。当我们在全球范围内看所有的再任务时，WanKeeper比WPaxos和VPaxos经历更多的广域网延迟。
