leader选举过程详解

最新推荐文章于 2024-07-18 09:08:14 发布

caifengguo

最新推荐文章于 2024-07-18 09:08:14 发布

阅读量1k

点赞数

分类专栏： SeaWeedFS 文章标签： Raft 协议

本文链接：https://blog.csdn.net/caifengguo/article/details/75341584

版权

当网络分区发生时，Follower因收不到Leader的心跳而启动选举，可能导致双Leader局面。旧Leader无法提交数据，而新Leader可以。当网络恢复，旧Leader发现新任期的Leader后自动降级为Follower，从而保持数据一致。然而，平票情况可能导致长时间无法选出Leader，目前解决方案尚不明朗。

摘要由CSDN通过智能技术生成

leader选举过程详解
一、只有一个master节点
在这种情况下，只有一个master节点，则不存在选举，且该节点为leader

二、针对两个master节点，在启master动服务时，如何选举leader节点？
由于master服务在启动时存在时间的先后顺序，先启动的那个会先发起投票，向还没有启动正常的一方请求投票，此时对方只能把票投给自己，则自己成为leader

三、针对三个master节点(A/B/C)
1、三者都分别给自己投票，则存在平票，此时三者都随机休息一下然后重新发起投票，最先从休息中恢复起来发起投票的一方向另外两方请求投票，此时他们只能投给自己，则自己成为leader
2、三者中A两票，B一票、C没有票，则此时A为leader
3、三者中B两票，A一票、C没有票，则此时B为leader
4、三者中C两票，A一票、B没有票，则此时C为leader

四、针对多节点数据一致性问题
1、Raft 协议强依赖 Leader 节点的可用性来确保集群数据的一致性
2、如果client向leader发送数据后没有收到leader的回应，则client会重发
3、如果client向leader发送数据后，leader同步到部分子节点，leader挂掉，Raft 协议要求投票只能投给拥有最新数据的节点，所以拥有最新数据的节点会被选为Leader，再强制同步数据到 Follower，然后client会重发