GBase 8c Raft协议学习（二）

最新推荐文章于 2025-12-03 14:48:07 发布

转载最新推荐文章于 2025-12-03 14:48:07 发布 · 222 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://www.cnblogs.com/wind-zhou/p/12827140.html

文章标签：

#zookeeper #分布式 #java

Raft协议通过心跳触发Leader选举，当Follower在选举超时后发起竞选。竞选时，服务器将term加一并尝试获取多数选票。当选票过半则成为Leader，否则可能因收到其他Leader消息或选票分散导致选举失败。当选Leader必须包含所有已提交日志，以确保数据不丢失。

Leader选举
1、Leader选举的过程
Raft 使用心跳（heartbeat）触发Leader选举。当服务器启动时，初始化为Follower。Leader向所有Followers周期性发送heartbeat。如果Follower在选举超时时间内没有收到Leader的heartbeat，就会等待一段随机的时间后发起一次Leader选举。
每一个follower都有一个时钟，是一个随机的值，表示的是follower等待成为leader的时间，谁的时钟先跑完，则发起leader选举。
Follower将其当前term加一然后转换为Candidate。它首先给自己投票并且给集群中的其他服务器发送 RequestVote RPC。结果有以下三种情况：
" 赢得了多数的选票，成功选举为Leader；
" 收到了Leader的消息，表示有其它服务器已经抢先当选了Leader；
" 没有服务器赢得多数的选票，Leader选举失败，等待选举时间超时后发起下一次选举。

2、Leader选举的限制
在Raft协议中，所有的日志条目都只会从Leader节点往Follower节点写入，且Leader节点上的日志只会增加，绝对不会删除或者覆盖。
这意味着Leader节点必须包含所有已经提交的日志，即能被选举为Leader的节点一定需要包含所有的已经提交的日志。因为日志只会从Leader向Follower传输，所以如果被选举出的Leader缺少已经Commit的日志，那么这些已经提交的日志就会丢失，显然这是不符合要求的。
这就是Leader选举的限制：能被选举成为Leader的节点，一定包含了所有已经提交的日志条目。