Zookeeper: 一个分布式应用程序协调服务

Zookeeper: A Service for Coordinating Processes of Distributed Applications

A Scalable,reliable,robust centrailized service

ZooKeeper是一个开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。Zookeeper是Hadoop的一个子项目，其发展历程无需赘述。在分布式应用中，由于工程师不能很好地使用锁机制，以及基于消息的协调机制不适合在某些应用中使用，因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。



主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群成员的管理、分布式应用配置项的管理等。

配置管理 某个Job的很多个实例在运行，它们在运行时大多数配置项是相同的，如果想要统一改某个配置，一个个实例去改，是比较低效，也是比较容易出错的方式

命名服务：分布式应用中，通常需要一套完备的命令机制，既能产生唯一的标识，又方便人识别和记忆。 我们知道，每个ZNode都可以由其路径唯一标识，路径本身也比较简洁直观，另外ZNode上还可以存储少量数据，这些都是实现统一的NameService的基础

我们知识，在传统的应用程序中，线程、进程的同步，都可以通过操作系统提供的机制来完成。但是在分布式系统中，多个进程之间的同步，操作系统层面就无能为力了。这时候就需要像ZooKeeper这样的分布式的协调(Coordination)服务来协助完成同步，下面是用ZooKeeper实现简单的互斥锁的步骤，这个可以和线程间同步的mutex做类比来理解：

典型的Master-Slave结构的分布式系统中，Master需要作为“总管”来管理所有的Slave, 当有Slave加入，或者有Slave宕机，Master都需要感知到这个事情，然后作出对应的调整，以便不影响整个集群对外提供服务。 对于新节点的加入和旧节点的删除得到同步的感知。



我们以Hadoop Yarn 架构为例，RM把资源管理和作业控制分离开来，崩溃的可能性已经很低。但依然存在单点故障。 因此，为了以防万一，我们需要对RM作备份。那么做备份的话，就需要处理好备份节点和运行中的节点之间的数据同步问题。以及当运行的RM节点不幸崩溃的话，我们需要从几个备份节点中选取一个节点来替代。那么如何选举最好的备份的节点也是个问题。

另外，就是就是集群成员管理的问题。 举例来说，当有新节点加入，master应该感知它的加入,以便为它分配任务运行。并且新的节点也需要知道整个集群的的基本配置信息，比如说HDFS文件系统的访问路径、机器应该开放的端口段等等。

最后一点，从应用开发者的用户角度来说，应用开发者应该不需要为这种master节点的备份和恢复、新节点的加入的感知策略写代码。 也就是说，集群的分布式协调工作对用户来说是透明的



Clients can connect to a Zookeeper service by connecting to any member of the ensemble.

Tcp connection , periodically sending heartbeats.

Among the ensemble of servers, a server is elected as a leader, and all the remaining servers are made followers. The leader handles all requests that change the ZooKeeper service.



Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统

它包含两种节点，这两种节点可以由客户端创建和删除

一种是长时间存在的节点，并且，这种节点可以拥有子节点。

另外一种是短暂存在的节点，短节点不可以拥有子节点。之所以它是短暂的，是因为当客户端与server的会话连接断开时，那么由客户端创建的短暂的节点就会被zookeeper服务自动删除。与其不同的是，长时间存在的节点不会因客户端和server的会话结束而被删除，会一直保留，知道客户端显式删除。



每一个节点也有其读写权限的限制。与Unix的文件系统不同的是，它的父节点和子节点的权限控制是独立的。也就是父节点的权限信息丝毫不影响子节点的权限信息。你能够删除父节点，但不一定能够删除子节点。 子节点不会继承父节点的权限信息。



ZooKeeper支持一种Watch操作，Client可以在某个ZNode上设置一个Watcher，来监听该ZNode上的变化。如果该ZNode上有相应的变化，就会触发这个Watcher，把相应的事件通知给设置Watcher的Client。需要注意的是，ZooKeeper中的Watcher是一次性的，即触发一次就会被取消，如果想继续Watch的话，需要客户端重新设置Watcher。



Zookeeper 中的事务

This transaction is similar to the concept of a transaction in a database management system.

Each server maintains an in-core database, which represents the entire state of the ZooKeeper namespace.

讲完ZooKeeper的数据模型之后，我们来看一下Client 对数据读写处理的流程是怎样的。

Zookeeper 通过事务来处理客户端的读写请求。

Zookeeper中事务的概念类似于数据库中的事务，事务处理只有两种结果，成功或失败。

每一个Server都包含一个内置的数据库，保存着整个ZooKeeper集群同步的数据模型信息。

Client 可以连接任意一个Server 来获取ZooKeeper 的数据模型信息。 如果是读请求，Server 就直接把本地的数据信息返回给客户端。如果是写请求，则相应的Server把写请求转发给leader,有leader通过广播协议的机制来协调所有的Server进行数据写入的同步。





Leader 首先把对数据的更新请求提议通过Zookeeper 原子广播协议传播给跟随者，每一个跟随者回应leader是否能够满足数据更新请求。当超过一半以上的跟随者同意数据更新请求时，leader正式提交数据写入操作，然后各自的Server把数据写入磁盘。

事务各自间是相互隔离，并且，事务的执行也是按照先进先出队列的顺序执行。



如何解决分布式系统中生产者-消费者问题？

Zookeeper 中的数据模型形成一个生产者-消费者队列。 生产者每创建资源，于队列中子节点就会增加一个。队列中的子节点属性是短暂存在，并且节点创建时按编号排序的。Zookeeper Service能够保证保证这些节点的编号标识是单调递增的。



如何使用Fast election算法实现备份恢复功能？

以Hadoop 为例，当一个RM崩溃时，ZooKeeper 如何如何从备份的RM中选举出新的RM?。A,B,C 按照递增的顺序表示Server 备份的数据的最新状态。比如说A是12点备份的、B是13点备份的，C是15点备份的。