Zookeeper详解

Zookeeper概念

       ZooKeeper 是Hadoop下的一个子项目，它是一个针对大型分布式系统的可靠协调系统；它提供的功能包括：配置维护、名字服务、分布式同步、组服务等； 它的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户Zookeeper一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心，服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据，简单示例图如下：

Zookeeper的主要功能

1. 配置管理

       这个好理解。分布式系统都有好多机器，比如我在搭建hadoop的HDFS的时候，需要在一个主机器上（Master节点）配置好HDFS需要的各种配置文件，然后通过scp命令把这些配置文件拷贝到其他节点上，这样各个机器拿到的配置信息是一致的，才能成功运行起来HDFS服务。Zookeeper提供了这样的一种服务：一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得变更。这样就省去手动拷贝配置了，还保证了可靠和一致性。 

2. 名字服务

       这个可以简单理解为一个电话薄，电话号码不好记，但是人名好记，要打谁的电话，直接查人名就好了。 分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务； 类似于域名与ip之间对应关系，域名容易记住； 通过名称来获取资源或服务的地址，提供者等信息。

3. 分布式锁

       碰到分布二字貌似就难理解了，其实很简单。单机程序的各个进程需要对互斥资源进行访问时需要加锁，那分布式程序分布在各个主机上的进程对互斥资源进行访问时也需要加锁。很多分布式系统有多个可服务的窗口，但是在某个时刻只让一个服务去干活，当这台服务出问题的时候锁释放，立即fail over到另外的服务。这在很多分布式系统中都是这么做，这种设计有一个更好听的名字叫Leader Election(leader选举)。举个通俗点的例子，比如银行取钱，有多个窗口，但是呢对你来说，只能有一个窗口对你服务，如果正在对你服务的窗口的柜员突然有急事走了，那咋办？找大堂经理（zookeeper）!大堂经理指定另外的一个窗口继续为你服务！

4. 集群管理

       在分布式的集群中，经常会由于各种原因，比如硬件故障，软件故障，网络问题，有些节点会进进出出。有新的节点加入进来，也有老的节点退出集群。这个时候，集群中有些机器（比如Master节点）需要感知到这种变化，然后根据这种变化做出对应的决策。我已经知道HDFS中namenode是通过datanode的心跳机制来实现上述感知的，那么我们可以先假设Zookeeper其实也是实现了类似心跳机制的功能吧！

5. 分布式通知与协调

       分布式环境中，经常存在一个服务需要知道它所管理的子服务的状态。 NameNode需知道各个Datanode的状态，JobTracker需知道各个TaskTracker的状态；心跳检测机制可通过ZooKeeper来实现；信息推送可由ZooKeeper来实现，ZooKeeper相当于一个发布/订阅系统。

6. 分布式队列

       分布式队列分为两种：当一个队列的成员都聚齐时这个队列才可用，否则一直等待所有成员到达，这种是同步队列 。a）一个job由多个task组成，只有所有任务完成后job才运行完成； b）可为job创建一个/job目录，然后在该目录下为每个完成的task创建一个临时的Znode，一旦临时节点数目达到task总数，则表明job运行完成。队列按照FIFO方式进行入队和出队操作，例如实现生产者和消费者模型。

Zookeeper的主要特点

• 最终一致性：为客户端展示同一视图，这是zookeeper最重要的功能。 
• 可靠性：如果消息被到一台服务器接受，那么它将被所有的服务器接受。 
• 实时性：Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 
• 等待无关（wait-free）：慢的或者失效的client不干预快速的client的请求。 
• 原子性：更新只能成功或者失败，没有中间状态。 
• 顺序性：所有Server，同一消息发布顺序一致。

用到Zookeeper的系统

• HDFS中的HA方案；
• YARN的HA方案；
• HBase：必须依赖Zookeeper，保存了Regionserver的心跳信息，和其他的一些关键信息；
• Flume：负载均衡，单点故障。

Zookeeper的基本架构

• 每个Server在内存中存储了一份数据；
• Zookeeper启动时，将从实例中选举一个leader（Paxos协议）；
• Leader负责处理数据更新等操作（Zab协议）；
• 一个更新操作成功，当且仅当大多数Server在内存中成功修改数据。

       ZooKeeper分为服务器端（Server） 和客户端（Client），客户端可以连接到整个 ZooKeeper服务的任意服务器上（除非 leaderServes 参数被显式设置， leader 不允许接受客户端连接）。客户端使用并维护一个 TCP 连接，通过这个连接发送请求、接受响应、获取观察的事件以及发送心跳。如果这个 TCP 连接中断，客户端将自动尝试连接到另外的 ZooKeeper服务器。客户端第一次连接到 ZooKeeper服务时，接受这个连接的 ZooKeeper服务器会为这个客户端建立一个会话。当这个客户端连接到另外的服务器时，这个会话会被新的服务器重新建立。上图中每一个Server代表一个安装Zookeeper服务的机器，即是整个提供Zookeeper服务的集群（或者是由伪集群组成）；组成ZooKeeper服务的服务器必须彼此了解。 它们维护一个内存中的状态图像，以及持久存储中的事务日志和快照， 只要大多数服务器可用，ZooKeeper服务就可用；ZooKeeper 启动时，将从实例中选举一个 leader，Leader 负责处理数据更新等操作，一个更新操作成功的标志是当且仅当大多数Server在内存中成功修改数据。每个Server 在内存中存储了一份数据。Zookeeper是可以集群复制的，集群间通过Zab协议（Zookeeper Atomic Broadcast）来保持数据的一致性；Zab协议包含两个阶段：leader election阶段和Atomic Brodcast阶段。集群中将选举出一个leader，其他的机器则称为follower，所有的写操作都被传送给leader，并通过brodcast将所有的更新告诉给follower。当leader崩溃或者leader失去大多数的follower时，需要重新选举出一个新的leader，让所有的服务器都恢复到一个正确的状态。当leader被选举出来，且大多数服务器完成了和leader的状态同步后，leadder election 的过程就结束了，就将会进入到Atomic brodcast的过程。Atomic Brodcast同步leader和follower之间的信息，保证leader和follower具有形同的系统状态。

Zookeeper Server 节点的数目

       Zookeeper Server数目一般为奇数，Leader选举算法采用了Paxos协议；Paxos核心思想：当多数Server写成功，则任务数据写成功。也就是说如果有3个Server，则两个写成功即可；如果有4或5个Server，则三个写成功即可。 Server数目一般为奇数（3、5、7） 如果有3个Server，则最多允许1个Server挂掉；如果有4个Server，则同样最多允许1个Server挂掉既然如此，为啥要用4个Server？

Observer节点

       3.3.0以后版本新增角色Observer增加原因：Zookeeper需保证高可用和强一致性；当集群节点数目逐渐增大为了支持更多的客户端时需要增加更多Server，然而Server增多，投票阶段延迟增大，从而影响性能。为了权衡伸缩性和高吞吐率，引入Observer： Observer不参与投票； Observers接受客户端的连接，并将写请求转发给leader节点； 加入更多Observer节点，提高伸缩性，同时不影响吞吐率。

Zookeeper写流程：

 
       客户端首先和一个Server或者Observe（可以认为是一个Server的代理）通信，发起写请求，然后Server将写请求转发给Leader，Leader再将写请求转发给其他Server，Server在接收到写请求后写入数据并相应Leader，Leader在接收到大多数写成功回应后，认为数据写成功，相应Client。

Zookeeper数据模型

 
       Zookeeper采用层次化的目录结构，命名符合常规文件系统规范； 每个目录在zookeeper中叫做znode,并且其有一个唯一的路径标识； Znode可以包含数据和子znode(ephemeral类型的节点不能有子znode)；Znode中的数据可以有多个版本，比如某一个Znode下存有多个数据版本，那么查询这个路径下的数据需带上版本；客户端应用可以在znode上设置监视器(Watcher)； Znode不支持部分读写，而是一次性完整读写；Znode有两种类型，短暂的(ephemeral)和持久的(persistent)；Znode的类型在创建时确定并且之后不能再修改；ephemeralznode的客户端会话结束时，zookeeper会将该ephemeral znode删除，ephemeralzn ode不可以有子节点；persistentznode不依赖于客户端会话，只有当客户端明确要删除该persistent znode时才会被删除；Znode有四种形式的目录节点，PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、PHEMERAL_SEQUENTIAL。

原文链接地址： https://blog.csdn.net/xuxiuning/article/details/51218941