ZooKeeper 是一个开源的分布式协调服务，由雅虎创建，是 Google Chubby 的开源实现。
分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协
调/通知、集群管理、Master 选举、配置维护，名字服务、分布式同步、分布式锁和分布式队列
等功能。ZooKeeper 是一个高可用的分布式数据管理与协调框架。基于对ZAB算法的实现，该框架
能够很好地保证分布式环境中数据的一致性。也是基于这样的特性，使得 ZooKeeper 成为了
解决分布式一致性问题的利器。

1. 使用场景

1. 数据发布与订阅（配置中心）

ZooKeeper 采用的是推拉相结合的方式： 客户端想服务端注册自己需要关注的节点，一旦该节点的数据发生变更，那么服务端就会向相应的客户端发送Watcher事件通知，客户端接收到这个消息通知后，需要主动到服务端获取最新的数据

2. 命名服务

通过在ZooKeepr里
创建顺序节点，能够很容易创建一个全局唯一的路径，这个路径就可以作为一个名字。ZooKeeper 的命名服务即生成全局唯一的ID。

3. 分布式协调服务/通知

Watcher 注册与异步通知机制

4. Master选举

针对 Master 选举的需求，通常情况下，我们可以选择常见的关系型数据库中的主键特性来实现：希望成为 Master 的机器都向数据库中插入一条相同主键ID的记录，数据库会帮我们进行主键冲突检查，也就是说，只有一台机器能插入成功——那么，我们就认为向数据库中成功插入数据的客户端机器成为Master。依靠关系型数据库的主键特性确实能够很好地保证在集群中选举出唯一的一个Master。但是，如果当前选举出的 Master 挂了，那么该如何处理？谁来告诉我 Master 挂了呢？显然，关系型数据库无法通知我们这个事件。但是，ZooKeeper 可以做到！利用 ZooKeepr 的强一致性，能够很好地保证在分布式高并发情况下节点的创建一定能够保证全局唯一性，即 ZooKeeper 将会保证客户端无法创建一个已经存在的 数据单元节点。也就是说，如果同时有多个客户端请求创建同一个临时节点，那么最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很容易地在分布式环境中进行 Master 选举了。成功创建该节点的客户端所在的机器就成为了 Master。同时，其他没有成功创建该节点的客户端，都会在该节点上注册一个子节点变更的 Watcher，用于监控当前 Master 机器是否存活，一旦发现当前的Master挂了，那么其他客户端将会重新进行 Master 选举。这样就实现了 Master 的动态选举。

2. 集群角色

Leader(1个)
Follower
Observer

1.ZooKeeper 集群的所有机器通过一个 Leader 选举过程来选定一台被称为『Leader』
的机器，Leader服务器为客户端提供读和写服务。

2.Follower 和 Observer 都能提供读服务，不能提供写服务。两者唯一的区别在于，
Observer机器不参与 Leader 选举过程，也不参与写操作的『过半写成功』策略，因
此 Observer 可以在不影响写性能的情况下提升集群的读性能。

3. session

ZooKeeper 对外的服务端口默认是2181，客户端启动时，首先会与服务器建立一个TCP
连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够通
过心跳检测和服务器保持有效的会话，也能够向 ZooKeeper 服务器发送请求并接受响应，同
时还能通过该连接接收来自服务器的 Watch 事件通知。

Session 的 SessionTimeout 值用来设置一个客户端会话的超时时间。当由于服务器
压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在
SessionTimeout 规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话
仍然有效。

4. 树形结构

zookeeper的节点分两类：持久节点和临时节点

• 持久节点：
  所谓持久节点是指一旦这个 树形结构上被创建了，除非主动进行对树节点的移除操
  作，否则这个 节点将一直保存在 ZooKeeper 上。

• 临时节点：
  临时节点的生命周期跟客户端会话绑定，一旦客户端会话失效，那么这个客户端创
  建的所有临时节点都会被移除。

5. 状态信息

每个 节点除了存储数据内容之外，还存储了 节点本身的一些状态信息。用 get 命令可以
同时获得某个 节点的内容和状态信息。
在 ZooKeeper 中，version 属性是用来实现乐观锁机制中的『写入校验』的（保证分布
式数据原子性操作）。

6. 事务操作

在ZooKeeper中，能改变ZooKeeper服务器状态的操作称为事务操作。一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作。对应每一个事务请求，ZooKeeper都会为其分配一个全局唯一的事务ID，用 ZXID 表示，通常是一个64位的数字。每一个 ZXID对应一次更新操作，从这些 ZXID 中可以间接地识别出 ZooKeeper 处理这些事务操作请求的全局顺序

7. 事件监听

是 ZooKeeper 中一个很重要的特性。ZooKeeper允许用户在指定节点上注册一些 Watcher，
并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去。该
机制是 ZooKeeper 实现分布式协调服务的重要特性。

8.命令和java api

bin/zkCli.sh -server localhost:2181
ls /  获取节点内容
ls2 / 获取节点信息
get / 获取节点内容
help

zookeeper-server status

apache 封装zookeeper

   <!--zookeeper-->
        <dependency>
            <groupId>org.apache.zookeeper</groupId>
            <artifactId>zookeeper</artifactId>
            <version>3.4.6</version>
        </dependency>
        <!--zookeeper封装API-->
        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-framework</artifactId>
            <version>2.7.1</version>
        </dependency>


/**
 * 使用zookeeper来做spider的节点发现服务
 *
 * 所以该task是独立于Spider的进程
 * 要想去监控爬虫，则需要不断的监听/zk的目录变化
 *
 * 实际上要想让zk监听到有新的spider服务增加进来或者有新的spider服务丢失，则需要我们去监控zk中对应的目录的变化
 * 所以我们这里需要zk的监听器Watcher
 *      专门监听zk的目录
 * 使用CuratorFramework向zk中进行节点的注册（向zk中增删节点），用watcher监听该目录的变化
 *
 * 得需要完成实现监听器，在监听器中完成对应的操作的变化
 */
public class SpiderMonitorTask implements Watcher {

    private List<String> previousNodes;
    private CuratorFramework curator;
    private Logger logger = LoggerFactory.getLogger(SpiderMonitorTask.class);

    /**
     * 因为要监控，所以我们得要知道监控的目录，要拿到监控目录下面的东西
     * 以便我们当节点发生变化之后，知道是由谁引起的变化
     * 所以要获取初始的节点状态
     */
    public SpiderMonitorTask() {
        String zkStr = "uplooking01:2181,uplooking02:2181,uplooking03:2181";
        int baseSleepTimeMs = 1000;
        int maxRetries = 3;
        RetryPolicy retryPolicy = new ExponentialBackoffRetry(baseSleepTimeMs, maxRetries);
        curator = CuratorFrameworkFactory.newClient(zkStr, retryPolicy);
        curator.start();
        try {
            previousNodes = curator.getChildren().usingWatcher(this).forPath("/ispider");
        } catch (Exception e) {
            e.printStackTrace();
        }

    }

    /**
     * 这个方法，当监控的zk对应的目录一旦有变动，就会被调用
     * 得到当前最新的节点状态，将最新的节点状态和初始或者上一次的节点状态作比较，那我们就知道了是由谁引起的节点变化
     * @param event
     */
    @Override
    public void process(WatchedEvent event) {
        try {
            List<String> currentNodes = curator.getChildren().usingWatcher(this).forPath("/ispider");
//            HashSet<String> previousNodesSet = new HashSet<>(previousNodes);
            if(currentNodes.size() > previousNodes.size()) { // 最新的节点服务，超过之前的节点服务个数，有新的节点增加进来
                for(String node : currentNodes) {
                    if(!previousNodes.contains(node)) {
                        // 当前节点就是新增节点
                        logger.info("----有新的爬虫节点{}新增进来", node);
                    }
                }
            } else if(currentNodes.size() < previousNodes.size()) {  // 有节点挂了    发送告警邮件或者短信
                for(String node : previousNodes) {
                    if(!currentNodes.contains(node)) {
                        // 当前节点挂掉了 得需要发邮件
                        logger.info("----有爬虫节点{}挂掉了", node);
                        MailUtil.sendMail("有爬虫节点挂掉了，请人工查看爬虫节点的情况，节点信息为：", node);
                    }
                }
            } // 挂掉和新增的数目一模一样，上面是不包括这种情况的，有兴趣的朋友可以直接实现包括这种特殊情况的监控
            previousNodes = currentNodes;   // 更新上一次的节点列表，成为最新的节点列表
        } catch (Exception e) {
            e.printStackTrace();
        }
        // 在原生的API需要再做一次监控，因为每一次监控只会生效一次，所以当上面发现变化后，需要再监听一次，这样下一次才能监听到
        // 但是在使用curator的API时则不需要这样做
    }

    public static void main(String[] args) {
        new SpiderMonitorTask().start();
    }

    /**
     * 因为我们的监听服务不能停止，所以必须持续不断的运行，所以死循环
     */
    public void start() {
        while (true) {

        }
    }

}

概念参考 https://blog.csdn.net/weijifeng_/article/details/79775738
安装参考 https://www.cnblogs.com/LUA123/p/7222216.html