《云计算技术系列丛书 云原生分布式存储基石： etcd深入解析》—1.4.2可用性与时序

1.4.2　可用性与时序

       在描述了Raft一致性算法之后，接下来我们再来讨论有关可用性和时序的问题。

       我们对分布式一致性算法的要求之一就是不依赖于时序（timing）—系统不能仅仅因为某些事件发生得比预想的快一些或慢一些就产生错误。然而，可用性（系统及时响应客户端的请求）不可避免地要依赖时序。从上面的描述中可以看出，没有一个稳定的领导人，Raft算法将无法工作（至少没法接受客户端的写请求）。因此，如果消息交换发生在服务器崩溃时，则需要花费更多的时间，而候选人不会等待太长的时间来赢得选举。

       领导人选取是Raft算法中对时序要求最多的地方。只有当系统环境满足以下时序要求时，Raft算法才能选举并且保持一个稳定的领导人存在：

broadcastTime << electionTimeout << MTBF

       在以上不等式中，broadcastTime指的是一个节点向集群中其他节点发送RPC，并且收到它们响应的平均时间，electionTimeout就是在上文中多次出现的选举超时时间，MTBF指的是单个节点发生故障的平均时间间隔。为了使领导人能够持续发送心跳包来阻止下面的Follower发起选举，broadcastTime应该比electionTimeout小一个数量级。根据已经给出的随机化选举超时时间方法，这个不等式也显著降低了候选人平分选票的概率。为了使得系统稳定运行，electionTimeout也应该比MTBF小几个数量级。当领导人出现故障且在新的领导人选举出来之前，系统对外将会不可用，这个时长大约为electionTimeout。

       broadcastTime和MTBF与系统环境息息相关，但是我们可以根据实际情况配置electionTimeout的值。一次Raft算法的RPC的完成需要接收方将信息持久化到本地存储中去，所以广播时间是网络传输时延与存储写入时延的总和，一般在几毫秒到几十毫秒之间。因此，通常将electionTimeout设置在10ms到500ms之间。大多数的服务器的MTBF都在几个月甚至更长的时间里，因此很容易满足这个时序需求。

       下文将会用实验数据进一步说明时延对Raft系统性能和可用性的影响。