Appearance
Redis 集群推荐奇数个节点的原因
1. 缘起
被很多资料误导了，说什么 Redis 只能是奇数个节点。其实这是一种错误的说法，Redis 只不过是推荐奇数个节点，从来没有过必须是奇数节点的说法，那么这是为什么呢？
2. 为什么 Redis 推荐奇数个节点
其主要原因还是从成本上考虑的，因为奇数个节点和偶数个节点允许宕机的节点数是一样的，比如 3 个节点和 4 个节点都只允许宕机一台，那么为什么要搞 4 个节点去浪费服务资源呢？
那么话又说回来了，为什么三个节点和四个节点都只允许宕机一个节点呢？这是因为 Redis 规定：
集群中，半数以上节点认为主节点故障了，才会选举新的节点。
2.1. 三个节点的情况
我们假设存在这样一个 Redis 集群（A、B、C 三个节点）A 节点是主节点
2.1.1. 情况一：坏了一个节点
如果是 A 节点坏了，就需要从 B 和 C 里面选举一个节点出来作为主节点，而因为 B 和 C 占比在集群中个占 33.333%。那么投票会有以下四种情况和对应结果：
- B 和 C 都投给自己，各占比 33.33%，不满足超过半数的约定，重新选举
- B 和 C 都投给对方，各占比 33.33%，不满足超过半数的约定，重新选举
- B 投给自己，C 投给了 B，B 被选举为主节点，系统恢复运行
- C 投给自己，B 投给了 C，C 被选举为主节点，系统恢复运行
可以看到，只要投票次数足够多，总能从 B 或者 C 中选举出来一个主节点，系统总是能够自动恢复的。
2.1.2. 情况二：坏了两个节点
假设 A 和 B 或者 A 和 C 都坏了，剩下的一个节点占比只有 33.333%。那么他是没法选举自己为主节点的，整个系统也是没法恢复正常的。
2.2. 四个节点的情况
2.2.1. 情况一：坏了一个节点
如果是 A 节点坏了，就需要从 B 和 C 和 D 里面选举一个节点出来作为主节点，而因为 B 和 C 和 D 占比在集群中个占 25%。那么投票会有以下几种情况和对应结果：
- B 和 C 和 D 都投给自己，各占比 25%，不满足超过半数的约定，重新选举
- B 和 C 和 D 都投给对方，各占比 25%，不满足超过半数的约定，重新选举
- C 和 D 投给了 B，B 投给了 C。B 占比 50%,C 占比 25%。还是没有节点满足超过半数的约定，重新选举
- C 和 D 投给了 B，B 投给了自己，B 占比 75%。B 被选举为主节点，整个系统恢复正常
其他情况自行脑补
2.2.2. 情况二：坏了两个节点
如果是 A 和 B 坏了，剩下的 C 和 D 投票最多只能投到 50%。不满足超过半数的约定，系统无法恢复正常。
3. 总结
通过上面的分析，想必可以清楚，不管是 3 个节点还是 4 个节点，都只能允许一个节点宕机。所以在实际使用过程中出于成本的考虑，一般会建议奇数个节点。
但是：4 个节点的性能和容量是比 3 个节点高的，如果对性能方面有要求的，也可以偶数个节点，Redis 是完全支持的。
关于 zookeeper 为什么推荐奇数个节点还有一个原因是因为脑裂的问题：https://blog.csdn.net/adorechen/article/details/82791280
参考：https://blog.csdn.net/weixin_33860553/article/details/91682263