一、Zookeeper简单介绍
ZooKeeper是分布式、开源的分布式APP应用协调服务，是谷歌Chubby的开源实现，是Hadoop和Hbase的重要组件。 它是一个为分布式APP应用程序提供一致服务的软件，提供配置维护、域名服务、分布式同步和组服务等功能。
二、Zookeeper的工作机制
Zookeeper从设计模式的角度理解，是一个基于观察者模式的分布式服务管理框架，负责存储和管理重要的数据，Zookeeper接受观察者的注册，暂时
结构如下图所示。
简单地说，Zookeeper=文件系统的通知机制。
被观察的数据状态发生变化
【1】Zookeeper存在由通知酷芹菜(Follower )组成的集群。
【2】如果集群中存在半数以上(服务器生存数量必须在一半以上，一半以下不行)的节点，则正常运行。
【3】数据匹配：各服务器保存同一数据的副本，客户端连接任何服务器获取的数据相同。
【4】更新请求按照发送顺序依次执行。
【5】数据更新原子性原则是更新一次成功或失败。
【6】实时性，客户端可以读取最新的数据。
三、Zookeeper特点
【1】半数机制：如果集群中有半数以上的计算机生存，集群将正常运行，因此Zookeeper 领导者（Leader）和多个
【2】ZooKeeper在配置中没有指定主节点和从属节点，但ZooKeeper在工作中一个节点变为Leader，其他为Follower。 Leader是由内部选举机制暂时产生的。
以下方案模拟内部选举机制。 假设有5台服务器。 每个ID都是1到5。 ID首先从1开始，它进行投票，选择一台服务器作为Leader。 但是，由于ID为1的服务器将此投票给自己，所以ID为1的票数为1。 但是，Leader只在票数超过总数的一半时发生。 (这里总数为5台，如果满足度在3以上，就会发生Leader。 因此，轮到ID为2的服务器进行投票，当然ID为2的服务器会投票给自己，所以ID为2的服务器的票数为1。 此时，ID为1的服务器将自己的票数投票给ID为2的服务器。 因此，此时，ID为2的服务器的票数为2，当然票数不满足总数的一半以上。 这个场景的票数必须是3才能成为领导者。 轮到ID为3的服务器开始投票。 当然，那个也投自己的票。 然后，ID为1和ID为2的服务器也将自己的票数投给ID为3的服务器。 因此，ID为3的服务器的票数为3，票数大于总数的一半，ID为3的服务器为Leader，ID为4和ID为5，这也是无奈之举，直接被ID为3的服务器引领。
图解如下。四、Zookeeper的选举机制
【1】永久：客户端和服务端断开连接后，创建的节点不会被删除。
、持久化目录节点：客户端与服务端断开连接后，该节点仍然存在。
、持久序列号目录节点(客户端与服务端断开连接后，该节点仍然存在，只需对该节点名称进行序列号。
【2】短时间：客户端和服务端断开连接后，创建的节点自己删除。
、临时目录节点：客户端与服务端断开连接后，该节点将被删除。
、临时序列号目录节点(客户端与服务端断开连接后，该节点将被删除，只需对该节点名称进行序列号即可。
适合安装奇数台服务器。
【1】首先需要main ()线程。
(【2】main ) )在线程中创建Zookeeper客户端。 此时，您有机会创建两个线程。 一个负责网络连接通信(Connect )，另一个负责监听。
【3】将登录的拦截事件通过连接线程发送到Zookeeper集群。
【4】添加Zookeeper注册监听程序列表中注册的监听事件。
【5】Zookeeper拦截五、节点类型发生变化时，会向监听器线程发送消息。
【6】监听器线程调用内部process ()方法处理业务。
图解如下。六、监听器原理
【1】客户端将数据写在Zookeeper中的Server1上，发送一个server http://www.Sina.com /。
【2】如果服务器1不是Leader，服务器1将收到的请求发送到Leader，Leader将收到的写入请求数据或者路径发送到各个服务器，例如Server1
【3】Leader在大部分服务器收到数据写入成功的响应时(大部分情况下是指服务器总数的一半以上)，认为写入数据的操作成功，Leader向Server1写入数据
【4】Server1进一步通知客户机写入数据成功。 这被认为是整个写入数据操作成功了。
图解如下。七、写数据流程
【1】数据发布和订阅。
【2】负载均衡(软负载均衡)。
【3】命名服务。
【4】分布式通知/调整。
【5】集群管理和Leader选举。
【6】分散锁。
【7】分布式队列。