本文内容解释etcd集群为什么推荐是奇数个节点
内容转载自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 的日志，直到和其他节点状态一致。
所以综合考虑性能和容错能力，etcd 官方文档推荐的 etcd 集群大小是 3, 5, 7。至于到底选择 3，5 还是 7，根据需要的容错能力而定。
关于节点数和容错能力对应关系，如下表所示：
| 集群大小 | 最大容错 |
|---|---|
| 1 | 0 |
| 2 | 0 |
| 3 | 1 |
| 4 | 1 |
| 5 | 2 |
| 6 | 2 |
| 7 | 3 |
| 8 | 3 |