《别看了，你学不会的》——zookeeper入门与实践

zookeeper

前言

我们大多数使用zookeeper，大多数是作为辅助工具，比如说在做Kafka的时候，把zookeeper作为服务发现的中间件来使用，使用dubbo的时候会用到zookeeper来注册节点

在使用分布式锁的时候才会使用到zookeeper

当服务启动以后，会在zookeeper里面注册节点。当zookeeper注册节点的时候，节点的类型不一定是临时节点，有的版本创建的节点是永久节点

如果对某一个节点进行了增删改操作，使用zookeeper的watch机制就能快速的知道

什么是zookeeper

• zookeeper是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一种复杂的过程，zookeeper通过简单的架构和API解决了这个问题
• zookeeper运行开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性
• zookeeper的应用场景
• • 分布式协调组件：在分布式系统中，需要有zookeeper作为分布式协调组件，来协调分布式系统中的状态
• • 分布式锁：zookeeper在实现分布式锁上门，可以做到强一致性
• • 无状态的实现：可以将一些具有无状态的信息存储到zookeeper中，分布式服务直接去zookeeper中获取相关信息

zookeeper启动命令

启动zookeeper

./zkServer.sh start

查看zookeeper的运行状态

zkServer.sh status

关闭zookeeper服务

zkServer.sh stop

zookeeper客户端连接

zkClient.sh

znode

zookeeper中数据的存储结构

• zookeeper中的数据是保存在节点(znode)上的，多个znode之间能构成一棵树型的目录结构
• 树树由节点所组成，zookeeper的数据存储也同样是基于节点，这种节点就叫做znode
• 但是不同于树的几点，znode的引用方式是路径引用，类似于文件路径：/a/b，这种的层级结构，让每一个znode节点拥有唯一的路径，就像命名空间一样，对不同信息做出清晰的隔离
  

znode的结构

znode包含如下部分

名称	解释
data	保存的数据
acl	权限，定义了什么样的用户能操作这个节点，且能够进行怎样的操作 【c】create：创建权限，允许在该节点下创建子节点 【w】write：更新权限，允许更新该节点的数据 【r】read：读取权限，运行读取该节点的内容以及子节点的列表信息 【d】delete：删除权限，允许删除该节点的子节点 【a】admin：管理员权限，允许对该节点进行acl权限设置
stat	描述当前的znode的元数据
child	当前节点的子节点

znode的类型

• 持久节点（create[节点][存储的值])
  创建出的节点，在会话结束后依然存在。保存数据
  当我们需要存储服务里面的配置，就应该使用持久节点，而不是临时节点
• 持久序号节点（create -s[节点]）
  具有持久节点的特征。创建出的节点，根据先后顺序，会在节点之后带上一个数值，越后面的节点数值越大。适合分布式锁的应用场景
• 临时节点
  创建一个临时节点后，如果创建节点的会话结束，该节点会被自动的删除。通过这个特性，zk可以实现服务的注册与发现。临时节点通过心跳机制，告诉zk服务器自己还活着
  

如果有请求过来，而机器3和机器4 宕机了，这时候肯定不能让请求过来到这两台机器的，所以这里就可以使用临时节点，两个服务session挂掉之后在zookeeper里面维护的节点就只剩两个znode了，所以就不会出现请求到第三第四个机器这种情况
如果使用的是持久节点

• 临时序号节点（create -es[节点]或create -e -s[节点])
  具有临时节点和序号节点的特征总和
• 容器节点（create -c[节点]）
  在zookeeper3.5.3版本新增的节点。当我们创建完容器节点后，如果该节点下没有任何子节点，那么该容器节点就会被zk删除
• TTL节点（create -t[毫秒数][节点]）
  可以指定节点的到期时间，到期后会被zk删除
  需要通过系统配置zoo.cfg文件中
  extendedTypesEnable=true开启

根据不同的业务场景选择不同的节点类型

数据持久化机制

zookeeper的数据在内存中运行，它提供了两种持久化机制：

1. 事务日志

• • zookeeper把执行的命令以日志的形式保存在dataLogDir指定的路径中的文件里，如果没有指定dataLogDir，则按照dataDir指定的路径

2. 数据快照

• • zookeeper会在一定的时间间隔内做一次内存数据的快照，把这段时间的内存数据保存到快照文件中

zookeeper通过上面的两种形式的持久化，在恢复时先恢复快照文件中的数据到内存中，再用日志文件中的数据做增量恢复，这样可以加快恢复速度。查看事务日志和数据快照文件

zkCli常用指令操作

常用指令

官方文档：https://zookeeper.apache.org/doc/r3.7.0/zookeeperCLI.html

查询某个节点下所有“一级”节点
ls [节点路径]

查询某节点下“所有”节点
ls -R [节点路径]

查询节点上存储的值
get [节点路径]

查询节点的详细信息
get -s [节点路径]

设置/修改节点上存储的值
set [节点路径] [存储的值]

删除节点（删除某节点，并且该节点下没有子节点）
delete [节点路径]

删除节点（删除某节点以及节点下的所有子节点）
deleteall [节点路径]

乐观锁删除（如果删除的版本不匹配，异常提醒：version No is not valid）
delete -v [dataVersion] [节点路径]

名称	解释
cZxid	创建节点的事务ID
ctime	节点创建的时间
mZxid	修改节点的事务ID
mtime	节点最近修改的时间
pZxid	添加和删除子节点的事务ID
cversion	当前节点的子节点版本号，初始值为-1，每对该节点的子节点进行操作，这个cversion都会自动增加
dataVersion	当前子节点的数据版本号，初识版本为0，每对该节点的数据进行操作，这个dataVersion都会自动增加
aclVersion	此节点的权限版本
ephemeralOwnwer	如果当前节点是临时节点，该值就是当前节点所有者的sessionID。如果不是临时节点，那么该值为0
dataLength	节点内数据的长度
numChildren	该节点的子节点个数

权限设置

ACL权限：定义了什么样的用户能够操作这个节点，且能够进行怎样的操作

命令	全称	含义	解释
c	create	创建权限	允许在该节点下创建子节点
w	write	更新权限	允许更新该节点的数据
r	read	读取权限	允许读取该节点的内容以及子节点的列表信息
d	delete	删除权限	允许删除该节点的子节点
a	admin	管理员权限	允许对该节点进行acl权限设置

为当前会话添加权限账号和权限密码

addauth digest[用户名]:[密码]

创建节点并设置权限

create[节点][节点value] auth:[用户名]:[密码]:[ACL命令]

Curator

官网地址：https://curator.apache.org/
Curator说Netflix公司开源的一套zookeeper客户端框架，Curator是对zookeeper支持最好的客户端框架。Curator封装了大部分zookeeper的功能，比如：Leader选举、分布式锁等等，极大的减轻了开发者在使用zookeeper时的底层细节开发工作

maven依赖

 <dependency>
            <groupId>org.apache.zookeeper</groupId>
            <artifactId>zookeeper</artifactId>
            <version>3.7.0</version>
        </dependency>
        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-framework</artifactId>
            <version>5.2.0</version>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.zookeeper</groupId>
                    <artifactId>zookeeper</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

创建永久节点

private final static String NODE_NAME = "/curator-node";
private final static byte[] VALUE_BYTES = "yang".getBytes();
@Test
    void createNode() throws Throwable {
        String path = curatorFramework.create().forPath(NODE_NAME, VALUE_BYTES);
        log.info("createNode success! path={}", path);
    }

创建临时序号节点

private final static String EPHEMERAL_NODE_NAME = "/curator-ephemeral-node-";
private final static byte[] VALUE_BYTES = "yang".getBytes();
 @Test
 @SneakyThrows
 void createEphemeralSeqNode() {
     String path = curatorFramework.create().withMode(CreateMode.EPHEMERAL_SEQUENTIAL).
             forPath(EPHEMERAL_NODE_NAME, VALUE_BYTES);
     log.info("createEphemeralSeqNode success! path={}", path);
     Thread.sleep(5000); // 线程睡眠5秒钟，这个时间可以查询到临时节点，方法执行完毕，临时节点就不存在了
 }

创建节点，如果父节点不存在，则顺便创建出来

 private final static String PARENT_NODE_NAME = "/animal/dog/whiteDog";
 private final static byte[] VALUE_BYTES = "yang".getBytes();
@Test
@SneakyThrows
void createWithParent() {
    String path = curatorFramework.create().creatingParentsIfNeeded().forPath(PARENT_NODE_NAME, VALUE_BYTES);
    log.info("createWithParent success! path={}", path);
}

获得节点上存储的值

private final static String NODE_NAME = "/curator-node";
@Testd
@SneakyThrows
void getData() {
    byte[] valueByte = curatorFramework.getData().forPath(NODE_NAME);
    log.info("getData success! valueByte={}", new String(valueByte));
}

修改节点上存储的值

private final static String NODE_NAME = "/curator-node";
private final static byte[] NEW_VALUE_BYTES = "yang-new".getBytes();
@Test
@SneakyThrows
void setData() {
        curatorFramework.setData().forPath(NODE_NAME, NEW_VALUE_BYTES);
    }

删除节点及其包含的子节点

private final static String NODE_NAME = "/curator-node";
 @Test
 @SneakyThrows
 void deleteNode() {
     curatorFramework.delete().guaranteed().deletingChildrenIfNeeded().forPath(NODE_NAME);
 }

分布式锁

读锁

并发的时候，多个线程都可以执行读操作，彼此不会阻塞
加读锁成功的前提是：没有对其待访问的资源加写锁
如果有一个资源加了读锁，有3条线程同时访问这个资源，那么这是没问题的

但是，如果这个资源同时加了读锁和写锁，那么第一个线程来的时候先执行读操作，再执行写操作就会发生阻塞，其余的线程再来执行写都会发生阻塞

写锁

并发时如果多个线程都要去获得写锁，那么只有一条线程可以获得写锁，彼此之间会发生阻塞
加锁成功的前提是：没有对其待访问的资源加任何锁（无论是写锁还是读锁）

如何实现读写锁

1. 在/lock路径下创建临时序号节点/lock/WRITE-或/lock/Read-，该节点就代表将要获取的Write/Read锁节点
2. 获取/lock下的子节点，并按照临时节点的顺序号排序
3. 检查此Read/Write锁之前是否有Write锁，如果有，则先注册对该Write锁前一个锁的监听，然后阻塞该Read/Write锁的获取
4. 如果监听到该Read/Write锁前一个Write锁已释放，则打开阻塞，继续执行

使用Curator提供的读写锁

Maven依赖

        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-recipes</artifactId>
            <version>5.2.0</version>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.zookeeper</groupId>
                    <artifactId>zookeeper</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

读锁

	@Test
    @SneakyThrows
    void getReadLock() {
        InterProcessReadWriteLock rwlock = new InterProcessReadWriteLock(curatorFramework, "/read-lock");
        InterProcessMutex readLock = rwlock.readLock(); /** 获得读锁实例对象 */
        for (int i = 0; i< 10 ; i++) {
            new Thread(()-> {
                String threadName = Thread.currentThread().getName();
                try {
                    readLock.acquire(); // 获取读锁
                    log.info("线程={}：等待获取Read锁成功！开始执行业务代码...", threadName);
                    Thread.sleep(1000);
                } catch (Throwable e) {
                    e.printStackTrace();
                } finally {
                    try {
                        readLock.release(); // 释放锁
                    } catch (Throwable e) {
                        e.printStackTrace();
                    }
                }
            }).start();
        }
        Thread.sleep(2000);
    }

写锁

	@Test
    @SneakyThrows
    void getWriteLock() {
        InterProcessReadWriteLock rwlock = new InterProcessReadWriteLock(curatorFramework, "/write-lock");
        InterProcessMutex writeLock = rwlock.writeLock(); /** 获得写锁实例对象 */
        for (int i = 0; i< 5 ; i++) {
            new Thread(()-> {
                String threadName = Thread.currentThread().getName();
                try {
                    writeLock.acquire(); // 获取写锁
                    log.info("线程={}：等待获取Write锁成功！开始执行业务代码...", threadName);
                    Thread.sleep(1000);
                } catch (Throwable e) {
                    e.printStackTrace();
                } finally {
                    try {
                        writeLock.release(); // 释放锁
                    } catch (Throwable e) {
                        e.printStackTrace();
                    }
                }
            }).start();
        }
        Thread.sleep(6000);
    }

Watch机制

• 可以把Watch理解成是注册在指定Znode上的触发器
• 当被Watch的这个Znode发生了变化(即：create，delete，setData)时，将会触发Znode上注册的对应监听事件，请求Watch的客户端会接收到异步回调通知
• 客户端使用了NIO通信模式监听服务的调用
• 监听节点内容的变化，可以使用get -w[节点]
• 监听节点目录的变化，可以使用ls -w[节点]
• 监听所有级别子目录变化，可以使用ls -w -R[节点]

基于Curator使用Watch

void watch() {
        // 如果不存在节点，则创建
        if (null == curatorFramework.checkExists().forPath(WATCH_NODE_NAME)) {
            curatorFramework.create().forPath(WATCH_NODE_NAME, VALUE_BYTES);
        }
        CuratorCache curatorCache = CuratorCache.builder(curatorFramework, WATCH_NODE_NAME).build();
        CuratorCacheListener listener = CuratorCacheListener.builder().forNodeCache(new NodeCacheListener() {
            @Override
            public void nodeChanged() {
                log.info("-----forNodeCache-----{} node is changed!", WATCH_NODE_NAME);
            }
        }).forAll(new CuratorCacheListener() {
            @Override
            public void event(Type type, ChildData oldData, ChildData data) {
                log.info("-----forAll-----{} node is changed！type={} oldDate={} date={}", WATCH_NODE_NAME,
                        GSON.toJson(type), GSON.toJson(oldData), GSON.toJson(data));
            }
        }).build();
        curatorCache.listenable().addListener(listener);
        curatorCache.start();

        System.in.read();
    }

zookeeper集群

第一步：创建4个数据存储目录
第二步：分别在zk1~zk4目录中创建myid文件

touch myid

第三步：创建4个zoo.cfg配置文件，分别在zoo1.conf，zoo2.conf，zoo3.conf，zoo4.conf

#clientPort修改为2181-2184
clientPort=2184
#dataDir修改为文件路径
dataDir=/Users/yangxudong/apache-zookeeper-3.7.1-bin/dataDir/zk4
#2001为集群通信端口；3001为集群选举接口；observer表示不参与集群选举
sever.1=127.0.0.1:2001:3001
sever.2=127.0.0.1:2001:3002
sever.3=127.0.0.1:2001:3003
sever.4=127.0.0.1:2001:3004:observer

第四步：启动4台zookeeper

第五步：查看4台zookeeper的角色

第六步：连接集群

> ./zkCli.sh -server 127.0.0.1:2181 127.0.0.1:2182 127.0.0.1:2183 127.0.0.1:2184

zookeeper的Leader选举

zookeeper作为非常重要的分布式协调组件，需要进行集群部署，集群中会以一主多从多形式进行部署。为了保证数据的一致性，使用了ZAB(zookeeper Atomic Broadcase)协议，这个协议解决了zookeeper的崩溃恢复和主从数据同步的问题

ZAB协议定义了如下四种节点状态

名称	解释
Looking	选举状态
Following	Follower节点(从节点)所处的状态
Leading	Leader节点(主节点)所处的状态
Observing	观察者节点所处的状态

Leader选举流程——第一轮选举投票

Leader选举流程——第二轮选举投票

Leader选举流程——确定leader后

Leader选举出来之后，会周期性不断的向Follower发送心跳(ping命令，没有内容的socket)

当Leader崩溃后，Follower发现socket通道已经关闭，那么Follower就会从Following状态进入Looking状态，然后重新开始进行Leader的选举，在Leader选举的这个过程中，zk集群不能对外提供服务

zookeeper的数据同步

如果客户端连接了Leader节点，则直接将数据写入到主节点中；如果客户端连接到了Follower节点，那么Follower节点会将数据转发给Leader节点，Leader节点再将数据写入到本节点中