Part 11：Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》（基础Raft-Leader转换）

Part 11：Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》（基础Raft-Leader转换）
3.10 Leadership Transfer Extension（Leader转换）
本节介绍了Raft的可选扩展，允许一个服务器将其Leader角色转移给另一个服务器。Leader转移在两种情况下可能很有用：

有时，Leader必须下线。例如，它可能需要重新启动以进行维护，或者它可能会从集群中删除（请参见第4章）。当Leader退出时，集群将闲置一个选举超时时间直到另一个服务器超时并赢得选举。这种短暂的不可用性可以通过让Leader在退出之前将Leader角色转移到另一个服务器来避免；
在某些情况下，一个或多个服务器可能比其他服务器更适合作为Leader。例如，具有高负载的服务器不会成为较好的Leader，或者在广域网部署中，可以首选主数据中心中的服务器作为Leader，以尽量减少客户端和Leader之间的延迟。其他的共识算法可能能够在Leader选举期间适应这些偏好，但是Raft需要新Leader具有足够的最新的log才能变成新Leader。在Raft中，Leader其实也可以定期的再集群中检查以发现最合适作为新Leader的服务器，并在需要的情况下将Leader角色转给这个服务器。
要在Raft中转移Leader角色，当前的Leader将其log entry发送到目标服务器，然后目标服务器在不等待选举超时的情况下运行选举。因此，当前的Leader确保目标服务器在其任期开始时拥有所有承诺的log entry，并且，正如在正常选举中一样，多数投票保证保持安全属性（如Leader的完整性属性）。以下步骤将更详细地描述该过程：

当前Leader停止接受新的客户端请求；
当前Leader保证下一任Leader完全复制了自己的log，可通过正常的AppenEntries RPC；
当前Leader发送一个TimeoutNow请求给下一任Leader。这个请求有和目标服务器选举超时的效果，这将引起目标Leader开始一个正常的选举请求（变成Candidate并增加当前的term）；
当目标的Leader（下一任Leader）收到来自当前Leader的TimeoutNow请求时，这个目标Leader会以很大概率来发起下一轮Leader选举。当新Leader选出来后，它会发送消息给前任Leader（携带一个新term），前任Leader就可以安全下线了，Leader角色的传递就完成了。

目标Leader也可能失效，这样的话，客户端就要重新发送请求了。如果Leader转换不能在一个选举超时时间内完成，那么当前的Leader就会终止转换，并且重新接收客户端的请求。如果当前的Leader搞错了，但是目标Leader正常的再运行，最差的情况下，Leader角色的转换会多花一个选举超时时间，然后客户端的请求就会回复。

这种方法通过在Raft集群的正常过渡范围内进行操作来保持安全性。例如，即使时钟以任意速度运行，Raft也已经保证了安全；当目标服务器收到TimeoutNow请求时，它相当于目标服务器的时钟快速跳转，这是安全的。然而，我们目前还没有实施或评估这种方法。

<< 上一章：Raft算法-时间和可用性
下一章：Raft算法-小结 >>