图 16：发现并替换?一个已经崩溃的领导?人的时间 。上?面的图考察了了在选举超时时间上的随机化程度，下?面的图考察了了最?小选举超时时间 。每条线代表了了 1000 次实验（除了了 150-150 毫秒只试了了 100 次），和相应的确定的选举超时时间 。例例如，150-155 毫秒意思是，选举超时时间从这个区间范围内随机选择并确定下来 。这个实验在?一个拥有 5 个节点的集群上进?行行，其?广播时延?大约是 15 毫秒 。对于 9 个节点的集群，结果也差不不多 。为了了衡量量领导?人选举，我们反复的使?一个拥有五个节点的服务器器集群的领导?人宕机，并计算需要多久才能发现领导?人已经宕机并选出?一个新的领导?人（?见图 16） 。为了了构建?一个最坏的场景，在每?一的尝试?里里，服务器器都有不不同?长度的?日志，意味着有些候选?人是没有成为领导?人的资格的 。另外，为了了促成选票持平的情况，我们的测试脚本在终?止领导?人之前同步的发送了了?一次?心跳?广播（这?大约和领导?人在崩溃前复制?一个新的?日志给其他机器器很像） 。领导?人均匀的随机的在?心跳间隔?里里宕机，也就是最?小选举超时时间的?一半 。因此，最?小宕机时间?大约就是最?小选举超时时间的?一半 。
图 16 中上?面的图表明，只需要在选举超时时间上使?用很少的随机化就可以?大?大避免选票被?瓜分的情况 。在没有随机化的情况下，在我们的测试?里里，选举过程往往都需要花费超过 10 秒钟由于太多的选票持平的情况 。仅仅增加 5 毫秒的随机化时间，就?大?大的改善了了选举过程，现在平均的宕机时间只有 287 毫秒 。增加更更多的随机化时间可以?大?大改善最坏情况：通过增加 50 毫秒的随机化时间，最坏的完成情况（1000 次尝试）只要 513 毫秒 。图 16 中下?面的图显示，通过减少选举超时时间可以减少系统的宕机时间 。在选举超时时间为 12-24 毫秒的情况下，只需要平均 35 毫秒就可以选举出新的领导?人（最?长的?一次花费了了 152 毫秒） 。然?而，进?一步降低选举超时时间的话就会违反 Raft 的时间不不等式需求：在选举新领导?人之前，领导?人就很难发送完?心跳包 。这会导致没有意义的领导?人改变并降低了了系统整体的可?用性 。我们建议使?用更更为保守的选举超时时间，?比如 150-300 毫秒；这样的时间不不?大可能导致没有意义的领导?人改变，?而且依然提供不不错的可?用性 。
10 相关?工作已经有很多关于?一致性算法的?工作被发表出来，其中很多都可以归到下?面的类别中：
? Lamport 关于 Paxos 的原始描述，和尝试描述的更更清晰 。? 关于 Paxos 的更更详尽的描述，补充遗漏漏的细节并修改算法，使得可以提供更更加容易易的实现基础 。
? 实现?一致性算法的系统，例例如 Chubby，ZooKeeper 和 Spanner 。对于 Chubby 和 Spanner 的算法并没有公开发表其技术细节，尽管他们都声称是基于 Paxos 的 。ZooKeeper 的算法细节已经发表，但是和 Paxos 着实有着很?大的差别 。
? Paxos 可以应?用的性能优化 。? Oki 和 Liskov 的 Viewstamped Replication（VR），?一种和 Paxos 差不不多的替代算法 。原始的算法描述和分布式传输协议耦合在了了?一起，但是核?心的?一致性算法在最近的更更新?里里被分离了了出来 。VR 使?用了了?一种基于领导?人的?方法，和 Raft 有很多相似之处 。
Raft 和 Paxos 最?大的不不同之处就在于 Raft 的强领导特性：Raft 使?用领导?人选举作为?一致性协议?里里必不不可少的部分，并且将尽可能多的功能集中到了了领导?人身上 。这样就可以使得算法更更加容易易理理解 。例例如，在 Paxos 中，领导?人选举和基本的?一致性协议是正交的：领导?人选举仅仅是性能优化的?手段，?而且不不是?一致性所必须要求的 。但是，这样就增加了了多余的机制：Paxos 同时包含了了针对基本?一致性要求的两阶段提交协议和针对领导?人选举的独?立的机制 。相?比较?而

• 人生低谷的时候，怎么寻找出路？
• 我的世界大全 我的世界
• 网上怎样找女朋友 网上找人上哪个网站怎么寻找亲人
• 87%以上新兵拥有大专学历，低学历当兵如何寻找出路？
• 寻找尸源女 玩尸女的看法
• 超级巨星游戏下载
• 寻找那遗失的年味
• 寻找乡村的味道
• 寻找心灵的故乡
• 创业扶持项目 如何寻找创业项目