为啥ZooKeeper 集群的服务器数部署成奇数？偶数不行吗？

#### 过半存活特性 ZooKeeper 集群具有“过半存活即可用”的特性，即一个 ZooKeeper 集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信。基于这个特性，如果想搭建一个能够允许 N 台机器 down 掉的集群，那么就要部署一个由 2*N+1 台服务器构成的 ZooKeeper 集群。 #### 服务器数与容灾能力的关系 - **3台服务器的ZooKeeper集群**： - 允许挂掉1台机器后依然正常工作。 - **5台服务器的ZooKeeper集群**： - 允许挂掉2台机器后依然正常工作。 - **6台服务器的ZooKeeper集群**： - 同样只允许挂掉2台机器。如果挂掉3台，剩下的机器就无法实现过半存活。 #### 奇数服务器的优势 从上述分析可以看出，对于一个由6台机器构成的ZooKeeper集群，与一个由5台机器构成的ZooKeeper集群相比，其在容灾能力上并没有任何显著的优势，反而多占用了一个服务器资源。基于这个原因，ZooKeeper集群通常设计部署成奇数台服务器即可。 ### 总结 ZooKeeper集群的服务器数通常建议部署成奇数，这是因为： 1. **过半存活特性**：ZooKeeper集群需要过半机器正常工作才能对外提供服务。 2. **资源效率**：部署奇数台服务器可以在相同的容灾能力下，最大化资源利用效率。例如，5台服务器和6台服务器的容灾能力相同，但6台服务器多占用了一个服务器资源。 3. **容灾能力**：奇数台服务器的部署能够有效提升系统的容灾能力。例如，3台服务器可以挂掉1台，5台服务器可以挂掉2台。 因此，ZooKeeper官方建议将集群服务器数部署成奇数台，以确保在同等条件下实现最佳的容灾能力和资源利用效率。

Zookeeper 集群通常配置为奇数个节点，这是为了提高系统的可用性和容错能力。以下是具体原因： #### 1. 确保可用节点数超过半数 Zookeeper 选举规则要求 Leader 选举和写请求都需要超过一半节点的同意才能有效。集群的可用性取决于是否有超过一半的节点正常工作： - **超过一半节点同意**： - Leader 选举需要超过一半的节点同意。 - 写请求需要超过一半的节点同意才能被认为是成功的。 - 集群整体的可用性取决于是否超过一半的节点正常工作。 #### 2. 容错能力与节点数量的关系 通过分析不同节点数下的容错能力，可以发现奇数个节点更有效： - **2 个节点**： - 需要 2 个节点都正常才能保持集群可用（容错度为 0）。 - **3 个节点**： - 可以容忍 1 个节点失效，剩余 2 个节点超过半数（容错度为 1）。 - **4 个节点**： - 需要 3 个节点正常才能保持集群可用（容错度为 1）。 - **5 个节点**： - 可以容忍 2 个节点失效，剩余 3 个节点超过半数（容错度为 2）。 可以发现，奇数个节点的集群在同样的容错度下，节省了一个节点。例如，3 个节点和 4 个节点的容错度相同，但 3 个节点的配置更有效。 #### 3. 避免选举时的平票情况 在 Leader 选举过程中，必须要有超过一半的节点同意才能选出新的 Leader。如果节点数为偶数，可能会导致投票结果平票，无法选出新的 Leader： - **奇数个节点**： - 总是能确保选举过程中不会出现平票情况，能顺利选出 Leader。 ### 总结 - **确保可用节点数超过半数**：保证集群在超过一半节点正常工作时是可用的。 - **更高的容错能力**：奇数个节点在相同容错度下更有效，避免浪费资源。 - **避免选举时的平票情况**：确保选举过程中能顺利选出 Leader。 因此，Zookeeper 集群通常配置为奇数个节点，以提高系统的可用性和容错能力，避免选举过程中的平票问题。