ZooKeeper 架构原理

ZooKeeper 是什么？

          ZooKeeper 是一个针对大型分布式系统的可靠协调系统；它提供的功能包括：配置维护、名字服务、分布式同步、组服务等； 它的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户； ZooKeeper 已经成为 Hadoop 生态系统中的基础组件。

ZooKeeper特点

ZooKeeper 主要包含以下几个特点：

1、最终一致性：为客户端展示同一视图，这是 ZooKeeper 最重要的性能。

2、可靠性：如果消息被一台服务器接受，那么它将被所有的服务器接受。

3、实时性：ZooKeeper 不能保证两个客户端同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

4、等待无关（wait-free）：慢的或者失效的 client 不干预快速的client的请求。

5、原子性：更新只能成功或者失败，没有中间其它状态。

6、顺序性：对于所有Server，同一消息发布顺序一致。

哪些系统用到了ZooKeeper？

主要有如下系统使用了ZooKeeper：

1、HDFS 文件存储系统。

2、下一代 Hadoop，Hadoop2.0即YARN。

3、Storm 实时计算框架。

4、HBase 分布式数据库。

5、Flume 流数据导入工具。

ZooKeeper 基本原理

ZooKeeper 架构

下面我们首先看一下 ZooKeeper 的架构图：

针对上面的 ZooKeeper 架构图，我们需要掌握以下几点内容。

1、每个Server 在内存中存储了一份数据。

2、ZooKeeper 启动时，将从实例中选举一个 leader（根据Paxos协议来选举，大家知道有这么个协议即可）。

3、Leader 负责处理数据更新等操作（这里用到Zab协议，大家知道有这么个协议即可）

4、一个更新操作成功的标志是当且仅当大多数Server在内存中成功修改数据。

Zookeeper 角色

Zookeeper中的角色主要有以下三类，如下表所示：

观察者（ObServer）

3.3.0版本新增了角色ObServer，那么为什么要引入ObServer角色呢？主要由于以下几种原因：

1、ZooKeeper 需保证高可用和强一致性。

2、为了支持更多的客户端，需要增加更多的Server。

3、Server增多会导致投票阶段延迟增大，影响性能。

ZooKeeper 权衡了伸缩性和高吞吐率，从而引入了ObServer角色。它的作用主要表现在以下几个方面：

1）ObServer 不参与投票过程，只同步 leader的状态。。

2）Observers 接受客户端的连接，并将写请求转发给 leader节点。

3）加入更多ObServer 节点，提高伸缩性，同时还不影响吞吐率。

ZooKeeper Server

我们从以下几个方面来理解 ZooKeeper Server：

1、Leader 选举算法采用了 Paxos 协议。

2、Paxos 核心思想是当多数 Server 写成功，则任务数据写成功。

1）如果有3个Server，则需两个写成功即表示任务数据写成功。

2）如果有4或5个Server，则需三个写成功即表示任务数据写成功。

3、Server 数目一般为奇数，例如 3、5、7等等。

1）如果有3个Server，则最多允许1个Server 挂掉。

2）如果有4个Server，则同样最多允许1个Server挂掉。

既然3个或者4个Server，同样最多允许1个Server挂掉，那么它们的可靠性是一样的，所以选择奇数个ZooKeeper Server即可，这里选择3个Server。

ZooKeeper 写数据流程

ZooKeeper 写数据的流程图如下所示：

ZooKeeper 的写数据流程主要分为以下几步：

1、比如 Client 向 ZooKeeper 的 Server1 上写数据，发送一个写请求。

2、如果Server1不是Leader，那么Server1 会把接受到的请求进一步转发给Leader，因为每个ZooKeeper的Server里面有一个是Leader。这个Leader 会将写请求广播给各个Server，比如Server1和Server2， 各个Server写成功后就会通知Leader。

3、当Leader收到大多数 Server 数据写成功了，那么就说明数据写成功了。如果这里三个节点的话，只要有两个节点数据写成功了，那么就认为数据写成功了。写成功之后，Leader会告诉Server1数据写成功了。

4、Server1会进一步通知 Client 数据写成功了，这时就认为整个写操作成功。ZooKeeper 整个写数据流程就是这样的。

ZooKeeper 数据模型

下面是一个典型的ZooKeeper 数据模型。

ZooKeeper 它里面是如何组织用户数据的呢？下面让我们来一起学习；

1、ZooKeeper提供了一个层次化的目录结构，命名符合常规文件系统规范。

2、每个节点在ZooKeeper中叫做znode，并且它有一个唯一的路径标识。

3、节点Znode可以包含数据和子节点

4、Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本， 那么查询这个路径下的数据需带上版本号。

5、客户端应用可以在节点上设置监视器（Watcher）。

6、节点Znode不支持部分读写，而是一次性完整读写。

7、Znode 有两种类型：短暂的（ephemeral）和持久的（persistent）。

8、Znode的类型在创建时确定并且之后不能再修改。

9、短暂Znode的客户端会话结束时，ZooKeeper会将该短暂Znode删除，短暂的Znode不可以有子节点。

10、持久的Znode不依赖于客户端会话，只有当客户端明确要删除该持久Znode时才会被删除。

11、Znode有四种形式的目录节点，PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、EPHEMERAL_SEQUENTIAL。

ZooKeeper 应用场景

统一命名服务

统一命名服务的命名结构图如下所示：

1、在分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。

1）类似于域名与ip之间对应关系，ip不容易记住，而域名容易记住。

2）通过名称来获取资源或服务的地址，提供者等信息。

2、按照层次结构组织服务/应用名称。

1）可将服务名称以及地址信息写到ZooKeeper上，客户端通过ZooKeeper获取可用服务列表类。

配置管理

配置管理结构图如下所示：

1、分布式环境下，配置文件管理和同步是一个常见问题。

1）一个集群中，所有节点的配置信息是一致的，比如 Hadoop 集群。

2）对配置文件修改后，希望能够快速同步到各个节点上。

2、配置管理可交由ZooKeeper实现。

1）可将配置信息写入ZooKeeper上的一个Znode。

2）各个节点监听这个Znode。

3）一旦Znode中的数据被修改，ZooKeeper将通知各个节点。

集群管理

集群管理结构图如下所示：

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

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

2、可交由ZooKeeper实现。

1）可将节点信息写入ZooKeeper上的一个Znode。

2）监听这个Znode可获取它的实时状态变化。

3、典型应用

1）HBase中Master状态监控与选举。

分布式通知与协调

1、分布式环境中，经常存在一个服务需要知道它所管理的子服务的状态。

1）NameNode需知道各个Datanode的状态。

2）JobTracker需知道各个TaskTracker的状态。

2、心跳检测机制可通过ZooKeeper来实现。

3、信息推送可由ZooKeeper来实现，ZooKeeper相当于一个发布/订阅系统。

分布式锁

处于不同节点上不同的服务，它们可能需要顺序的访问一些资源，这里需要一把分布式的锁。分布式锁具有以下特性：

1、ZooKeeper是强一致的。比如各个节点上运行一个ZooKeeper客户端，它们同时创建相同的Znode，但是只有一个客户端创建成功。

2、实现锁的独占性。创建Znode成功的那个客户端才能得到锁，其它客户端只能等待。当前客户端用完这个锁后，会删除这个Znode，其它客户端再尝试创建Znode，获取分布式锁。

3、控制锁的时序。各个客户端在某个Znode下创建临时Znode，这个类型必须为CreateMode.EPHEMERAL_SEQUENTIAL，这样该Znode可掌握全局访问时序。

分布式队列

分布式队列分为两种：

1、当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。

1）一个job由多个task组成，只有所有任务完成后，job才运行完成。

2）可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时的Znode，一旦临时节点数目达到task总数，则表明job运行完成。

2、队列按照FIFO方式进行入队和出队操作，例如实现生产者和消费者模型。