Leader选举流程是什么样的？

如果系统中只有唯一一个节点，读写操作都由这一个节点来负责，不会存在数据不一致的问题。

但是，对于分布式系统会存在至少两个节点，需要有一个角色来充唯一的节点，我们把这个唯一节点叫做 Leader 节点，其他节点叫做 Follower 节点， leader 选举过程中才会有的状态叫做 Candidate 节点。

为了便于理解和说明，假设集群中有三个节点：节点A、节点B、节点C。

集群启动后，初始节点状态都是 Follower 状态。最开始各个节点启动之后，此时集群内还没有 Leader。

如果每次各节点都投票给自己，Leader 会始终无法选出来，这样僵持下去肯定是不行的。所以出现了 electionTimeout 的概念，称为 选举超时时间 每个节点都会有 electionTimeout。

一旦发现一轮投票没有结果，集群中各节点自身设置一个 electionTimeout，时间范围在 150ms ~ 300ms 之间的一个随机值。

当节点 A 的 electionTimeout 时间到了，会将节点 A 状态变为 Candidate 状态，节点 A 苏醒过来，很Happy，终于可以参与竞选了，立马给自己投了一票 。然后向集群中其他两个节点发起选举投票（Http协议或者RPC协议请求都可以）。

节点B、C可以认为处于 Follower 状态，如何进行选举投票呢？

这里就出现了 term 的概念，每个节点都会有个 term，term 表示任期，跟美国总统竞选里的任期类似。term 是一个全局且连续递增的整数，每完成一次选举，term会递增 +1。

Follower 状态的节点此时收到 Candidate 选举请求，发现集群中就只有一个 Candidate 状态的节点 A，所以直接投票给 Candidate 节点。

这里就出现了 voteFor 的概念，每个节点都会有voteFor，voteFor 表示投票的数据。

节点 A 收到投票反馈之后，引出了另外的判断条件：必须是集群中过半节点都投票给自己，也包括自己。

算式：n / 2 + 1

举个：

集群中有三个节点，3 / 2 + 1 = 2 必须有 2 个节点投票成功。

集群中有五个节点，5 / 2 + 1 = 3 必须有 3 个节点投票成功。

最终 Candidate 状态的节点 A 很荣幸晋升为 Leader。