5.6 时序与可用性

我们对于Raft的要求之一就是安全性不依赖于时序（timing）：系统不能仅仅因为一些事件发生的比预想的快一些或慢一些就产生错误。然而，可用性（系统可以及时响应客户端的特性）不可避免的要依赖时序。例如，如果消息交换在服务器崩溃时花费更多的时间，Candidate不会等待太长的时间来赢得选举；没有一个稳定的Leader，Raft将无法工作。

Leader选举是Raft中对时序要求最关键的地方。Raft会选出并保持一个稳定的Leader，只有系统满足下列时序要求（timing requirement）：

broadcastTime << electionTimeout << MTBF

在这个不等式中，broadcastTime是指，一个Server并行的向集群中的其它Server发送RPC，并收到这些Server的响应的平均时间；electionTimeout指的就是在5.2节描述的选举超时时间；MTBF指的是单个Server发生故障的间隔时间的平均数。broadcastTime应该比electionTimeout小一个数量级，为的是使Leader能够持续发送心跳信息（heartbeat）来阻止Follower开始选举；根据已经给出的随机化选举超时时间方法，这个不等式也使得瓜分选票的情况变成不可能。electionTimeout也要比MTBF小几个数量级，为的是使得系统稳定运行。当Leader崩溃时，大约会在整个electionTimeout的时间内不可用；我们希望这种情况仅占全部时间的很小一部分。

broadcastTime和MTBF是由系统决定的属性，但electionTimeout是我们必须做出选择的。Raft的RPC需要接收方将信息持久化保存到稳定的存储中，所以广播时间大约是0.5毫秒到20毫秒，这取决于存储技术。因此，electionTimeout一般在10ms到500ms之间。大多数Server的MTBF都在几个月甚至更长，很容易满足这个时序需求。