ZooKeeper 入门学习

一.入门

1.1 概述

Zookeeper 是一个开源的分布式的，为分布式框架提供协调服务的 Apache 项目

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

特点

• Zookeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群
• 集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。所以Zookeeper适合安装奇数台服务器
• 全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的
• 更新请求顺序执行，来自同一个Client的更新请求按其发送顺序依次执行，先进先出
• 数据更新原子性，一次数据更新要么成功，要么失败
• 实时性，在一定时间范围内，Client能读到最新数据

Zookeeper数据结构

ZK=文件系统+通知机制

ZooKeeper 数据模型的结构与 Unix 文件系统很类似，整体上可以看作是一棵树，每个节点称做一个 ZNode。每一个 ZNode 默认能够存储 1MB 的数据，每个 ZNode 都可以通过其路径唯一标识

ZK应用场景

提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等

统一命名服务

在分布式环境下，经常需要对应用/服务进行统一命名，便于识别
例如：IP不容易记住，而域名容易记住

统一配置管理

一般要求一个集群中，所有节点的配置信息是一致的，比如 Kafka 集群
对配置文件修改后，希望能够快速同步到各个节点上，配置管理可交由ZooKeeper实现

可将配置信息写入ZooKeeper上的一个Znode
各个客户端服务器监听这个Znode
一旦Znode中的数据被修改，ZooKeeper将通知各个客户端服务器，进行修改

统一集群管理

ZooKeeper可以实现实时监控节点状态变化

可将节点信息写入ZooKeeper上的一个ZNode，监听这个ZNode可获取它的实时状态变化

服务器节点动态上下线

这个很好理解，当ZK上注册的某台服务器下线了，它可以通知Client这台服务器下线了

软负载均衡

在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求

1.2 下载安装（集群）

在 hadoop102、hadoop103 和 hadoop104 三个节点上都部署 Zookeeper

在hadoop102上进行解压ZK的压缩包

在zk目录下，创建zkData文件夹，在该文件下创建myid，必须是这个名字，这是节点在zk集群的标识

然后输入一个2，代表这是2号节点，退出保存即可

xsync zk-3.5.7分发到其他两个节点，然后在将另外两个节点的myid修改为3和4

配置zoo.cfg文件

在conf目录下重命名mv zoo_sample.cfg zoo.cfg

①修改数据存储路径配置

dataDir=/opt/module/zookeeper-3.5.7/zkData

②增加如下配置

#######################cluster##########################
server.2=hadoop102:2888:3888
server.3=hadoop103:2888:3888
server.4=hadoop104:2888:3888

server.A=B:C:D

A 是一个数字，表示这个是第几号服务
集群模式下配置一个文件 myid，这个文件在dataDir目录下，这个文件里面有一个数据，就是 A 的值，从而判断到底是哪个 server
B 是这个服务器的地址

C 是这个服务器Follower与集群中的Leader服务器交换信息的端口

D 是万一集群中的Leader服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口

分发到其他的节点

可在bin目录下通./zkServer.sh start-foreground查看日志

启动
bin目录下./zkServer.sh start 后

通过./zkServer.sh status查看主从关系

1.3 ZK选举机制（重点）

第一次启动选举机制

假设有5台机器

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

2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的myid比自己目前投票推举的（服务器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，并更改状态为FOLLOWIN，因为leader已经产生，4会服从老大，3不会把票给4

SID：服务器ID。用来唯一标识一台zooKeeper集群中的机器，每台机器不能重复，和myid一致

事务id（zxid）ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关

Epoch：每个leader任期的代号，有新的leader产生就有epoch就递增

非第一次启动选举机制

1）当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举：

服务器初始化启动
服务器运行期间无法和Leader保持连接

2）而当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态：

①集群中本来就已经存在一个Leader
对于第一种已经存在Leader的情况，机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可

②集群中确实不存在Leader
假设ZooKeeper由5台服务器组成，SID分别为1、2、3、4、5，ZXID分别为8、8、8、7、7（意思就是zxid为8的机器比7的机器多执行了一次写操作），此时SID为3的服务器是Leader。某一时刻，3和5服务器出现故障，因此开始进行Leader选举

根据（epoch，zxid，sid）1、2、4的机器投票情况：
(1，8，1）（1，8，2）（1，7，4）

规则：

①EPOCH大的直接胜出
②EPOCH相同，事务id大的胜出
③事务id相同，服务器id大的胜出

1.4 ZK一键启动停止脚本

在bin下vim zk.sh

#!/bin/bash
case $1 in
"start"){
   for i in hadoop102 hadoop103 hadoop104
   do
      echo ---------- zookeeper $i 启动 ------------
      ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh start"
   done
}
;;
"stop"){
    for i in hadoop102 hadoop103 hadoop104
    do
       echo ---------- zookeeper $i 停止 ------------
       ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh stop"
    done
}
;;
"status"){
     for i in hadoop102 hadoop103 hadoop104
     do
        echo ---------- zookeeper $i 状态 ------------
        ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh status"
     done
}
;;
esac

一键启动：bin/zk.sh start
一键查看地址：bin/zk.sh status
一键停止：bin/zk.sh stop

二.客户端命令行操作zk

进入命令行

bin/zkCli.sh -server hadoop102:2181

2.1 znode节点数据信息

查看当前znode中所包含的内容

[zk: hadoop102:2181(CONNECTED) 0] ls /

查看当前节点详细数据

[zk: hadoop102:2181(CONNECTED) 5] ls -s /

• czxid：创建节点时的事务 zxid
  每次修改ZooKeeper 状态都会产生一个ZooKeeper事务 ID。事务ID是 ZooKeeper中所有修改总的次序。每次修改都有唯一的zxid，如果 zxid1小于 zxid2，那么zxid1在zxid2之前发生
• ctime：znode 被创建的毫秒数（从 1970 年开始）
• mzxid：znode 最后更新的事务zxid
• mtime：znode 最后修改的毫秒数（从 1970 年开始）
• pZxid：znode 最后更新的子节点zxid
• cversion：znode子节点变化号，znode 子节点修改次数
• dataversion：znode 数据变化号
• aclVersion：znode 访问控制列表的变化号
• ephemeralOwner：如果是临时节点，这个是znode拥有者的session id。如果不是临时节点则是0
• dataLength：znode的数据长度
• numChildren：znode子节点数量

2.2 节点类型

持久（Persistent）：客户端和服务器端断开连接后，创建的节点不删除
临时（Ephemeral）：客户端和服务器端断开连接后，创建的节点自己删除

• 持久化目录节点：客户端与Zookeeper断开连接后，该节点依旧存在
• 持久化顺序编号目录节点：客户端与Zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
• 临时目录节点：客户端与Zookeeper断开连接后，该节点被删除
• 临时顺序编号目录节点：客 户 端 与 Zookeeper 断 开 连 接 后， 该 节 点 被 删 除 ， 只是Zookeeper给该节点名称进行顺序编号
  

创建持久节点（无序号）

create /sanguo "diaochan"

create /sanguo/shuguo "liubei"

注意：创建节点时，要赋值，不赋值为null

创建持久节点（带序号）

create -s /xxxx

带序号和不带序号的区别，不带序号的不可以创建同名节点，如果是带序号，可以创建同名称节点，有序号区分，比如kun00001、kun00002是不同的节点

创建临时节点（不带序号）

create -e /xxxx

创建临时节点（带序号）

create -e -s /xxxx

查看节点数据

get -s /sanguo 

get -s /sanguo/shuguo

修改节点的值

set /xxx value

2.3 监听器原理（重点）

客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、节点删除、子目录节点增加删除）时，ZooKeeper 会通知客户端。监听机制保证 ZooKeeper 保存的任何的数据的任何改变都能快速的响应到监听了该节点的应用程序

原理：

1.首先要有一个main()线程

2.在main线程中创建Zookeeper客户端，这时就会创建两个线程，一个负责网络连接通信（connet），一个负责监听（listener）

3.通过connect线程将注册的监听事件发送给Zookeeper

4.在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中

5.Zookeeper监听到有数据或路径变化，就会将这个消息发送给listener线程

6.listener线程内部调用了process()方法

常见的监听：

1.监听节点数据的变化

创建监听器
节点sanguo的值是dioachan

get -w /xxx

监听该节点

然后在另一台服务器修改该节点的值，可以看到，监听节点立马有了反应

2.监听子节点增减的变化

ls -w /xxxx

另外一台服务器在/sanguo下增加一个节点，立马有了反应

删除节点

delete /xx
deleteall /xx

三.Java API 操作zk

3.1 环境准备

<dependencies>
     <dependency>
         <groupId>junit</groupId>
         <artifactId>junit</artifactId>
         <version>RELEASE</version>
     </dependency>
     <dependency>
         <groupId>org.apache.logging.log4j</groupId>
         <artifactId>log4j-core</artifactId>
         <version>2.8.2</version>
     </dependency>
     <dependency>
         <groupId>org.apache.zookeeper</groupId>
         <artifactId>zookeeper</artifactId>
         <version>3.5.7</version>
     </dependency>
    <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-framework</artifactId>
            <version>5.2.1</version>
        </dependency>
        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-recipes</artifactId>
            <version>5.2.1</version>
        </dependency>
 </dependencies>

log4j.properties

log4j.rootLogger=INFO, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - %m%n
log4j.appender.logfile=org.apache.log4j.FileAppender
log4j.appender.logfile.File=target/spring.log
log4j.appender.logfile.layout=org.apache.log4j.PatternLayout
log4j.appender.logfile.layout.ConversionPattern=%d %p [%c] - %m%n

在测试环境下，创建一个客户端

private CuratorFramework client;

    @Before
    public void testConnect(){
        ExponentialBackoffRetry retry = new ExponentialBackoffRetry(3000, 10);

        String connectString = "192.168.10.102:2181,192.168.10.103:2181,192.168.10.104:2181";


        client = CuratorFrameworkFactory.builder().connectString(connectString)
                .sessionTimeoutMs(60 * 1000)  // 会话超时时间
                .connectionTimeoutMs(15 * 1000) // 连接超时时间
                .namespace("gzhu") // 所有目录的前缀，比如我创建一个目录为 /hello  其实创建了/gzhu/hello 当然可以不加这个namespace
                .retryPolicy(retry).build(); // 重试策略

        client.start();
    }

3.2 增删改查节点

ghuz是namespace的前缀

public class CuratorTest {
    private CuratorFramework client;

    @Before
    public void testConnect() {
        ExponentialBackoffRetry retry = new ExponentialBackoffRetry(3000, 10);

        String connectString = "192.168.10.102:2181,192.168.10.103:2181,192.168.10.104:2181";


        client = CuratorFrameworkFactory.builder().connectString(connectString)
                .sessionTimeoutMs(60 * 1000)  // 会话超时时间
                .connectionTimeoutMs(15 * 1000) // 连接超时时间
                .namespace("gzhu")
                .retryPolicy(retry).build(); // 重试策略

        client.start();
    }

    // 增加节点
    @Test
    public void testCrate() throws Exception {
        // 1.基本创建，节点值也输入，默认类型持久型
        client.create().forPath("/song", "songData".getBytes(StandardCharsets.UTF_8));
        // 2.类型为持久带序号的
        client.create().withMode(CreateMode.PERSISTENT_SEQUENTIAL).forPath("/kun", "kunData".getBytes(StandardCharsets.UTF_8));
        // 3.创建多级节点 creatingParentContainersIfNeeded
        client.create().creatingParentContainersIfNeeded().forPath("/zhang/liu", "liuData".getBytes(StandardCharsets.UTF_8));
    }


    @Test // 查节点
    public void getTese() throws Exception {
        // 1.查看节点上的数据  songData
        byte[] bytes = client.getData().forPath("/song");
        System.out.println(new String(bytes));
        // 2.查看子节点 [song, zhang, kun0000000001]
        List<String> list = client.getChildren().forPath("/");
        System.out.println(list);
        // 3.节点状态
        Stat stat = new Stat();
        byte[] bytes1 = client.getData().storingStatIn(stat).forPath("/song");
        System.out.println(stat);

    }

    @Test // 改
    public void setTest() throws Exception {
        Stat stat = new Stat();
        byte[] bytes1 = client.getData().storingStatIn(stat).forPath("/song");
        int version = stat.getVersion();
        client.setData().withVersion(version).forPath("/song", "songUpdate".getBytes(StandardCharsets.UTF_8));
    }

    @Test // 删除
    public void deleteTest() throws Exception {
        // 1.删除单个节点
        client.delete().forPath("/song");
        // 2.删除多级节点
        client.delete().deletingChildrenIfNeeded().forPath("/zhang/liu");
        // 3.回调，删除后执行的函数
        client.delete().inBackground(new BackgroundCallback() {
            @Override
            public void processResult(CuratorFramework curatorFramework, CuratorEvent curatorEvent) throws Exception {
                System.out.println("我被删除了");
                System.out.println(curatorEvent);
            }
        }).forPath("/kun0000000001");
    }


    @After
    public void close() {
        if (client != null) {
            client.close();
        }
    }
}

3.3 监听watch

public class WatchTest {
    private CuratorFramework client;

    @Before
    public void testConnect() {
        ExponentialBackoffRetry retry = new ExponentialBackoffRetry(3000, 10);

        String connectString = "192.168.10.102:2181,192.168.10.103:2181,192.168.10.104:2181";


        client = CuratorFrameworkFactory.builder().connectString(connectString)
                .sessionTimeoutMs(60 * 1000)  // 会话超时时间
                .connectionTimeoutMs(15 * 1000) // 连接超时时间
                .namespace("gzhu")
                .retryPolicy(retry).build(); // 重试策略

        client.start();
    }

    // 1.监听某一个具体的节点
    @Test
    public void testNodeCache() throws Exception {
        // ①.创建NodeCache
       NodeCache nodeCache = new NodeCache(client,"/zhang");
       // ②.注册监听
       nodeCache.getListenable().addListener(new NodeCacheListener() {
           @Override
           public void nodeChanged() throws Exception {
               System.out.println("节点变了");

               byte[] bytes = nodeCache.getCurrentData().getData();
               System.out.println(new String(bytes));
           }
       });
       // ③.开启监听
       nodeCache.start();
       while (true){

       }
    }

    // 2.监听某一个节点的子节点（该节点本身不会被监听）
    @Test
    public void parentchildCache() throws Exception {
        // ①.创建PathChildrenCache对象
        PathChildrenCache cache = new PathChildrenCache(client, "/zhang",true);
        // ②.注册监听
        cache.getListenable().addListener(new PathChildrenCacheListener() {
            @Override
            public void childEvent(CuratorFramework curatorFramework, PathChildrenCacheEvent event) throws Exception {
                System.out.println("子节点变化了");
                System.out.println(event);
                // 获取变的类型
                PathChildrenCacheEvent.Type type = event.getType();
                // 如果是update，则输出改变后的值
                if(type.equals(PathChildrenCacheEvent.Type.CHILD_UPDATED)){
                    System.out.println("修改了子节点");
                    byte[] bytes = event.getData().getData();
                    System.out.println(new String(bytes));
                }
            }
        });

        // ③.开启监听
        cache.start();

        while(true){

        }
    }

    // 3.TreeNode  监听自己和孩子
    @Test
    public void treeTest() throws Exception {
        TreeCache treeCache = new TreeCache(client,"/zhang");

        treeCache.getListenable().addListener(new TreeCacheListener() {
            @Override
            public void childEvent(CuratorFramework curatorFramework, TreeCacheEvent treeCacheEvent) throws Exception {
                System.out.println("节点变化了");
                TreeCacheEvent.Type type = treeCacheEvent.getType();
                System.out.println(treeCacheEvent);

                if(type.equals(TreeCacheEvent.Type.NODE_UPDATED)){
                    System.out.println("节点变了");
                    System.out.println(treeCacheEvent);
                }
            }
        });

        // ③.开启监听
        treeCache.start();

        while (true){

        }
    }



    @After
    public void close() {
        if (client != null) {
            client.close();
        }
    }
}

3.4 写数据原理

如果客户端是和leader建立的连接

1.leader首先会写数据
2.leader会通知一个其余的节点follower写数据
3.这个foll写完后会返回一个ack
4.这时候leader已经知道这个集群上有超过半数的节点有了数据，那么会返回给客户端写数据成功
5.再让其他节点写数据，同样的，成功后返回ack

如果是和follower建立的连接
这个follower会通知leader，让leader先写，leader写完后再通知其他leader，其他leader写完后通知leader，leader统计写成功的节点过半数后，会通知那个与client建立连接的follower告知客户端写数据成功

3.5 ZK分布式锁（重点）

跨机器的进程之间的数据同步问题，获得分布式锁的才会进行数据操作

zk分布式锁的实现

核心思想：当客户端要获得锁时，则创建节点，使用完锁，则删除节点

1.当多个客户端想获取lock节点的锁时，那么它会在lock节点下创建临时顺序节点

2.然后获取lock节点下的所有子节点，客户端获得子节点后，如果发现自己创建的节点序号最小，那么就会获得锁，使用完成后，删除该节点

3.如果发现自己的节点不是子节点中最小的，那么不会获得锁，此时客户端会找到比自己小的节点，同时对其监听，监听删除事件

4.一旦比自己小的那个节点被删除，则客户端的Watcher会收到相应的通知，此时再次判断自己序号是不是最小的，如果是，就会获得锁，如果不是再去监听比自己小的节点

为什么是临时？

如果不是临时，正在使用锁的主机突然挂了，那么锁就被永久占用了，但是使用临时的节点，主机挂了，对应的子节点也就没了，释放了锁

为什么是顺序？
因为需要最小的节点序号，所以就要排序

案例：分布式可重入排他锁实现

主要使用Curator框架中的InterProcessMutex（进程互斥）

public class Lock {
    private static CuratorFramework client;

    public static CuratorFramework getClient() {
        ExponentialBackoffRetry retry = new ExponentialBackoffRetry(3000, 10);

        String connectString = "192.168.10.102:2181,192.168.10.103:2181,192.168.10.104:2181";


        client = CuratorFrameworkFactory.builder().connectString(connectString)
                .sessionTimeoutMs(2000)  // 会话超时时间
                .connectionTimeoutMs(2000) // 连接超时时间
                .retryPolicy(retry).build(); // 重试策略

        client.start();

        return client;
    }

    public static void main(String[] args) {
        InterProcessMutex lock1 = new InterProcessMutex(getClient(),"/gzhu/song");

        InterProcessMutex lock2 = new InterProcessMutex(getClient(),"/gzhu/song");

        new Thread(()->{
            try {
                lock1.acquire();
                System.out.println("线程1获得锁");

                lock1.acquire();
                System.out.println("线程1再次获得锁");

                Thread.sleep(5000);

                lock1.release();
                System.out.println("线程1 释放锁");

                lock1.release();
                System.out.println("线程1 再次释放锁");
            } catch (Exception e) {
                e.printStackTrace();
            }

        }).start();

        new Thread(()->{
            try {
                lock2.acquire();
                System.out.println("线程2获得锁");

                lock2.acquire();
                System.out.println("线程2再次获得锁");

                Thread.sleep(5000);

                lock2.release();
                System.out.println("线程2 释放锁");

                lock2.release();
                System.out.println("线程2 再次释放锁");
            } catch (Exception e) {
                e.printStackTrace();
            }

        }).start();
    }
}