Part 13：Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》（集群成员变更-总述）

Part 13：Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》（集群成员变更-总述）

4 Cluster membership changes（集群成员变更）

到目前为止，我们已经假设集群配置（参与共识算法的服务器集群）是固定的。在实践中，偶尔也需要更改配置，例如在服务器失败时替换服务器或更改副本的数量。这可以通过以下两种手动方式完成：

• 可以通过使整个集群下线、更新配置文件，然后重新启动集群来完成配置更改。但是，这将在转换过程中使集群不可用；

• 或者，一个新的服务器可以通过使用集群中某个服务器的网络地址来替换这个集群成员。但是，管理员必须保证被替换的服务器永远不会恢复，否则系统将失去其安全属性（例如，会有一个额外的投票）。

这两种更改成员变更的方法都有显著的缺点，如果有任何手动步骤，它们就会有操作员出错的风险。

为了避免这些问题，我们决定利用自动化的配置变更并将其融合进Raft算法中。Raft容许在变更期间集群正常的运行，并且成员变更仅仅是通过在基础的Raft算法上集成一些插件既能实现。图4.1总结了集群中成员变更使用的RPC。

image.png

图4.1中的RPC。

• AddServer RPC（由admin调用以向集群配置中添加server）

  • Arguments（参数）

    • newServer，需删除的server的地址；

  • Results（返回值）

    • status，RPC调用成功则返回OK；

    • leaderHint，最近的Leader的地址，如果知道的话；

  • Receiver Implementation（RPC请求接收者的处理逻辑）

    • 返回NOT_LEADER，如果接收到RPC请求的服务器不是Leader的话；

• RemoveServer RPC（由admin调用以向集群配置中删除server）

  • Arguments（参数）

    • newServer，新加入的server的地址；

  • Results（返回值）

    • status，RPC调用成功则返回OK；

    • leaderHint，最近的Leader的地址，如果知道的话；

  • Receiver Implementation（RPC请求接收者的处理逻辑）

    • 返回NOT_LEADER，如果接收到RPC请求的服务器不是Leader的话；

<< 上一章：Raft算法-小结
下一章：集群成员变更-安全性 >>