作者回复: 加一颗星:),可以这么理解,Raft领导者选举的关键是随机超时时间、一个节点在一个任期只有一张选票、基于任期编号大小和日志完整度来投票。
作者回复: 加一颗星:),其实节点的奇偶数不影响选举结果,影响的是节点故障容错能力,比如,4节点集群和3节点集群的“大多数”分别是3和2,也就是n/2 + 1,都只能容忍1个节点的故障。
作者回复: 加一颗星:),可以这么理解,每个节点维护一个投票池,每个投票池都包含自己和其他节点推荐的领导者的节点信息,如果有节点赢得大多数投票,那么这时会判断这个节点是否是自己,如果是自己,那么节点将设置自己的状态为LEADING状态,退出选举;如果不是自己,那么节点将设置自己的状态为FOLLOWING状态,退出选举。
作者回复: 加一颗星:),Raft是可以的,这个特性与ZAB的设计有关,在我看来,这个设计不是很精巧,我会在接下来的加餐中,具体说说。
作者回复: 加一颗星:)
作者回复: 加一颗星:),问题1:主要是为了避免接受到旧的投票信息;会的,具体细节,可参考FastLeaderElection.lookForLeader() 的实现。 问题2:是一个AtomicLong的变量(hzxid),因为领导者的存在,所以事务id,本质上是“单机”的,原子变量就可以了。
作者回复: 加一颗星:),引入超时,更确切的说是读超时,读超时且没有接收到其他节点的新的选票,重新发送自己的投票,在ZooKeeper中,这个值,初始值为200ms,之后每次超时时,指数退避,增加时长,最大值为60s,具体的实现,可以参考FastLeaderElection.lookForLeader()函数。
作者回复: 加一颗星:)
作者回复: 加一颗星:)
作者回复: 加一颗星:),可以把逻辑时钟理解为选举的轮次,会影响选票的有效性,主要是为了避免接受到旧的投票信息。