由于集群中不存在Leader,A、B、C三个成员都不会收到来自Leader的心跳信息。其中,成员A的超时最短,最先进入选举状态,修改自己的状态为Candidate,并增加自己的任期编号为1,发起请求投票消息,如图2所示。■图2请求投票成员A通过RequestVote广播自己的选票给成员B、
由于集群中不存在Leader,A、B、C三个成员都不会收到来自Leader的心跳信息。其中,成员A的超时最短,最先进入选举状态,修改自己的状态为Candidate,并增加自己的任期编号为1,发起请求投票消息,如图2所示。
■ 图2 请求投票
成员A通过RequestVote广播自己的选票给成员B、C,选票描述了成员A所拥有的数据,其包含成员A所处的term及最新的日志索引。成员B、C根据投票规则处理RequestVote消息。
term大的成员拒绝投票给term小的成员。
日志索引大的成员拒绝投票给日志索引小的成员。
一个term内只投出一张选票,采用先来先获得投票的原则。
很明显,成员B、C的term小于成员A的term,也不存在比成员A日志索引更大的日志索引,并且term为1的选票还没有投给其他成员,因此成员B、C将term为1的选票投给成员A并更新自己的term为1。
成员A获得包括自己在内的3张选票,赢得大多数选票,成员A晋升为Leader,并向其他成员发送心跳信息,维护自己的领导地位,如图3所示。
■ 图3 Leader晋升示意
如果成员A在等待投票超过约定的时间内没有收到多数派的选票,则会重置自己的超时,并结束本次选举进程。接着会有其他成员在等待心跳超时后发起Leader选举,在当前案例中,发起Leader选举的顺序为A→C→B。
可能因为网络问题,使集群中的所有成员又发起了一轮选举,但是都没有获得多数派的选票,因此会随机产生新的超时,开始下一个循环的选举。
日志复制是一个一阶段协商的过程,其中,日志项的提交操作由下一轮协商或者心跳消息来代替完成。因此处理事务请求,Raft只需要发送一轮AppendEntries消息即可
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!