zookeeper笔记

概念

概述

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

zookeeper工作机制

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

zookeeper主要是文件系统和通知机制

• 文件系统主要是用来存储数据

• 通知机制主要是服务器或者客户端进行通知，并且监督

基于观察者模式设计的分布式服务管理框架，开源的分布式框架

特点

• 一个leader，多个follower的集群

• 集群只要有半数以上包括半数就可正常服务，一般安装奇数台服务器

• 全局数据一致，每个服务器都保存同样的数据，实时更新

• 更新的请求顺序保持顺序（来自同一个服务器）

• 数据更新的原子性，数据要么成功要么失败

• 数据实时更新性很快

主要的集群步骤为

1. 服务端启动时去注册信息（创建都是临时节点）

2. 获取到当前在线服务器列表，并且注册监听

3. 服务器节点下线

4. 服务器节点上下线事件通知

5. process(){重新再去获取服务器列表，并注册监听}

数据结构

与 Unix 文件系统很类似，可看成树形结构，每个节点称做一个 ZNode。每一个 ZNode 默认能够存储1MB 的数据。也就是只能存储小数据

应用场景

1. 统一命名服务（域名服务）

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

1. 统一配置管理（一个集群中的所有配置都一致，且也要实时更新同步） 将配置信息写入ZooKeeper上的一个Znode，各个客户端服务器监听这个Znode。一旦Znode中的数据被修改，ZooKeeper将通知各个客户端服务器

1. 统一集群管理（掌握实时状态） 将节点信息写入ZooKeeper上的一个ZNode。监听ZNode获取实时状态变化

1. 服务器节点动态上下线

1. 软负载均衡（根据每个节点的访问数，让访问数最少的服务器处理最新的数据需求）

安装

http://zookeeper.apache.org

bin目录 框架启动停止，客户端和服务端的 conf 配置文件信息 docs文档 lib 配置文档的依赖

具体安装的文档可查看我这篇文章 Zookeeper的安装配置详解（window / linux） 如果中途出现问题，可参考这篇文章

1. zookeeper启动时出现Starting zookeeper … FAILED TO START超全诠释的解决方案

2. zookeeper启动过程出现zkServer.sh: command not found解决方法

安装前准备

（1）安装 JDK （2）拷贝 apache-zookeeper-3.5.7-bin.tar.gz 安装包到 Linux 系统下 （3）解压到指定目录

tar -zxvf apache-zookeeper-3.5.7-bin.tar.gz -C /opt/module/

（4）修改名称

mv apache-zookeeper-3.5.7-bin zookeeper-3.5.7

配置修改

（1）将/opt/module/zookeeper-3.5.7/conf 这个路径下的 zoo_sample.cfg 修改为 zoo.cfg；

mv zoo_sample.cfg zoo.cfg

（2）打开 zoo.cfg 文件，修改 dataDir 路径：

vim zoo.cfg
修改如下内容：
dataDir=/opt/module/zookeeper-3.5.7/zkData

（3）在/opt/module/zookeeper-3.5.7/这个目录上创建 zkData 文件夹

mkdir zkData

操作zookeeper

（1）启动 Zookeeper

bin/zkServer.sh start

（2）查看进程是否启动

jps
显示：
4020 Jps
4001 QuorumPeerMain

（3）查看状态

bin/zkServer.sh status
显示：
ZooKeeper JMX enabled by default
Using config: /opt/module/zookeeper-3.5.7/bin/../conf/zoo.cfg
Mode: standalone

（4）启动客户端

bin/zkCli.sh

（5）退出客户端：

quit

（6）停止 Zookeeper

bin/zkServer.sh stop

配置文件解读

配置文件的5大参数

• tickTime = 2000发送时间

• initLimit = 10初始化通信的时间，最多不能超过的时间，超过的话，通信失败

• syncLimit = 5建立好连接后，下次的通信时间如果超过，通信失败

• dataDir保存zookeeper的数据，默认是temp会被系统定期清除

• clientPort = 2181客户端的连接端口，一般不需要修改

zookeeper集群操作

集群安装

比如三个节点部署zookeeper，那么需要3台服务器

安装步骤

1. 解压安装zookeeper

2. 配置服务器编号

   1. 在/opt/zookeeper-3.5.7/这个目录下创建 zkData

   2. 在/opt/zookeeper-3.5.7/zkData 目录下创建一个 myid 的文件

      在文件中添加与 server 对应的编号（注意：上下不要有空行，左右不要有空格）

   2

3. 拷贝配置好的 zookeeper 到其他机器上，并分别在 hadoop103、hadoop104 上修改 myid 文件中内容为 3、4

xsync zookeeper-3.5.7

1. 修改zoo.cfg文件

   1. 重命名/opt/module/zookeeper-3.5.7/conf 这个目录下的 zoo_sample.cfg 为 zoo.cfg

   mv zoo_sample.cfg zoo.cfg

   1. 修改数据存储路径配置，并在最后面添加如下配置

   dataDir=/opt/module/zookeeper-3.5.7/zkData
   
   server.2=hadoop102:2888:3888
   server.3=hadoop103:2888:3888
   server.4=hadoop104:2888:3888

   1. 同步zoo.cfg 配置文件

   xsync zoo.cfg

2. 集群操作

   1. 分别启动zookeeper

   bin/zkServer.sh start

   1. 查看状态

   bin/zkServer.sh status

集群成功启动后的效果：

 

 

配置文件解读

当前主要配置编号的参数是server.A=B:C:D

• A标识第几台服务器

• B标识服务器地址

• C标识服务器 Follower 与集群中的 Leader 服务器交换信息的端口

• D主要是选举，如果Leader 服务器挂了。这个端口就是用来执行选举时服务器相互通信的端口，通过这个端口进行重新选举leader

配置文件以及服务器编号设置好后即可启动

选举机制

以下主要是面试的重点 区分好第一次启动与非第一次启动的步骤 epoch在没有leader的时候，主要是逻辑时钟（与数字电路中的逻辑时钟相同）

非第一次启动，在没有leader的时候 其判断依据是：epoch任职期>事务id>服务器sid

集群启动停止脚本

如果服务器太多，需要一台一台启动和关闭会比较麻烦

脚本文件大致如下： 建立一个后缀名为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

修改该文件的权限：

通过chmod 777 zk.sh，之后在一个服务器中执行./zk.sh start就可启动脚本文件，其它命令也如此

查看其进程号： 可以通过jpsall 就可查看所有服务器的进程

客户端命令

常用命令

命令	功能
help	显示所有操作命令
ls path	使用 ls 命令来查看当前 znode 的子节点 [可监听] ，-w 监听子节点变化，-s 附加次级信息
create	普通创建
-s	含有序列
-e	临时（重启或者超时消失）
get path	获得节点的值 [可监听] ，-w 监听节点内容变化
-s	附加次级信息
set	设置节点的具体值
stat	查看节点状态
delete	删除节点
deleteall	递归删除节点

通过ls / 查看当前znode包含的信息

[zk: localhost:2181(CONNECTED) 0] ls /
[zookeeper]

123

查看当前数据节点详细信息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 子节点数量

启动客户端的时候默认是本地的localhost

如果要启动专门的服务器 启动客户端的时候后缀要加上./zkCli.sh -server 服务器名:2181 博主的启动方式也为./zkCli.sh -server hadoop102:2181

节点类型

节点类型分为（两两进行组合）

• 持久/短暂

• 有序号/无序号

1. 创建永久节点不带序号的

1. 创建永久节点带序号的（-s）

   通过加上-s参数，即便创建两个一样的，-s 自动会加上序号辨别两者不同 退出客户端之后，这些节点并没有被清除

2. 创建临时节点 加上参数 -e，如果要带上节点序号则加上-s，如果退出客户端，这些短暂节点将会被清除

如果修改节点的值，通过set key value即可

监听器原理

注册一次监听一次 主要有节点值的变化还有节点路径的变化 在一个服务器中通过修改其值或者路径 在另一个服务器中进行监听，通过get -w 节点值进行监听节点值的变化 如果是路径的变化，在另一个服务器中进行ls -w 路径进行监听

如果有很多个节点 不能直接使用删除delete 需要删除deleteall

查看节点的状态信息 stat

客户端监听操作

（1）节点的值变化监听

1. 在 hadoop104 主机上注册监听/sanguo 节点数据变化

[zk: localhost:2181(CONNECTED) 26] get -w /sanguo

1. 在 hadoop103 主机上修改/sanguo 节点的数据

[zk: localhost:2181(CONNECTED) 1] set /sanguo "xisi"

1. 观察 hadoop104 主机收到数据变化的监听

WATCHER::
WatchedEvent state:SyncConnected type:NodeDataChanged path:/sanguo

注意：在hadoop103再多次修改/sanguo的值，hadoop104上不会再收到监听。因为注册一次，只能监听一次。想再次监听，需要再次注册。

（2）节点的子节点变化监听（路径变化）

1. 在 hadoop104 主机上注册监听/sanguo 节点的子节点变化

[zk: localhost:2181(CONNECTED) 1] ls -w /sanguo
[shuguo, weiguo]

1. 在 hadoop103 主机/sanguo 节点上创建子节点

[zk: localhost:2181(CONNECTED) 2] create /sanguo/jin "simayi"
Created /sanguo/jin

1. 观察 hadoop104 主机收到子节点变化的监听

WATCHER::
WatchedEvent state:SyncConnected type:NodeChildrenChanged path:/sanguo

注意：节点的路径变化，也是注册一次，生效一次。想多次生效，就需要多次注册。

（3）节点删除与查看

1. 删除节点

[zk: localhost:2181(CONNECTED) 4] delete /sanguo/jin

1. 递归删除节点

[zk: localhost:2181(CONNECTED) 15] deleteall /sanguo/shuguo

1. 查看节点状态

[zk: localhost:2181(CONNECTED) 17] stat /sanguo
cZxid = 0x100000003
ctime = Wed Aug 29 00:03:23 CST 2018
mZxid = 0x100000011
mtime = Wed Aug 29 00:21:23 CST 2018
pZxid = 0x100000014
cversion = 9
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 4
numChildren = 1

客户端监听代码操作

1. 创建一个工程

2. 在pom文件中配好依赖文件

<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>
</dependencies>

1. 需要在项目的 src/main/resources 目录下，新建一个文件，命名为“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

1. 在客户端中生成具体代码

初始化并且负责监听节点，主要通过设置连接的服务器，以及超时参数，监听匿名函数new Watcher() {}

 // 注意：逗号左右不能有空格
    private String connectString = "hadoop102:2181,hadoop103:2181,hadoop104:2181";
    private int sessionTimeout = 2000;
    private ZooKeeper zkClient;

    @Before
    public void init() throws IOException {

        zkClient = new ZooKeeper(connectString, sessionTimeout, new Watcher() {
            @Override
            public void process(WatchedEvent watchedEvent) {
        });
    }

    }

（1）创建一个新的节点 创建的节点必须在初始化节点这些之后，通过注解，在之前中加入before

• 第一个参数是路径

• 第二个参数是数据，要求是字节类型，需要用getBytes()

• 第三个参数是权限，Ids.OPEN_ACL_UNSAFE允许所有人进行访问

• 第四个参数是创建节点的类型

 @Test
    public void create() throws KeeperException, InterruptedException {
        String nodeCreated = zkClient.create("/manongyanjiuseng ", "123".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
123

（2）获取子节点并且监听其变化 获取子节点通过getChildren()，关于获取子节点一共有两种 获取子节点第一个是路径，第二个是监听函数，如果使用true，则会使用初始化函数中重写的监听函数

@Test
public void getChildren() throws KeeperException, InterruptedException {
    List<String> children = zkClient.getChildren("/", true);

    for (String child : children) {
        System.out.println(child);
    }

    // 延时
    Thread.sleep(Long.MAX_VALUE);
}

注册一次生效一次，还需要再进行注册，如果希望通过延迟函数延迟程序的结束，继续放在监听函数中就可以注册一次生效一次，之后再注册就可以实时监听节点的增减

zkClient = new ZooKeeper(connectString, sessionTimeout, new Watcher() {
    @Override
    public void process(WatchedEvent watchedEvent) {

        System.out.println("-------------------------------");
        List<String> children = null;
        try {
            children = zkClient.getChildren("/", true);

            for (String child : children) {
                System.out.println(child);
            }

            System.out.println("-------------------------------");
        } catch (KeeperException e) {
            e.printStackTrace();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
});

[zk: localhost:2181(CONNECTED) 12] create /atguigu1 "jishu2"
Created /atguigu1
[zk: localhost:2181(CONNECTED) 13] delete /atguigu1
打印结果：
NodeChildrenChanged--/
atguigu1
zookeeper
atguigu
NodeChildrenChanged--/
zookeeper
atguigu

（3）判断Znode节点是否存在 exits函数，返回的是状态信息，通过状态信息判断是否还在 第一个参数是路径 第二个参数是是否监听

@Test
public void exist() throws KeeperException, InterruptedException {

    Stat stat = zkClient.exists("/manongyanjiuseng", false);

    System.out.println(stat==null? "not exist " : "exist");
}

客户端向服务端写数据流程

1. 发送给leader的时候 通俗解释：客户端给服务器的leader发送写请求，写完数据后给手下发送写请求，手下写完发送给leader，超过半票以上都写了则发回给客户端。之后leader在给其他手下让他们写，写完在发数据给leader

2. 发送给follower的时候 通俗解释：客户端给服务器的follower发送写的请求，follower给leader发送写的请求，写完后，给手下发送写的请求，手下写完后给leader发送确认，超过半票，leader确认后，发给确认给follower，然后follower响应客户端请求，最后leader再发送写请求给其他手下

服务器动态上下线监听

1. 服务器上线的时候其实就是服务器启动时去注册信息（创建的都是临时节点）

2. 客户端获取到当前在线的服务器列表后

3. 服务器节点下线后给集群管理

4. 集群管理服务器节点的下件时间通知给客户端

5. 客户端通过获取服务器列表新选择服务器

6. 服务器代码

• 获取zookeeper集群的连接，通过zookeeper的构造函数ZooKeeper(connectString, sessionTimeout, new Watcher(){})

• 将其服务注册到zookeeper集群中，具体通过create的函数，通过获取每个服务器名字、其值、权限、节点类型

• 执行该函数通过延迟函数

public class DistributeServer {

    private String connectString = "hadoop102:2181,hadoop103:2181,hadoop104:2181";
    private int sessionTimeout = 2000;
    private ZooKeeper zk;

    public static void main(String[] args) throws IOException, KeeperException, InterruptedException {

        DistributeServer server = new DistributeServer();
        // 1 获取zk连接
        server.getConnect();

        // 2 注册服务器到zk集群
        server.regist(args[0]);

        // 3 启动业务逻辑（睡觉）
        server.business();

    }

    private void business() throws InterruptedException {
        Thread.sleep(Long.MAX_VALUE);
    }

    private void regist(String hostname) throws KeeperException, InterruptedException {
        String create = zk.create("/servers/"+hostname, hostname.getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);

        System.out.println(hostname +" is online") ;
    }

    private void getConnect() throws IOException {

        zk = new ZooKeeper(connectString, sessionTimeout, new Watcher() {
            @Override
            public void process(WatchedEvent watchedEvent) {

            }
        });
    }
}

1. 客户端代码

• 获取zookeeper集群的连接，通过zookeeper的构造函数ZooKeeper(connectString, sessionTimeout, new Watcher(){})

• 客户端通过监听每个节点，具体监听通过getChildren函数，获取其节点位置，以及是否使用初始化的监听函数，true为使用。获取到的都是以列表存在，输出的时候通过遍历实现，输出的还是一些数组格式。将这些数组都封装到一个列表中，最后统一输出列表即可

• 执行该函数通过延迟函数

因为注册的时候记录一次，所以在初始化的时候，将其注册放在初始化内部getServerList();

public class DistributeClient {

    private String connectString = "hadoop102:2181,hadoop103:2181,hadoop104:2181";
    private int sessionTimeout = 2000;
    private ZooKeeper zk;

    public static void main(String[] args) throws IOException, KeeperException, InterruptedException {
        DistributeClient client = new DistributeClient();

        // 1 获取zk连接
        client.getConnect();

        // 2 监听/servers下面子节点的增加和删除
        client.getServerList();

        // 3 业务逻辑（睡觉）
        client.business();

    }

    private void business() throws InterruptedException {
        Thread.sleep(Long.MAX_VALUE);
    }

    private void getServerList() throws KeeperException, InterruptedException {
        List<String> children = zk.getChildren("/servers", true);

        ArrayList<String> servers = new ArrayList<>();

        for (String child : children) {

            byte[] data = zk.getData("/servers/" + child, false, null);

            servers.add(new String(data));
        }

        // 打印
        System.out.println(servers);
    }

    private void getConnect() throws IOException {
        zk = new ZooKeeper(connectString, sessionTimeout, new Watcher() {
            @Override
            public void process(WatchedEvent watchedEvent) {

                try {
                    getServerList();
                } catch (KeeperException e) {
                    e.printStackTrace();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        });
    }
}

具体测试的逻辑：

1. 启动客户端，通过虚拟机进行create -e -s 节点信息（临时带序号的节点），或者delete进行更新

2. 启动服务器，判定节点是否正常上下线

分布式锁

分布式锁：

比如说"进程 1"在使用该资源的时候，会先去获得锁，"进程 1"获得锁以后会对该资源保持独占，这样其他进程就无法访问该资源，"进程 1"用完该资源以后就将锁释放掉，让其他进程来获得锁，那么通过这个锁机制，我们就能保证了分布式系统中多个进程能够有序的访问该临界资源。那么我们把这个分布式环境下的这个锁叫作分布式锁。

原生zookeeper分布式锁

实现原理：

创建节点，判断是否是最小的节点，如果不是最小的节点，需要监听前一个的节点

健壮性可以通过CountDownLatch类

监听函数 如果集群状态是连接，则释放connectlatch 如果集群类型是删除，且前一个节点的位置等于该节点的文职，则释放该节点

判断节点是否存在不用一直监听，获取节点信息要一直监听getData

public class DistributedLock {
​
    private final String connectString = "hadoop102:2181,hadoop103:2181,hadoop104:2181";
    private final int sessionTimeout = 2000;
    private final ZooKeeper zk;
​
    private CountDownLatch connectLatch = new CountDownLatch(1);
    private CountDownLatch waitLatch = new CountDownLatch(1);
​
    private String waitPath;
    private String currentMode;
​
    public DistributedLock() throws IOException, InterruptedException, KeeperException {
​
        // 获取连接
        zk = new ZooKeeper(connectString, sessionTimeout, new Watcher() {
            @Override
            public void process(WatchedEvent watchedEvent) {
                // connectLatch  如果连接上zk  可以释放
                if (watchedEvent.getState() == Event.KeeperState.SyncConnected){
                    connectLatch.countDown();
                }
​
                // waitLatch  需要释放
                if (watchedEvent.getType()== Event.EventType.NodeDeleted && watchedEvent.getPath().equals(waitPath)){
                    waitLatch.countDown();
                }
            }
        });
​
        // 等待zk正常连接后，往下走程序
        connectLatch.await();
​
        // 判断根节点/locks是否存在
        Stat stat = zk.exists("/locks", false);
​
        if (stat == null) {
            // 创建一下根节点
            zk.create("/locks", "locks".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
        }
    }
​
    // 对zk加锁
    public void zklock() {
        // 创建对应的临时带序号节点
        try {
            currentMode = zk.create("/locks/" + "seq-", null, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);
​
            // wait一小会, 让结果更清晰一些
            Thread.sleep(10);
​
            // 判断创建的节点是否是最小的序号节点，如果是获取到锁；如果不是，监听他序号前一个节点
​
            List<String> children = zk.getChildren("/locks", false);
​
            // 如果children 只有一个值，那就直接获取锁； 如果有多个节点，需要判断，谁最小
            if (children.size() == 1) {
                return;
            } else {
                Collections.sort(children);
​
                // 获取节点名称 seq-00000000
                String thisNode = currentMode.substring("/locks/".length());
                // 通过seq-00000000获取该节点在children集合的位置
                int index = children.indexOf(thisNode);
​
                // 判断
                if (index == -1) {
                    System.out.println("数据异常");
                } else if (index == 0) {
                    // 就一个节点，可以获取锁了
                    return;
                } else {
                    // 需要监听  他前一个节点变化
                    waitPath = "/locks/" + children.get(index - 1);
                    zk.getData(waitPath,true,new Stat());
​
                    // 等待监听
                    waitLatch.await();
​
                    return;
                }
            }
​
​
        } catch (KeeperException e) {
            e.printStackTrace();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
​
​
    }
​
    // 解锁
    public void unZkLock() {
​
        // 删除节点
        try {
            zk.delete(this.currentMode,-1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (KeeperException e) {
            e.printStackTrace();
        }
​
    }
​
}

测试类：

public class DistributedLockTest {

    public static void main(String[] args) throws InterruptedException, IOException, KeeperException {

       final  DistributedLock lock1 = new DistributedLock();

        final  DistributedLock lock2 = new DistributedLock();

       new Thread(new Runnable() {
           @Override
           public void run() {
               try {
                   lock1.zklock();
                   System.out.println("线程1 启动，获取到锁");
                   Thread.sleep(5 * 1000);

                   lock1.unZkLock();
                   System.out.println("线程1 释放锁");
               } catch (InterruptedException e) {
                   e.printStackTrace();
               }
           }
       }).start();

        new Thread(new Runnable() {
            @Override
            public void run() {

                try {
                    lock2.zklock();
                    System.out.println("线程2 启动，获取到锁");
                    Thread.sleep(5 * 1000);

                    lock2.unZkLock();
                    System.out.println("线程2 释放锁");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();

    }
}

测试结果：
线程 1 获取锁
线程 1 释放锁
线程 2 获取锁
线程 2 释放锁    

curator分布式锁

原生的 Java API 开发存在的问题 （1）会话连接是异步的，需要自己去处理。比如使用CountDownLatch （2）Watch 需要重复注册，不然就不能生效 （3）开发的复杂性还是比较高的 （4）不支持多节点删除和创建。需要自己去递归

详情请查看官方文档：https://curator.apache.org/index.html

curator可以解决上面的问题

添加相关的依赖文件

<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-framework</artifactId>
    <version>4.3.0</version>
</dependency>
<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-recipes</artifactId>
    <version>4.3.0</version>
</dependency>
<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-client</artifactId>
    <version>4.3.0</version>
</dependency>

主要是通过工程类的定义

编写实现代码如下

public class CuratorLockTest {
​
    public static void main(String[] args) {
​
        // 创建分布式锁1
        InterProcessMutex lock1 = new InterProcessMutex(getCuratorFramework(), "/locks");
​
        // 创建分布式锁2
        InterProcessMutex lock2 = new InterProcessMutex(getCuratorFramework(), "/locks");
​
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    lock1.acquire();
                    System.out.println("线程1 获取到锁");
​
                    lock1.acquire();
                    System.out.println("线程1 再次获取到锁");
​
                    Thread.sleep(5 * 1000);
​
                    lock1.release();
                    System.out.println("线程1 释放锁");
​
                    lock1.release();
                    System.out.println("线程1  再次释放锁");
​
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        }).start();
​
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    lock2.acquire();
                    System.out.println("线程2 获取到锁");
​
                    lock2.acquire();
                    System.out.println("线程2 再次获取到锁");
​
                    Thread.sleep(5 * 1000);
​
                    lock2.release();
                    System.out.println("线程2 释放锁");
​
                    lock2.release();
                    System.out.println("线程2  再次释放锁");
​
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
​
    private static CuratorFramework getCuratorFramework() {
​
        ExponentialBackoffRetry policy = new ExponentialBackoffRetry(3000, 3);
​
        CuratorFramework client = CuratorFrameworkFactory.builder().connectString("hadoop102:2181,hadoop103:2181,hadoop104:2181")
                .connectionTimeoutMs(2000)
                .sessionTimeoutMs(2000)
                .retryPolicy(policy).build();
​
        // 启动客户端
        client.start();
​
        System.out.println("zookeeper 启动成功");
        return client;
    }
}

 总结企业面试

企业中常考的面试有选举机制、集群安装以及常用命令

选举机制 半数机制，超过半数的投票通过，即通过。 （1）第一次启动选举规则： 投票过半数时，服务器 id 大的胜出 （2）第二次启动选举规则： ①EPOCH 大的直接胜出 ②EPOCH 相同，事务 id 大的胜出 ③事务 id 相同，服务器 id 大的胜出

集群安装

• 安装奇数台

• 服务器台数多：好处，提高可靠性；坏处：提高通信延时

常用命令 ls、get、create、delete

算法基础

以下的算法基础主要研究数据是如何保持一致性的 也就是多台服务器的决定问题 比如著名的拜占庭将军问题

Paxos 算法

一种基于消息传递且具有高度容错特性的一致性算法

Paxos算法解决的问题：就是如何快速正确的在一个分布式系统中对某个数据值达成一致，并且保证不论发生任何异常，都不会破坏整个系统的一致性 有唯一的请求id 不接受比其更小的id发话

情况1： 情况2：A5的覆盖，同时A5做了老大 情况3： 以上情况是因为多个 Proposers 相互争夺 Acceptor，造成迟迟无法达成一致的情况。针对这种情况。一种改进的 Paxos 算法被提出：从系统中选出一个节点作为 Leader，只有 Leader 能够发起提案。这样，一次 Paxos 流程中只有一个Proposer，不会出现活锁的情况，此时只会出现例子中第一种情况

 ZAB协议

只有一个服务器提交，没有服务器抢 主要的消息广播如下

• 准备发送，确认收到发送

• 在发送事务，确认收到事务过半之后

• 全部发送消息

但如果宕机 假设两种服务器异常情况： （1）假设一个事务在Leader提出之后，Leader挂了。 （2）一个事务在Leader上提交了，并且过半的Follower都响应Ack了，但是Leader在Commit消息发出之前挂了。

Zab协议崩溃恢复要求满足以下两个要求： （1）确保已经被Leader提交的提案Proposal，必须最终被所有的Follower服务器提交。 （已经产生的提案，Follower必须执行） （2）确保丢弃已经被Leader提出的，但是没有被提交的Proposal。（丢弃胎死腹中的提案）

之后开始新的leader的选举 Leader选举：根据上述要求，Zab协议需要保证选举出来的Leader需要满足以下条件： （1）新选举出来的Leader不能包含未提交的Proposal。即新Leader必须都是已经提交了Proposal的Follower服务器节点 （2）新选举的Leader节点中含有最大的zxid。这样做的好处是可以避免Leader服务器检查Proposal的提交和丢弃工作。

 CAP理论

分布式系统不能同时满足以下三种： 一致性（多个副本之间是否能够保持数据一致的特性） 可用性（系统提供的服务必须一直处于可用的状态） 分区容错性（分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务）

这三个基本需求，最多只能同时满足其中的两项，因为P是必须的，因此往往选择就在CP或者AP中

ZooKeeper保证的是一致性和分区容错性