zookeeper配置集群奇数节点总结
采用奇数个的节点主要是出于两方面的考虑:
1、防止由脑裂造成的集群不可用。
首先,什么是脑裂?集群的脑裂通常是发生在节点之间通信不可达的情况下,集群会分裂成不同的小集群,小集群各自选出自己的master节点,导致原有的集群出现多个master节点的情况,这就是脑裂。下面举例说一下为什么采用奇数台节点,就可以防止由于脑裂造成的服务不可用:
(1) 假如zookeeper集群有 5 个节点,发生了脑裂,脑裂成了A、B两个小集群:
(a) A : 1个节点 ,B :4个节点 , 或 A、B互换
(b) A : 2个节点, B :3个节点 , 或 A、B互换 可以看出,上面这两种情况下,A、B中总会有一个小集群满足 可用节点数量 > 总节点数量/2 。所以zookeeper集群仍然能够选举出leader , 仍然能对外提供服务,只不过是有一部分节点失效了而已。
(2) 假如zookeeper集群有4个节点,同样发生脑裂,脑裂成了A、B两个小集群:
(a) A:1个节点 , B:3个节点, 或 A、B互换
(b) A:2个节点 , B:2个节点 可以看出,情况(a) 是满足选举条件的,与(1)中的例子相同。 但是情况(b) 就不同了,因为A和B都是2个节点,都不满足 可用节点数量 > 总节点数量/2 的选举条件, 所以此时zookeeper就彻底不能提供服务了。综合上面两个例子可以看出: 在节点数量是奇数个的情况下, zookeeper集群总能对外提供服务(即使损失了一部分节点);如果节点数量是偶数个,会存在zookeeper集群不能用的可能性(脑裂成两个均等的子集群的时候)。在生产环境中,如果zookeeper集群不能提供服务,那将是致命的 , 所以zookeeper集群的节点数一般采用奇数个。
2、在容错能力相同的情况下,奇数台更节省资源。leader选举,要求 可用节点数量 > 总节点数量/2 。注意 是 > , 不是 ≥。举两个例子:
(1) 假如zookeeper集群1 ,有3个节点,3/2=1.5 , 即zookeeper想要正常对外提供服务(即leader选举成功),至少需要2个节点是正常的。换句话说,3个节点的zookeeper集群,允许有一个节点宕机。
(2) 假如zookeeper集群2,有4个节点,4/2=2 , 即zookeeper想要正常对外提供服务(即leader选举成功),至少需要3个节点是正常的。换句话说,4个节点的zookeeper集群,也允许有一个节点宕机。那么问题就来了, 集群1与集群2都有 允许1个节点宕机 的容错能力,但是集群2比集群1多了1个节点。在相同容错能力的情况下,本着节约资源的原则,zookeeper集群的节点数维持奇数个更好一些。
- zookeeper集群为什么总是配置奇数个节点
- 为什么zookeeper集群中节点配置个数是奇数个?
- zookeeper集群管理配置优化总结
- 为什么zookeeper的节点配置的个数必须是奇数个
- 2 weekend110的zookeeper的原理、特性、数据模型、节点、角色、顺序号、读写机制、保证、API接口、ACL、选举、 + 应用场景:统一命名服务、配置管理、集群管理、共享锁、队列管理
- CenterOs下kafka、zookeeper、storm集群环境变量配置及启动命令总结
- 为什么zookeeper的节点配置的个数必须是奇数个?
- Centos中Hadoop多节点集群配置 & Zookeeper安装
- zookeeper和java实现的统一配置管理和集群节点管理简单案例
- Zookeeper集群节点数量为什么要是奇数个?
- zookeeper集群管理配置优化总结
- ZooKeeper 02 - ZooKeeper集群的节点为什么是奇数个
- ZooKeeper集群安装与配置(ZooKeeper3.4.6)
- centos7.2(三台腾讯云服务器)配置zookeeper集群
- zookeeper单机伪集群配置
- cassandra单节点的安装与配置——cassandra总结(二)
- Spark集群master节点实现HA配置
- Dubbo的Zookeeper单机配置和Zookeeper集群配置
- zookeeper集群的配置
- zookeeper安装和应用场合(名字,配置,锁,队列,集群管理)