Part 10：Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》（基础Raft-时间和可用性）

Part 10：Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》（基础Raft-时间和可用性）
3.9 Timing and Availability（时间和可用性）
我们对Raft的要求之一是安全不能取决于时间：系统不能仅仅因为某些事件发生得比预期的更早或更晚而产生不正确的结果。然而，可用性（系统及时响应客户端的能力）必须不可避免地取决于时间。例如，如果消息交换花费的时间比两次服务器崩溃之间的常规时间要长，Candidate将不会保持这个状态足够长的时间以赢得选举（Candidate的超时机制导致它不能等很久来确定是否胜选/败选）；没有一个稳定的Leader，Raft就无法取得进展。

Leader选举是Raft选举的关键模块之一，这个模块严重依赖于时间。Raft能够选出Leader并保持这个Leader稳定，如果系统中的时间满足下面的要求：

broadcastTime << electionTimeout << MTBF (“<<”是远小于的意思)
上述的不等式中，broadcastTime是某个服务器向系统中其它服务器并行发送RPC请求并收到回复所需的平均时间；electionTimeout是选举超时时间；MTBF是单个服务器两次故障之间的平均时间。broadcastTime应该比electionTimeout小一个数量级以保证Leader有足够的的时间来收集Follower的心跳信息；在所描述的随机选举超时机制中，随机的超时时间也能保证分裂的选举以小概率的机会出现。electionTimeout应该比MTBF时间小数个数量级以保证系统能正常运行。当Leader宕机/失效时，系统中难免会通过随机超时来进行新一轮的选举，我们希望这个选举过程尽可能短。

broadcastTime和MTBF底层系统来提供的系统性保障，但是electionTimeout是我们可以控制的。Raft的RPC要保证接收者有足够的的时间来存储相关信息，这个时间大约是0.5-20ms，也取决于具体的持久化设备的性能。所以，Raft将选举超时时间设定在了10-500ms之间进行取值。典型的MTBF是几个月或者更久，这很好的满足了Raft对系统时间的要求。第9章说明了详细如何设置选举超时时间和这个时间对可用性、选举性能的影响。

<< 上一章：Raft算法-持久化的状态和服务器重启
下一章：Raft算法-Leader转换 >>