ZooKeeper高可用之集群搭建
前言
ZooKeeper 是一个典型的分布式数据一致性解决方案,分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。ZooKeeper功能很强大,但是在分布式项目中也会存在单点失败问题,所以为了实现服务的高可用,ZooKeeper的集群也是必不可少的。
集群架构
为了保证高可用,最好是以集群形态来部署 ZooKeeper,这样只要集群中大部分机器是可用的(能够容忍一定的机器故障),那么 ZooKeeper 本身仍然是可用的。
客户端在使用 ZooKeeper 时,需要知道集群机器列表,通过与集群中的某一台机器建立 TCP 连接来使用服务。
客户端使用这个 TCP 链接来发送请求、获取结果、获取监听事件以及发送心跳包。如果这个连接异常断开了,客户端可以连接到另外的机器上。
ZooKeeper 官方提供的架构图:
上图中每一个 Server 代表一个安装 ZooKeeper 服务的服务器。组成 ZooKeeper 服务的服务器都会在内存中维护当前的服务器状态,并且每台服务器之间都互相保持着通信。
集群间通过 Zab 协议(Zookeeper Atomic Broadcast)来保持数据的一致性。
集群中的角色
通常我们在构建集群的时候会引入Master/Slave(主从模式),在这种模式中,通常 Master 服务器作为主服务器提供写服务,其他的 Slave 服务器从服务器通过异步复制的方式获取 Master 服务器最新的数据提供读服务。
但是ZooKeeper中没有选择传统的 Master/Slave 概念,而是引入了Leader、Follower 和 Observer 三种角色。
ZooKeeper 集群中的所有机器通过一个 Leader 选举过程来选定一台称为 “Leader” 的机器。
Leader 既可以为客户端提供写服务又能提供读服务。除了 Leader 外,Follower 和 Observer 都只能提供读服务。
Follower 和 Observer 唯一的区别在于 Observer 机器不参与 Leader 的选举过程,也不参与写操作的“过半写成功”策略,因此 Observer 机器可以在不影响写性能的情况下提升集群的读性能。
为什么最好是奇数
我们知道在 ZooKeeper 中 Leader 选举算法采用了 Zab 协议。Zab 核心思想是当多数(这里过半数即可理解为多数) Server 写成功,则任务数据写成功:
-
如果有 3 个 Server,则最多允许 1 个 Server 挂掉。
-
如果有 4 个 Server,则同样最多允许 1 个 Server 挂掉。
既然 3 个或者 4 个 Server,同样最多允许 1 个 Server 挂掉,那么它们的可靠性是一样的。
所以选择奇数个 ZooKeeper Server 即可,这里选择 3 个 Server
参考文献
摘取自 开源中国
作者:SnailClimb