我如何实际使用Raft算法

时间:2016-12-27 05:20:05

标签: cluster-computing distributed raft

在Raft论文中,他们提到所有客户端交互都发生在领导者节点上。我不明白的是领导者在不断变化。所以,让我们说我的集群是负载均衡器的背后。如何通知负载均衡器领导者已更改?或者,如果我是正确的,负载均衡器是否可以向任何节点(跟随者或领导者)发送客户端请求,并且跟随者节点有责任将请求发送给领导者?

2 个答案:

答案 0 :(得分:3)

投票结束后,您将拥有一位领导者(新人或旧人)。领导者有责任通知网络中的所有节点,以定期间隔(小于网络的保持活动时间但大于最大往返时间)向所有节点发送心跳。

每次获得心跳时,您的负载均衡器都应该更新负责人。负载均衡器将根据筏算法仅向领导者发送数据,所有客户端请求仅直接发送给领导者,其他节点不能发送数据,只能对投票和附加命令进行确认。

这里有一个非常好的演示文稿: - Raft: Log-Replication

答案 1 :(得分:2)

有两种方法可以做到这一点:负载均衡器需要了解领导者的位置,或者关注者可以向领导者代理请求。

通过关注者向领导者代理客户请求没有任何问题,事实上,它可以带来很大的好处。许多Raft实现允许客户从追随者读取,同时保持顺序一致性。如果客户端跟踪它已经看到的最后一个索引并将其发送到每个请求以确保它看不到状态回溯,那么负载均衡器可以安全地将请求发送到任意节点。我不会在这里编写完整的算法,但是在Raft论文中对此进行了描述,您应该参考。

但在某些情况下,以这种方式使用负载均衡器可能会变得不安全。如果允许客户端发送多个并发请求,则负载均衡器可以将这些请求路由到不同的节点,并且它们可能无序地到达组长。这可以通过将序列号附加到客户端请求并对领导者重新排序请求来解决。但要做到这一点,实施必须包括允许领导者跟踪每个客户端状态的会话。

但是,通常,Raft客户端会连接到特定节点并尽可能长时间地与它们保持连接,以减少切换服务器时保持一致性的开销。如果一个实现支持从关注者那里阅读,那么切换服务器的成本仍然很高,因为服务器必须等待状态赶上来维持顺序一致性。

相关问题