Raft实现报告（15）

重制配置的三个问题

问题一

第一个问题是新的服务器可能不会存储任何的日志条目。如果他们以这种状态添加到集群中，他们可能需要很长的时间才能赶上，在此期间可能无法提交新的条目日志。为了避免可用性的差距。Raft在配置更改钱引入了一个额外的阶段，在该阶段中，新服务器作为非投票成员加入集群（leader将日志条目复制给他们，但他们不被纳入范围）。一旦新服务器赶上了集群的其余部分，那么动态更换配置就可继续执行。

第二个问题

leader可能不在新配置中的一部分，在这种情况下，leader在提交新集群日之后下台（返回follower状态）。这意味着有一段时间（当它提交新集群日志时）leader正在管理一个不包括自己的集群；leader转换发生在提交新集群的日志时，因为这是新配置可以独立运行的第一个点（总是可以从新集群中选举leader），在此之前，可能只有来自旧集群配置的服务器可以被选为leader。

第三个问题

第三个问题是删除的服务器（不在新集群配置中的服务器）可能会破坏集群。这些服务器收不到心跳后，因此他们会超时并开始新的选举。然后后他们将发送带有新期号的RequestVoteRPC，这将导致当前领导者恢复为follower的状态，这破坏了系统的稳定性。最终会选出一个新的leader，但是被移除的服务器会再次超时，这个过程就会重复，导致可用性很差。

为了防止这个问题发生，当服务器当前存在leader的时候，他们会忽略RequestVoteRPC。具体来说如果服务器在听取当前leader的最小选举超时时间内收到了RequestVoteRPC，他不会更新其任期的索引，或者是去头片。当然这个行为也不会影响正常的选举流程，每个服务器在开始选举之前至少会等待一个最小选举超时。它有助于变面被移除的服务器造成的中断：如果一个leader能够维持心跳，那么他将不会被代替。也就维持了系统的可用性。