ZooKeeper 一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心。
服务生产者将自己提供的服务注册到 ZooKeeper 中心,服务的消费者在进行服务调用的时候先到 ZooKeeper 中查×××,获取到服务生产者的详细信息之后,再去调用服务生产者的内容与数据。
如下图所示,在 Dubbo 架构中 ZooKeeper 就担任了注册中心这一角色。
Ⅲ.结合个人使用讲一下 ZooKeeper
在我自己做过的项目中,主要使用到了 ZooKeeper 作为 Dubbo 的注册中心(Dubbo 官方推荐使用 ZooKeeper 注册中心)。
另外在搭建 Solr 集群的时候,我使用 ZooKeeper 作为 Solr 集群的管理工具。
这时,ZooKeeper 主要提供下面几个功能:
-
集群管理:容错、负载均衡。
-
配置文件的集中管理。
-
集群的入口。
我个人觉得在使用 ZooKeeper 的时候,最好是使用集群版的 ZooKeeper 而不是单机版的。
官网给出的架构图就描述的是一个集群版的 ZooKeeper 。通常 3 台服务器就可以构成一个 ZooKeeper 集群了。
为什么最好使用奇数台服务器构成 ZooKeeper 集群?
我们知道在 ZooKeeper 中 Leader 选举算法采用了 Zab 协议。Zab 核心思想是当多数 Server 写成功,则任务数据写成功:
-
如果有 3 个 Server,则最多允许 1 个 Server 挂掉。
-
如果有 4 个 Server,则同样最多允许 1 个 Server 挂掉。
既然 3 个或者 4 个 Server,同样最多允许 1 个 Server 挂掉,那么它们的可靠性是一样的。
所以选择奇数个 ZooKeeper Server 即可,这里选择 3 个 Server。
二、
《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》
【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享
关于 ZooKeeper 的一些重要概念
======================
Ⅰ.重要概念总结
关于 ZooKeeper 的一些重要概念:
-
ZooKeeper 本身就是一个分布式程序(只要半数以上节点存活,ZooKeeper 就能正常服务)。
-
为了保证高可用,最好是以集群形态来部署 ZooKeeper,这样只要集群中大部分机器是可用的(能够容忍一定的机器故障),那么 ZooKeeper 本身仍然是可用的。
-
ZooKeeper 将数据保存在内存中,这也就保证了 高吞吐量和低延迟(但是内存限制了能够存储的容量不太大,此限制也是保持 Znode 中存储的数据量较小的进一步原因)。