Zookeeper架构Day03-Zookeeper集群

原创

攻城狮Chova 2021-05-18 14:27:44 ©著作权

©著作权归作者所有：来自51CTO博客作者攻城狮Chova的原创作品，请联系作者获取转载授权，否则将追究法律责任

基本概念

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集群服务器状态

Zookeeper集群服务器数目

Zookeeper集群中服务器的数目推荐为奇数台
- Zookeeper集群在宕机部分Zookeeper服务器之后,只有保证剩余的Zookeeper服务器的数量大于宕机的数量,整个Zookeeper集群才会依然可用
- 也就是说,假如集群中Zookeeper服务器的数量有 $n$ 台,那么要求剩与的Zookeeper服务器的数量必须大于 $\frac{n}{2}$ 台
- 所以 $2 n - 1$ 和 $2 n$ 的容忍度是一样的,都是 $n - 1$
- 因此Zookeeper服务器的数量保证奇数量是和偶数量的效果一样的,所以不需要增加一个没有必要的Zookeeper服务器