Zookeeper入门详解

Zookeeper入门详解

一、Zookeeper是什么？

1.背景简述

（1）Hadoop生态：hadoop生态的核心思想就是分布式、集群、云计算。所谓时势造英雄，当今时代的信息处理量，单一机器的处理能力早已不能满足需求，所以才生产了由多台机器组成的服务器集群。集群在一定程度上，可以打破传统设备的性能瓶颈，避免所有服务都在一台机器上而造成宕机。

（2）问题思考：

①程序运行需要很多配置文件，比如：数据库地址、服务地址列表、黑名单控制等，如何保证所有机器共享的配置信息一致且实时更新呢？

②如果一台机器挂了，其他机器如何知晓？如何及时接管任务呢？

③用户量激增，或减少，如何让每台机器感知并实现负载均衡呢？

④几百台机器对同一个网络文件写操作，怎么协同和保证高效运行呢？

（3）Hadoop优势：

①高可靠性：hadoop底层维护了多个数据副本，某个节点出现故障，数据也不会丢失。

②高扩展性：在集群间分配任务数据，可方便的扩展数以千计的节点。

③高效性：hadoop里面的任务是并行工作的（MapReduce思想），可以加快任务处理速度。

④高容错性：能够自动将失败的任务重新分配。

2.Zookeeper定义

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

3.Zookeeper的作用

（1）统一命名服务：IP地址不容易记住，而域名容易记。

（2）统一配置管理：将配置信息写入到一个Znode，所有节点都监听这个Znode.

（3）统一集群管理：将节点信息写到到一个Znode，实时监控所有节点状态变化。

（4）服务器动态上下线：客户端可以实时洞察服务器上下线的变化。

（5）软负载均衡：记录每台机服务器的访问数，让访问数最少的去处理最新的客户端请求。

二、Zookeeper的内部原理

1.数据结构

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

（2）每个节点都被称为Znode，每个Znode的数据大小不超过1M。

（3）Znode兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL（Access Control List，访问控制列表）、时间戳等数据结构，又像目录一样可以作为路径标识的一部分。

（4）每个Znode有3部分组成：

①stat结构体：描述该Znode的版本、权限等信息。

②data：与该Znode关联的数据

③children：该Znode下的子节点

2.节点类型

（1）PERSISTENT-持久化目录节点
客户端与ZooKeeper断开连接后，该节点依旧存在。

（2）PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与ZooKeeper断开连接后，该节点依旧存在，只是ZooKeeper给该节点名称进行顺序编号。

（3）EPHEMERAL-临时目录节点
客户端与ZooKeeper断开连接后，该节点被删除。

（4）EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与ZooKeeper断开连接后，该节点被删除，只是ZooKeeper给该节点名称进行顺序编号。

3.Stat结构体

（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数据变化号，Zookeeper利用这个数据版本了，做了一个乐观锁。

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

（9）ephemeralOwner- 如果是临时节点，这个是znode拥有者的session id（绘画ID）。如果不是临时节点则是0。注意：临时节点下不能有子节点。

（10）dataLength- znode的数据长度

（11）numChildren - znode子节点数量

4.监听器原理

（1）在代码中，一般在main()线程中创建一个Zookeeper客户端，这时就会创建两个线程，一个线程负责网络连接通信（connect），一个负责监听（listener）。

（2）需要将connect线程将注册的监听事件发送给Zookeeper。

（3）Zookeeper会把这个监听事件，添加到注册监听器列表中。

（4）Zookeeper监听到有数据或路径变化时，就会将个消息发送给listener线程。

（5）listener线程内部调用process（）方法，这是一个回调函数（提前写好，但是不调用，别人通知的时候才调动）。

5.选举机制

半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。

Zookeeper虽然在配置文件中并没有指定Leader和Follower。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。

（1）服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING；

（2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的ID比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING；

（3）服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；

（4）服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；

（5）服务器5启动，同4一样当小弟。

；

（4）服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；

（5）服务器5启动，同4一样当小弟。