Zookeeper 的数据模型、Zookeeper应用场景

Zookeeper 的数据模型

1、每个子目录项如 NameService 都被称作为znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个znode 的标识为INameservicelServer1

2、znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL（临时节点

EPHEMERAL(临时节点)、EPHEMERAL_SEQUENTIAL(临时顺序节点)）

类型的目录节点不能有子节点目录

3、znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据

4、znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个znode 也将自动删除，

Zookeeper 客户端和服务器通信采用长连接方式每个客户端和服务器嗾使使用心跳来保持链接，这种连接方式称之为session，如果znode 是临时节点，这个 session 失效，znode 也就删除了

5、znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为App2

6、znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是Zookeeper的核心特性

Zookeeper 的很多功能都是基于这个特性实现的。

Zookeeper 的组成

ZK server根据其身份特性分为三种:leader，Follower，Observer，其中Follower和Observer又统称Learner(学习者)。

Leader:负责客户端的writer类型请求

Follower:负责客户端的reader类型请求，参与leader选举等，

Observer:特殊的“Follower"，其可以接受客户端reader请求，但不参与选举(扩容系统支撑能力，提高了读取速度。因为它不接受任何同步的写入请求，只负责与leader同步数据)。

Zookeeper应用场景

Zookeeper从设计模式角度来看，是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，

一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在

Zookeeper 上注册的那些观察者做出相应的反应，从而实现集群中类似Master/Slave 管理模式。

配置管理

集群管理

发布与订阅

数据库切换

分布式日志的收集

分布式锁、队列管理等等

Zookeeper应用场景说明

一、配置管理:配置的管理在分布式应用环境中很常见，比如我们在平常的应用系统中，经常会碰到这样的需求:如机器的配置列表、运行时的开关配置、数据库配置信息等。这些全局配置信息通常具备以下3个特性:

1 数据量比较小。

2 数据内容在运行时动态发生变化。

3 集群中各个节点共享信息，配置一致。

二、集群管理:Zookeeper不仅能够帮你维护当前的集群中机器的服务状态，而且能够帮你选出一个“总管”，让这个总管来管理集群，这就是Zookeeper 的另一个功能Leader，并实现集群容错功能。

1希望知道当前集群中究竞有多少机器工作。

2 对集群中每天集群的运行时状态进行数据收集。

3 对集群中每台集群进行上下线操作。

• 发布与订阅:Zookeeper是一个典型的发布/订阅模式的分布式数控管理与协调框架，开发人员可以使用它来进行分布式数据的发布与订阅。
• 数据库切换:比如我们初始化zookeeper的时候读取其节点上的数据库配置文件，当配置一旦发生变更时，zookeeper就能帮助我们把变更的通知发送到各个客户端，每个了互动在接收到这个变更通知后，就可以从新进行最新数据的获取。
• 分布式日志收集:我们可以做一个日志系统收集集群中所有的日志信息，进行统一管理。

六:zookeeper的特性就是在分布式场景下高可用，但是原生的API实现分布式功能非常困难，团队去实现也太浪费时间，即使实现了也未必稳定。那么可以采用第三方的客户端的完美实现，比如Curator框架，他是Apache的顶级项目

zookeeper使用场景非常广泛:

如Hadoop、Stomm、消息中间件、RPC服务框架、数据库增量订阅与消费组件(如Mysql Binlog)、分布式数据库同步系统，淘宝的Otter。