主体内容转载自https://cloud.tencent.com/developer/article/1495499，并修改了部分个人觉得有问题的部分

首先简单介绍一下 etcd 的选举方法：

• 初始启动时，节点处于 follower 状态并被设定一个 election timeout，如果在这一时间周期内没有收到来自 leader 的 heartbeat，节点将发起选举：将自己切换为 candidate 之后，向集群中其它 follower 节点发送请求，询问其是否选举自己成为 leader。
• 当收到来自集群中过半数节点的接受投票后，节点即成为 leader，开始接收保存 client 的数据并向其它的 follower 节点同步日志。如果没有达成一致，则 candidate 随机选择一个等待间隔（150ms ~ 300ms）再次发起投票，得到集群中半数以上 follower 接受的 candidate 将成为 leader。
• leader 节点依靠定时向 follower 发送 heartbeat 来保持其地位。
• 任何时候如果其它 follower 在 election timeout 期间都没有收到来自 leader 的 heartbeat，同样会将自己的状态切换为 candidate 并发起选举。每成功选举一次，新 leader 的任期（Term）都会比之前 leader 的任期大 1。

请注意：这里说的超过半数节点接受投票，是包括 candidate 自身在内的！而且这里的半数是以原集群大小作为总数来计算的！举个例子：假设某个 etcd 集群有 N 个节点，挂了一个节点之后，如果重新发起选举，一定要有超过 N/2 个节点接受投票（包括 candidate 在内），即最少需要 (N+1)/2 个节点接受投票，参加选举的节点才能成为 leader。

2. 集群大小与容错

假设有两个 etcd 集群，分别是 2 个节点和 1 个节点，2 节点集群需要所有节点接受投票才能选举成功（N=2），只要有一个节点发生故障，etcd 集群就会变成不可用状态，因为这时不可能选举成功，2 节点集群的容错能力为 0%。

我们把“超过半数节点接受投票的节点数量”称为 majority。

同样的方式，比较 3 节点集群和 4 节点集群。对于 3 节点集群来说，如果其中一个节点发生故障，majority 仍然是 2，集群依然可用。而对于 4 节点集群而言，majority 是 3，只允许一个节点发生故障，如果有两个节点发生故障，majority 就会变成 2，而 2 不满足 > N/2 的要求（N=4）。现在你应该理解为什么奇数个节点与和其配对的偶数个节点相比(比如 3 节点和 4 节点对比)，容错能力相同了。

这里能选择偶数个节点吗？ 最好不要这样。原因有二：

• 偶数个节点集群不可用风险更高，表现在选主过程中，有较大概率获得等额选票，从而触发下一轮选举。
• 偶数个节点集群在某些网络分割的场景下无法正常工作。试想，当网络分割发生后，将集群节点对半分割开。此时集群将无法工作。按照 raft 协议，此时集群写操作无法使得大多数节点同意，从而导致写失败，集群无法正常工作。

当网络分割后，etcd 集群如何处理的呢?

• 当集群的 Leader 在多数节点这一侧时，集群仍可以正常工作。少数节点那一侧无法收到 Leader 心跳，也无法完成选举。
• 当集群的 Leader 在少数节点这一侧时，集群仍可以正常工作，多数派的节点能够选出新的 Leader, 集群服务正常进行。

当网络分割恢复后，少数派的节点会接受集群 Leader 的日志，直到和其他节点状态一致。