Zookeeper集群
基本概念
-
Zookeeper使用集群形态部署来保证高可用. 在集群中,只要集群中大部分机器是可用的,那么整个Zookeeper服务就是可用的
-
通常情况下,至少要保证有3台服务器才能构成一个Zookeeper集群
-
Zookeeper集群模式 : 主备Master-Slave模式
- Master服务器: 主服务器提供写服务
- Slave服务器: 通过异步复制的方式获取主服务器上的最新数据提供读服务
-
每一个Server代表一个安装Zookeeper服务的服务器
-
组成Zookeeper服务的服务器都会在内存中维护当前的服务器状态,并且每台服务器之间都互相保持着通信
-
Zookeeper集群之间通过ZAB协议 (Zookeeper Atomic Broadcast) 保持数据的一致性
Zookeeper集群角色
-
Zookeeper中没有传统的Master-Slave的概念,而是包含以下三个角色:
-
Leader : 为客户端提供读和写服务,负责投票的发起和决议,更新系统状态
-
Follower : 为客户端提供读服务,如果是写服务则转发给Leader. 在选举过程中参与投票
-
Observer :
- 为客户端提供读服务,如果是写服务则转发给Leader
- 不参与选举过程中的投票,也不参与过半写成功策略
- 在不影响写性能的情况下提升集群的读性能
- Observer角色是Zookeeper3.3之后新增的角色
-
-
Zookeeper集群的选举过程: 当Zookeeper中的Leader服务器出现网络中断,崩溃退出以及重启等异常情况时,就会进入Leader选举过程,这个过程会产生新的Leader服务器
-
选举阶段Leader Election:
- 节点在一开始都是处于选举阶段
- 只要有一个节点得到超过半数节点的票数,就成为准Leader
-
发现阶段Discovery:
- Follower和准Leader之间进行通信,同步Follower最近接收的事务提议
-
同步阶段Synchronization:
- 利用准Leader在发现阶段获得的最新提议历史,同步集群中所有的副本
- 同步完成之后准Leader成为真正的Leader
-
广播阶段Broadcast:
- Zookeeper集群可以正式对外提供事务服务,并且Leader可以进行消息广播
- 如果有新的节点加入,需要对新节点进行同步
-
Zookeeper集群服务器状态
- LOOKING: 寻找Leader
- LEADING: Leader状态. 对应的节点为Leader
- FOLLOWING: Follower状态. 对应的节点为Follower
- OBSERVING: Observer状态. 对应的节点为Observer, 该节点不参与Leader选举
Zookeeper集群服务器数目
-
Zookeeper集群中服务器的数目推荐为奇数台
- Zookeeper集群在宕机部分Zookeeper服务器之后,只有保证剩余的Zookeeper服务器的数量大于宕机的数量,整个Zookeeper集群才会依然可用
- 也就是说,假如集群中Zookeeper服务器的数量有 n n n台,那么要求剩与的Zookeeper服务器的数量必须大于 n 2 \frac{n}{2} 2n台
- 所以 2 n − 1 2n-1 2n−1和 2 n 2n 2n的容忍度是一样的,都是 n − 1 n-1 n−1
- 因此Zookeeper服务器的数量保证奇数量是和偶数量的效果一样的,所以不需要增加一个没有必要的Zookeeper服务器
