zookeeper是什么？

1、是apache的一个开源框架 2、是分布式应用程序的 协调服务框架，是hdfs和hbase的重要组成部分 3、本身就是一个分布式应用框架 4、拥有类unix的文件系统的树状图的数据存储模型 5、提供了监听和通知的功能 6、提供了一组机器指令，提供了java和C语言接口

zookeeper的特点

1、是一个分布式集群框架，一个leader多个follower 2、半数以上存活就可以正常工作，所以一般适合安装在奇数台机器上 3、会把请求按照提交的先后顺序执行 4、数据一致性，所有机器上的数据都是一致的（所以具有高可靠性，高性能） 5、数据更新具有原子性，要么成功，要么失败 6、因为zookeeper只是一个协调服务框架，所以不用存储真正的数据，zookeeper一个子节点只能存储1M大小的数据 7、因为数据量比较小，所以数据同步几乎是实时的，没有延迟

zookeeper的数据模型

1、类unix的树形结构文件系统 2、每一个子节点（目录树）都被称为znode，而不是文件或目录 3、znode使用绝对路径进行唯一标识

zookeeper的工作机制

1、开机选举机制

说明： –1. zookeeper集群服务，是必须满足半数以上的节点存活才可以正常提供服务 –2. zookeeper里并没有配置谁是leader和follower，而是通过一种选举算法选择出来谁是leader。

选举流程：

目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下： 服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking(选举状态)。 服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。 服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。 服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。 服务器5启动，后面的逻辑同服务器4成为小弟。

选举机制中的几个概念

Server状态：选举状态 ​ LOOKING：竞选状态 ​ FOLLOWING:随从状态，同步leader状态，参与选票 ​ OBSERVING:观察状态，同步leader状态，不参与选票 ​ LEADER：领导者状态 –逻辑时钟: 指的是第几任选leader。比如之前已经挂掉了四个leader, 再投票选举时，就是选举第五次leader，这一任leader不是一次投票就选出来的。 –数据id： 服务器中存放的最大数据ID。值越大说明数据越新. –serverid 就是配置文件zoo.cfg中的server.x的x值。

在重新选举leader期间,逻辑时钟，数据id，服务器id所占的权重不一样。权重越大，当leader的概率就越大。

逻辑时钟(epoch)>数据id>服务器id

监听原理

1、客户端首先会 调用zookeeper的客户端API接口 2、客户端会维护两个对象，连接对象connect，监听对象listen 3、客户端会通过连接对象，告诉zookeeper服务器要监听的事件。 （1）可能是某一个znode里存储的数据变化 （2）可能是某一个znode的子znode的数量的变化 4、zookeeper会将客户端要监听的事件注册到服务中 5、如果事件发生了变化，就会通知客户端 6、客户端收到通知后，就会执行自己的 逻辑，也就是process方法中的 逻辑

写流程

Client向Zookeeper的server1上写数据，发送一个写请求如果server1不是leader,那么server1会把请求进一步转发给leader。这个leader会将写请求广播给所有server。各个Server写成功后就会通知leader。当leader收到半数以上的server写成功的通知，就说明数据写成功了。写成功后，leader会告诉server1数据写成功了。server1会进一步通知Client数据写成功了。这时就认为整个写操作成功。

zookeeper的端口

2888：集群内部通讯端口 3888：leader选举端口 2181：对客户端提供服务

zookeeper的应用场景

1、集群应用程序的配置文件的统一管理 比如 集群上的所有应用程序都连接mysql 都需要url,driver,username,pwd 那么，每个应用程序都会有自己独立的配置文件配置上述四个参数 假如有一天老板让修改mysql的密码，那么所有的应用程序都需要修改密码才能正常使用。相对来说是比较麻烦的。 但是，如果将配置文件的四个参数保存到zookeeper的某一个znode里。然后应用程序在连接mysql时，读取这个znode里的数据，就能访问mysql成功。

假如有一天老板让修改mysql的密码，只需要修改znode里的pwd的值。而所有的应用程序在mysql都还会读取znode里的数据，因此，这样的管理配置方式，非常简单，不需要为每一个应用程序单独修改配置属性

2、集群应用程序的管理节点的选举（HA高可用） 比如namenode高可用，就是两个namenode。 那么这个两个namenode如果选举出来一个来管理集群，剩下一个当备用。 比如两个namenode，分别是qianfeng01和qianfeng02, 这两个守护进程都作为客户端向zookeeper的某一个znode（/hadoop-ha）下创建一个临时子节点(active)，谁创建成功，谁就是活跃的namenode,来管理集群。没有创建成功的那个namenode监听/hadoop-ha/下的子节点的变量，如果发现消失，就立即创建active这个临时znode,就接管整个集群的工作。 3、服务节点（datanode）的动态上下线感知 /cluster/01 /cluster/02 /cluster/03

namenode只负责监听/cluster节点的子节点的数量以及名称

假如04想要上线，会先在/cluster下创建04子节点

zookeeper发现多一个节点，会通知namenode。namenode知道后，就可以将04当成工作节点为其分配任务 4、服务节点的软负载均衡 首先我们需要简单的理解分布式和集群，通俗点说：分布式就是将一个系统拆分到多个独立运行的应用中（有可能在同一台主机也有可能在不同的主机上），集群就是将单个独立的应用复制多份放在不同的主机上来减轻服务器的压力。而Zookeeper不仅仅可以作为分布式集群的服务注册调度中心（例如dubbo），也可以实现集群的负载均衡 首先我们要理解，如果是一个集群，那么他就会有多台主机。所以，他在Zookeeper中信息的存在应该是如下所示：

如上的结构，当服务调用方调用服务时，就可以根据特定的均衡负载算法来实现对服务的调用（调用前需要监听/service/serviceXXX节点，以更新列表数据） 5、分布式锁 1、首先zookeeper中我们可以创建一个/distributed_lock持久化节点 2、然后再在/distributed_lock节点下创建自己的临时顺序节点，比如：/distributed_lock/task_00000000008 3、获取所有的/distributed_lock下的所有子节点，并排序 4、判读自己创建的节点是否最小值（第一位） 5、如果是，则获取得到锁，执行自己的业务逻辑，最后删除这个临时节点。 6、如果不是最小值，则需要监听自己创建节点前一位节点的数据变化，并阻塞。 7、当前一位节点被删除时，我们需要通过递归来判断自己创建的节点是否在是最小的，如果是则执行第五步，如果不是 则执行6，（就是递归判断）

6、分布式队列 1、首先利用Zookeeper中临时顺序节点的特点 2、当生产者创建节点生产时，需要判断父节点下临时顺序子节点的个数，如果达到了上限，则阻塞等待；如果没有达到，就创建节点。 3、当消费者获取节点时，如果父节点中不存在临时顺序子节点，则阻塞等待；如果有子节点，则获取执行自己的业务，执行完毕后删除该节点即可。 4、获取时获取最小值，保证FIFO特性。