GBase 8c Raft协议学习（二）

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的节点，一定包含了所有已经提交的日志条目。

标签：节点,选举,8c,GBase,Follower,heartbeat,Raft,日志,Leader
来源： https://blog.csdn.net/lc17123/article/details/122139316