5.5 跟随者和候选?人崩溃到?目前为?止，我们都只关注了了领导?人崩溃的情况 。跟随者和候选?人崩溃后的处理理?方式?比领导?人要简单的多，并且他们的处理理?方式是相同的 。如果跟随者或者候选?人崩溃了了，那么后续发送给他们的 RPCs 都会失败 。Raft 中处理理这种失败就是简单的通过?无限的重试；如果崩溃的机器器重启了了，那么这些 RPC 就会完整的成功 。如果?一个服务器器在完成了了?一个 RPC，但是还没有响应的时候崩溃了了，那么在他重新启动之后就会再次收到同样的请求 。Raft 的 RPCs 都是幂等的，所以这样重试不不会造成任何问题 。例例如?一个跟随者如果收到附加?日志请求但是他已经包含了了这?一?日志，那么他就会直接忽略略这个新的请求 。
5.6 时间和可?用性Raft 的要求之?一就是安全性不不能依赖时间：整个系统不不能因为某些事件运?行行的?比预期快?一点或者慢?一点就产?生了了错误的结果 。但是，可?用性（系统可以及时的响应客户端）不不可避免的要依赖于时间 。例例如，如果消息交换?比服务器器故障间隔时间?长，候选?人将没有?足够?长的时间来赢得选举；没有?一个稳定的领导?人，Raft 将?无法?工作 。
领导?人选举是 Raft 中对时间要求最为关键的?方?面 。Raft 可以选举并维持?一个稳定的领导?人,只要系统满?足下?面的时间要求：?广播时间（broadcastTime） << 选举超时时间（electionTimeout） << 平均故障间隔时间（MTBF）在这个不不等式中，?广播时间指的是从?一个服务器器并?行行的发送 RPCs 给集群中的其他服务器器并接收响应的平均时间；选举超时时间就是在 5.2 节中介绍的选举的超时时间限制；然后平均故障间隔时间就是对于?一台服务器器?而?言，两次故障之间的平均时间 。?广播时间必须?比选举超时时间?小?一个量量级，这样领导?人才能够发送稳定的?心跳消息来阻?止跟随者开始进?入选举状态；通过随机化选举超时时间的?方法，这个不不等式也使得选票持平的情况变得不不可能 。选举超时时间应该要?比平均故障间隔时间?小上?几个数量量级，这样整个系统才能稳定的运?行行 。当领导?人崩溃后，整个系统会?大约相当于选举超时的时间?里里不不可?用；我们希望这种情况在整个系统的运?行行中很少出现 。?广播时间和平均故障间隔时间是由系统决定的，但是选举超时时间是我们?自?己选择的 。Raft 的 RPCs 需要接收?方将信息持久化的保存到稳定存储中去，所以?广播时间?大约是 0.5 毫秒到 20 毫秒，取决于存储的技术 。因此，选举超时时间可能需要在 10 毫秒到 500 毫秒之间 。?大多数的服务器器的平均故障间隔时间都在?几个?月甚?至更更?长，很容易易满?足时间的需求 。
6 集群成员变化到?目前为?止，我们都假设集群的配置（加?入到?一致性算法的服务器器集合）是固定不不变的 。但是在实践中，偶尔是会改变集群的配置的，例例如替换那些宕机的机器器或者改变复制级别 。尽管可以通过暂停整个集群，更更新所有配置，然后重启整个集群的?方式来实现，但是在更更改的时候集群会不不可?用 。另外，如果存在?手?工操作步骤，那么就会有操作失误的?风险 。为了了避免这样的问题，我们决定?自动化配置改变并且将其纳?入到 Raft ?一致性算法中来 。为了了让配置修改机制能够安全，那么在转换的过程中不不能够存在任何时间点使得两个领导?人同时被选举成功在同?一个任期?里里 。不不幸的是，任何服务器器直接从旧的配置直接转换到新的配置的?方案都是不不安全的 。?一次性?自动的转换所有服务器器是不不可能的，所以在转换期间整个集群存在划分成两个独?立的?大多数群体的可能性（?见图 10） 。

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