概述
官方描述
ZooKeeper是用于维护配置信息,命名,提供分布式同步和提供组服务的集中式服务。所有这些类型的服务都以某种形式被分布式应用程序使用。每次实施它们时,都会进行很多工作来修复不可避免的错误和争用条件。由于难以实现这类服务,因此应用程序最初通常会跳过它们,这会使它们在存在更改的情况下变得脆弱并且难以管理。即使部署正确,这些服务的不同实现也会导致管理复杂。
Apache ZooKeeper是Apache Software Foundation下的一个开源志愿者项目
Zookeeper的工作机制
系统要求
支持平台
ZooKeeper由多个组件组成。某些组件受到广泛支持,而其他组件仅在较小的一组平台上受支持。
- 客户端是Java客户端库,应用程序使用它来连接到ZooKeeper集合。
- 服务器是在ZooKeeper集成节点上运行的Java服务器。
- Native Client是类似于Java客户端的用C语言实现的客户端,应用程序使用它来连接ZooKeeper集成体。
- Contrib是指多个可选的附加组件。
以下矩阵描述了为在不同的操作系统平台上运行每个组件而承诺的支持级别。
支持矩阵
| 操作系统 | 客户 | 服务器 | 本机客户端 | 贡献者 |
|---|---|---|---|---|
| GNU / Linux | 开发与生产 | 开发与生产 | 开发与生产 | 开发与生产 |
| 的Solaris | 开发与生产 | 开发与生产 | 不支持 | 不支持 |
| FreeBSD的 | 开发与生产 | 开发与生产 | 不支持 | 不支持 |
| 视窗 | 开发与生产 | 开发与生产 | 不支持 | 不支持 |
| Mac OS X | 仅开发 | 仅开发 | 不支持 | 不支持 |
对于矩阵中未明确提及的任何操作系统,组件可能会起作用,也可能不会起作用。ZooKeeper社区将修复针对其他平台报告的明显错误,但没有完全支持。
必备软件
ZooKeeper在Java 1.7或更高版本(JDK 7或更高版本,FreeBSD支持需要openjdk7)中运行。它作为ZooKeeper服务器的整体运行。建议三个最小的ZooKeeper服务器是一个整体的最小大小,我们也建议它们在单独的计算机上运行。在Yahoo!上,ZooKeeper通常部署在专用的RHEL盒上,该盒具有双核处理器,2GB RAM和80GB IDE硬盘。
设计ZooKeeper部署
ZooKeeper的可靠性基于两个基本假设。
- 部署中只有少数服务器将发生故障。在这种情况下,故障意味着机器崩溃,或者是网络中的某些错误,这些错误将服务器与大多数服务器分开。
- 部署的机器正常运行。正确操作意味着正确执行代码,使时钟正常工作以及使存储和网络组件一致运行。
以下各节包含ZooKeeper管理员要考虑的因素,以最大程度地使这些假设成立。其中一些是跨计算机的考虑因素,而另一些则是部署中每台计算机都应考虑的事项。
跨机要求
为了使ZooKeeper服务处于活动状态,必须有大多数可以相互通信的非故障机器。要创建可以容忍F台机器故障的部署,您应该依靠部署2xF + 1台机器。因此,由三台计算机组成的部署可以处理一个故障,而由五台计算机组成的部署可以处理两个故障。请注意,部署六台计算机只能处理两个故障,因为三台计算机不是多数。因此,ZooKeeper部署通常由奇数台计算机组成。
为了最大程度地容忍故障,您应该尝试使机器故障独立。例如,如果大多数计算机共享同一交换机,则该交换机的故障可能导致相关的故障并导致服务中断。共享电源电路,冷却系统等也是如此。
单机要求
如果ZooKeeper必须与其他应用程序竞争以访问诸如存储介质,CPU,网络或内存之类的资源,则其性能将显着下降。ZooKeeper具有很强的耐用性保证,这意味着在允许负责更改的操作完成之前,它使用存储介质记录更改。然后,您应该意识到这种依赖性,如果要确保媒体不会阻止ZooKeeper的操作,请格外小心。您可以采取以下措施来最大程度地减少这种退化:
- ZooKeeper的事务日志必须位于专用设备上。(专用分区是不够的。)ZooKeeper按顺序写入日志,而不进行查找。与其他进程共享日志设备可能导致查找和争用,进而导致数秒的延迟。
- 不要将ZooKeeper放在可能引起交换的情况下。为了使ZooKeeper能够以任何及时性运行,它根本不能被交换。因此,请确保分配给ZooKeeper的最大堆大小不大于ZooKeeper可用的实际内存量。有关更多信息,请参阅下面的避免注意事项。
特点
Zookeeper的特点
- Zookeeper:一个领导者(Leader),多个跟随着(Follower)组成的集群。
- 集群中只有半数以上节点存活,Zookeeper集群就能正常服务
- 全局数据一致,每个server保存一份相同的数据副本,client无论连接到哪个servicer,数据都是一致的。
- 更新请求顺序进行,来自同一个client的更新请求按其发送顺序依次执行。
- 数据更新原子性,一次数据更新要么成功,要么失败。
- 实时性,在一定时间范围内,client能读取到最新数据
数据结构
Zookeeper数据模型的结构与
很类似,整体上可以看作是一棵树,每个节点称做一个znode.每个znode默认能够存储
的数据,每个Znode都可以
数据结构
应用场景
提供的服务包括:统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等,而域名容易记住
统一命名服务
在分布式环境下,经常需要对应用/服务进行统一命名,便于识别。
例如:IP不容易记住,而域名容易记住。
统一命名服务
统一配置管理
统一配置管理
- 分布式环境下,配置文件同步非常常见。
(1)一般要求一个集群中,所有节点的配置信息是一致的,比如kafka集群。
(2)对配置文件修改后,希望能够快速同步到各个节点上。 - 配置管理可交由Zookeeper实现。
(1)可将配置信息写入zookeeper上的一个znode。
(2)各个客户端服务器监听这个znode
(3)一旦znode中的数据被修改,zookeeper将通知各个客户端服务器。
统一集群管理
统一集群管理
- 分布式环境中,实时掌握每个节点的状态是必要的。
(1)可根据节点实时状态做出一些调整 - zookeeper可以实现监控节点状态变化
(1)可将节点信息吸入zookeeper上的一个znode
(2)监听这个znode可获取它的实时状态变化
服务器节点动态上下线
服务器节点动态上下线
软负载均衡
软负载均衡







