Raft实现报告（12）
上期讲到，时间点对于Raft至关重要，广播时间应该小于选举超时时间，为了保证系统能够稳定运行，让follower尽量保持稳定而不会触发leader选举，对各种RPC的处理时间应该是小于选举时间。在一个就是MTBF（单节点平均故障间隔时间），选举超时应该小于MTBP为了系统稳定运行，能在节点宕机时快速恢复。
时间和可用性 part2
这三个时间，其中广播时间和MTBF时底层的系统属性，MTBF又取决于系统稳定性，而选举超时是我们必须选择的，或是控制的。Raft的RPC通常要就接受者将信息持久化到稳定的存储中，因此，广播时间可能在0.5ms-20ms之间，这还取决于存储技术。因此选举超时可能在10ms-500ms之间。
典型服务器的MTBFs一边是几个月或者更久，相当于几个月出现一次小故障，这就轻松满足了之前的那个不等式。
广播时间<<选举时间<<MTBF
集群中的角色转换
到目前为止，我们一直接受集群配置（参与支持共识算法的服务器集合）是固定的。在实际情况中，有时需要更改配置，例如，在服务器发生物理故障时，更换服务器服务器或者更改副本的程度。虽然可以通过使整个集群脱机，更新配置文件然后重启集群来完成，但是这会让集群在转换期间不可用。此外，如果有任何手动步骤，则会存在操作员的错误风险。为了避免这些问题，在这次实现中，会把自动化配置合并到Raft共识算法中。
