raft论文-选主

1、选主

1.1 节点启动

• 以从的身份启动
• 接受主或者候选者的消息

1.2 触发选主流程

• 若没有消息， 超过一段时间则发起选举，升级为候选者
• 增加当前term， 并且切换为候选者角色
• 为自己投票， 并且并行的发送RequestVote消息给其它节点

1.3 选主中断

• 自己赢得选举
• 其它节点赢得选举
• 都没有赢得选举， 并且超时

1.3.1 抢主成功

• 在一个周期内候选者获得大多数的投票
• 在一个周期内， 每个节点最多给一个候选者投票
• 大多数节点确保了在一个周期内最多只有一个主被选出来
• 一旦一个候选者赢得选举， 就会发送心跳包给其它节点来阻止新的选举

1.3.2 抢主失败

• 当候选者收到消息发现已经有主存在， 并且term不比自己的小， 那么切换为从的角色
• 在超过一定时间后， 当自己和别人的没赢得选举的时候， 发起一轮新的选举

1.3.3 如何保证快速选主

• 利用随机时间

1.4 选主疑问

• 当一个节点出现分区， 触发选主， 会不会频繁导致选主， 影响可用性
  1、这个后面章节要介绍到， 为了避免发生不必要的选主， 其它节点并不是无脑的同意候选者， 也会判断主是否真的断开了

• 当候选者知道自己被大多数投票是有一定的延迟性的， 这个时候对外宣布为主， 或者就做主的行为， 是不是有问题:
  a、raft的行为是复制日志， 只有大多数同意才算成功， 如果作为主是过时的， 那么主的行为不会成功
  b、然而不依赖大多数的行为是有问题的, 所以利用raft来选主还需要其它的机制， 比如时间租约的模式

• 节点启动的时候都是从， 为什么不是候选者, 影响结果的正确性或者其它特性么
  1、作为候选者启动并不会影响程序的正确性
  2、然而启动就发起选主， 这个时候日志很大可能是落后的，毕竟是有一段时间服务不可用
  3、启动就发起选主， 由于日志落后， 必然不能赢得选举， 固然会浪费服务的可用性时间