Welcome to ZooKeeper(一)：概述

一、什么是zookeeper?

官方说明：

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them, which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.
复制代码

ZooKeeper 是一个集中式服务，用于维护配置信息、命名、提供分布式同步和提供组服务。所有这些类型的服务都以某种形式被分布式应用程序使用。每次实施它们时，都会进行大量工作来修复不可避免的错误和竞争条件。由于实现这些服务比较有难度，应用程序最初通常会忽略它们，这使得它们在发生变化时变得脆弱并且难以管理。即使正确完成，这些服务的不同实现也会在部署应用程序时导致管理复杂性。

通俗来说就是相当于一个第三方协调人，被hadoop（大象）、Hive(蜜蜂)、pig(小 猪)等等分布式应用程序使用，提供的主要功能包括：配置管理、名字服务、分布式锁、集群管理。

其它角度解释：

Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。

举例说明：各个地方的车站将自己的票余信息发送到12306总数据库，然后用户们就可以通过12306官方APP查看某些自己关注的车票，当某个车站的车票售尽时，12306就会将相应的缺额消息发送给关心的用户。

zookeeper架构：

• Leader： ZooKeeper 集群工作的核心事务请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性；集群内部各个服务的调度者。 对于 create，setData，delete 等有写操作的请求，则需要统一转发给 leader 处理，leader 需要决定编号、执行操作，这个过程称为一个事务。

• Follower： 处理客户端非事务（读操作）请求 转发事务请求给 Leader 参与集群 leader 选举投票2n-1台可以做集群投票。此外，针对访问量比较大的 zookeeper 集群，还可以新增Follower角色。
• Observer： 观察者角色，观察ZooKeeper集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给Leader服务器处理，不会参与任何形式的投票只提供服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力,增加并发的请求

zookeeper特性：

1. Zookeeper: 一个领导者(Leader) ，多个跟随者(Follower) 组成的集群。
2. 集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。
3. 全局数据一致:每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
4. 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息 a 在消息 b 前发布，则在所有 server 上消息 a 在消息 b 前被发布，偏序是指如果一个消息 b 在消息 a 后被同一个发送者发布，a 必须将排在 b 前面。
5. 原子性：一次数据更新要么成功，要么失败。
6. 实时性：ZooKeeper 保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。

---

上面提到分布式应用，那什么是分布式应用呢？

分布式应用可以在给定时间（同时）在网络中的多个系统上运行，通过协调它们以快速有效的方式完成特定任务。其有两部分， Server（服务器） 和 Client（客户端） 应用程序。服务器应用程序实际上是分布式的，并具有通用接口，以便客户端可以连接到集群中的任何服务器并获得相同的结果。 客户端应用程序是与分布式应用进行交互的工具。

分布式应用有哪些缺点呢？

• 竞争条件 - 两个或多个机器尝试执行特定任务，实际上只需在任意给定时间由单个机器完成。例如，共享资源只能在任意给定时间由单个机器修改。
• 死锁 - 两个或多个操作等待彼此释放资源或者完成某些条件导致一直无法完成。
• 不一致 - 分布式应用有很多的客户端，怎么保证客户端之间所使用的数据是一致的。

二、应用场景

下面介绍zookeeper的应用场景，从这些应用场景中，去寻找解决分布式应用所遇到的问题。

统一命名服务

在分布式环境下，经常要对应用/程序进行统一的命名，便于识别

例如：IP是不容易记住的，相对而言域名就比较容易记忆，对于一个网站所有的用户都访问同一个域名，而这些域名可能对应着许多不同的服务器，当用户访问域名的时候就可以访问该节点下的服务器而不必记忆它们具体的IP地址

统一配置管理

1. 分布式环境下，配置文件的同步是非常常见的。

   • 一般要求一个集群中，所有节点的配置信息是一致的， 比如Kafka集群。
   • 对配置文件修改后，希望能够快速同步到各个节点上。

2. 配置文件的同步问题可以交给zookeeper管理

   • 将配置信息写入到一个znode中。
   • 各个客户端服务器监听这个znode。
   • 当配置文件的内容发生变化（znode数据发生变化），zookeeper将通知到各个客户端服务器。

统一集群管理

1. 分布式环境中，实时掌握每个节点的状态是必要的。

   • 可根据节点实时状态做出一些调整。

2. ZooKeeper可以实现实时监控节点状态变化。

   • 可将节点信息写入ZooKeeper上的一个ZNode。.
   • 监听这个ZNode可获取它的实时状态变化。

软负载均衡：在zookeeper上面记录每台服务器被访问的次数，当新的request到达的时候，优先让访问数最少的服务器去处理请求。

服务器动态上下线:zookeeper可以实时监控服务器的上下线情况。

选举算法：选举一个节点作为协调目的的leader。

锁定和同步服务：在修改数据的同时锁定数据。防止数据发生异常。

所谓有问题才会有需求才会有进步。面对这些分布式应用所遇到的问题，ZooKeeper框架提供了一个完整的机制来克服所有的挑战。

• 竞争条件和死锁使用故障安全同步方法进行处理。

• ZooKeeper使用原子性解析来解决数据的不一致性问题。

三、基础知识

层次命名空间

下图描述了用于内存表示的ZooKeeper文件系统的树结构。ZooKeeper节点称为 znode 。每个znode由一个名称标识，并用路径(/)序列分隔，每个znode默认可以存储1M的数据。

• 在图中，首先有一个由“/”分隔的znode。在根目录下，有两个逻辑命名空间 config 和 workers 。
• config 命名空间用于集中式配置管理，workers 命名空间用于命名。
• 在 config 命名空间下，每个znode最多可存储1MB的数据。这与UNIX文件系统相类似，但是在zookeeper中父znode也可以存储数据。这种结构的主要目的是存储同步数据并描述znode的元数据。

每个Znode由三个部分组成：

• stat：此为状态信息，描述该Znode版本、权限等信息。

  （1）czxid-创建节点的事务zxid。每次修改ZooKeeper状态都会收到一个zxid形式的时间戳，也就是ZooKeeper事务ID。事务ID是ZooKeeper中所有修改总的次序。每个修改都有唯一的zxid，如果zxid1小于zxid2，那么zxid1在zxid2之前发生。

  （2）ctime - znode被创建的毫秒数(从1970年开始)

  （3）mzxid - znode最后更新的事务zxid

  （4）mtime - znode最后修改的毫秒数(从1970年开始)

  （5）pZxid-znode最后更新的子节点zxid

  （6）cversion - znode子节点变化号，znode子节点修改次数

  （7）dataversion - znode数据变化号

  （8）aclVersion - znode访问控制列表的变化号

  （9）ephemeralOwner- 如果是临时节点，这个是znode拥有者的session id。如果不是临时节点则是0。

  （10）dataLength- znode的数据长度

  （11）numChildren - znode子节点数量

• data：与该Znode关联的数据

• Children：该Znode下的节点

Znode的类型

Znode被分为持久（persistent）节点，顺序（sequential）节点和临时（ephemeral）节点。

• 持久节点 - 即使在创建该特定znode的客户端断开连接后，持久节点仍然存在。默认情况下，除非另有说明，否则所有znode都是持久的。

• 临时节点 - 客户端活跃时，临时节点就是有效的。当客户端与ZooKeeper集合断开连接时，临时节点会自动删除。因此，只有临时节点不允许有子节点。如果临时节点被删除，则下一个合适的节点将填充其位置。临时节点在leader选举中起着重要作用。

• 顺序节点 - 顺序节点可以是持久的或临时的。当一个新的znode被创建为一个顺序节点时，ZooKeeper通过将10位的序列号附加到原始名称来设置znode的路径。例如，如果将具有路径 /myapp 的znode创建为顺序节点，则ZooKeeper会将路径更改为 /myapp0000000001 ，并将下一个序列号设置为0000000002。如果两个顺序节点是同时创建的，那么ZooKeeper不会对每个znode使用相同的数字。顺序节点在锁定和同步中起重要作用。

Sessions（会话）

会话对于ZooKeeper的操作非常重要。会话中的请求按FIFO顺序执行。一旦客户端连接到服务器，将建立会话并向客户端分配会话ID 。

客户端以特定的时间间隔发送心跳以保持会话有效。如果ZooKeeper集合在超过服务器开启时指定的期间（会话超时）都没有从客户端接收到心跳，则它会判定客户端死机。

会话超时通常以毫秒为单位。当会话由于任何原因结束时，在该会话期间创建的临时节点也会被删除。

Watches（监视）

监视是一种简单的机制，使客户端收到关于ZooKeeper集合中的更改的通知。客户端可以在读取特定znode时设置Watches。Watches会向注册的客户端发送任何znode（客户端注册表）更改的通知。

Znode更改是znode相关的数据的修改或znode的子项中的更改。只触发一次watches。如果客户端想要再次通知，则必须通过另一个读取操作来完成。当连接会话过期时，客户端将与服务器断开连接，相关的watches也将被删除。

总结

zookeeper是一个很好的解决了分布式应用面临的问题的协调服务，利用它可以很好的解决锁相关、资源相关、更新相关的问题，并且所有节点之间的协调过程非常简单。