zookeeper知识点总结--持续更新中

Zookeeper有三种运行形式：集群模式、单机模式、伪集群模式。
若删除节点存在子节点，那么无法删除该节点，必须先删除子节点，再删除父节点。
zookeeper使用分为命令行、javaApi

zookeeper的三个jar包jar、javadoc.jar、sources.jar，使用maven依赖的只需要如下配置

<dependency>
            <groupId>org.apache.zookeeper</groupId>
            <artifactId>zookeeper</artifactId>
            <version>3.4.6</version>
        </dependency>

创建节点有异步和同步两种方式。无论是异步或者同步，Zookeeper都不支持递归调用，即无法在父节点不存在的情况下创建一个子节点，如在/zk-ephemeral节点不存在的情况下创建/zk-ephemeral/ch1节点；并且如果一个节点已经存在，那么创建同名节点时，会抛出NodeExistsException异常。
Watcher通知是一次性的，即一旦触发一次通知后，该Watcher就失效了，因此客户端需要反复注册Watcher，即程序中在process里面又注册了Watcher，否则，将无法获取c3节点的创建而导致子节点变化的事件。
在更新数据时，setData方法存在一个version参数，其用于指定节点的数据版本，表明本次更新操作是针对指定的数据版本进行的，但是，在getData方法中，并没有提供根据指定数据版本来获取数据的接口，那么，这里为何要指定数据更新版本呢，这里方便理解，可以等效于CAS（compare and swap），对于值V，每次更新之前都会比较其值是否是预期值A，只有符合预期，才会将V原子化地更新到新值B。Zookeeper的setData接口中的version参数可以对应预期值，表明是针对哪个数据版本进行更新，假如一个客户端试图进行更新操作，它会携带上次获取到的version值进行更新，而如果这段时间内，Zookeeper服务器上该节点的数据已经被其他客户端更新，那么其数据版本也会相应更新，而客户端携带的version将无法匹配，无法更新成功，因此可以有效地避免分布式更新的并发问题
ZkClient开源客户端提供了递归创建节点的接口，即其帮助开发者完成父节点的创建，再创建子节点。值得注意的是，在原生态接口中是无法创建成功的（父节点不存在），但是通过ZkClient可以递归的先创建父节点，再创建子节点。
Curator客户端解决了很多Zookeeper客户端非常底层的细节开发工作，包括连接重连，反复注册Watcher和NodeExistsException异常等，现已成为Apache的顶级项目。
Curator除了使用一般方法创建会话外，还可以使用fluent风格进行创建。通过使用Fluent风格的接口，开发人员可以进行自由组合来完成各种类型节点的创建。
Curator除了提供很便利的API，还提供了一些典型的应用场景，开发人员可以使用参考更好的理解如何使用Zookeeper客户端，所有的都在recipes包中，只需要在pom.xml中添加如下依赖即可
Master选举　　借助Zookeeper，开发者可以很方便地实现Master选举功能，其大体思路如下：选择一个根节点，如/master_select，多台机器同时向该节点创建一个子节点/master_select/lock，利用Zookeeper特性，最终只有一台机器能够成功创建，成功的那台机器就是Master。
分布式锁　　为了保证数据的一致性，经常在程序的某个运行点需要进行同步控制。以流水号生成场景为例，普通的后台应用通常采用时间戳方式来生成流水号，但是在用户量非常大的情况下，可能会出现并发问题。

package com.hust.grid.leesf.curator.examples;

import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.concurrent.CountDownLatch;

public class Recipes_NoLock {
    public static void main(String[] args) throws Exception {
        final CountDownLatch down = new CountDownLatch(1);
        for (int i = 0; i < 10; i++) {
            new Thread(new Runnable() {
                public void run() {
                    try {
                        down.await();
                    } catch (Exception e) {
                    }
                    SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss|SSS");
                    String orderNo = sdf.format(new Date());
                    System.err.println("生成的订单号是 : " + orderNo);
                }
            }).start();
        }
        down.countDown();
    }
}

　　运行结果：　

生成的订单号是 : 16:29:10|590
生成的订单号是 : 16:29:10|590
生成的订单号是 : 16:29:10|591
生成的订单号是 : 16:29:10|591
生成的订单号是 : 16:29:10|590
生成的订单号是 : 16:29:10|590
生成的订单号是 : 16:29:10|591
生成的订单号是 : 16:29:10|590
生成的订单号是 : 16:29:10|592
生成的订单号是 : 16:29:10|591

　　结果表示订单号出现了重复，即普通的方法无法满足业务需要，因为其未进行正确的同步。可以使用Curator来实现分布式锁功能。

package com.hust.grid.leesf.curator.examples;

import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.concurrent.CountDownLatch;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.apache.curator.retry.ExponentialBackoffRetry;

public class Recipes_Lock {
    static String lock_path = "/curator_recipes_lock_path";
    static CuratorFramework client = CuratorFrameworkFactory.builder().connectString("127.0.0.1:2181")
            .retryPolicy(new ExponentialBackoffRetry(1000, 3)).build();

    public static void main(String[] args) throws Exception {
        client.start();
        final InterProcessMutex lock = new InterProcessMutex(client, lock_path);
        final CountDownLatch down = new CountDownLatch(1);
        for (int i = 0; i < 30; i++) {
            new Thread(new Runnable() {
                public void run() {
                    try {
                        down.await();
                        lock.acquire();
                    } catch (Exception e) {
                    }
                    SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss|SSS");
                    String orderNo = sdf.format(new Date());
                    System.out.println("生成的订单号是 : " + orderNo);
                    try {
                        lock.release();
                    } catch (Exception e) {
                    }
                }
            }).start();
        }
        down.countDown();
    }
}

　　运行结果：

生成的订单号是 : 16:31:50|293
生成的订单号是 : 16:31:50|319
生成的订单号是 : 16:31:51|278
生成的订单号是 : 16:31:51|326
生成的订单号是 : 16:31:51|402
生成的订单号是 : 16:31:51|420
生成的订单号是 : 16:31:51|546
生成的订单号是 : 16:31:51|602
生成的订单号是 : 16:31:51|626
生成的订单号是 : 16:31:51|656
生成的订单号是 : 16:31:51|675
生成的订单号是 : 16:31:51|701
生成的订单号是 : 16:31:51|708
生成的订单号是 : 16:31:51|732
生成的订单号是 : 16:31:51|763
生成的订单号是 : 16:31:51|785
生成的订单号是 : 16:31:51|805
生成的订单号是 : 16:31:51|823
生成的订单号是 : 16:31:51|839
生成的订单号是 : 16:31:51|853
生成的订单号是 : 16:31:51|868
生成的订单号是 : 16:31:51|884
生成的订单号是 : 16:31:51|897
生成的订单号是 : 16:31:51|910
生成的订单号是 : 16:31:51|926
生成的订单号是 : 16:31:51|939
生成的订单号是 : 16:31:51|951
生成的订单号是 : 16:31:51|965
生成的订单号是 : 16:31:51|972
生成的订单号是 : 16:31:51|983

　　结果表明此时已经不存在重复的流水号。

命名服务

　　命名服务是分步实现系统中较为常见的一类场景，分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等，通过命名服务，客户端可以根据指定名字来获取资源的实体、服务地址和提供者的信息。Zookeeper也可帮助应用系统通过资源引用的方式来实现对资源的定位和使用，广义上的命名服务的资源定位都不是真正意义上的实体资源，在分布式环境中，上层应用仅仅需要一个全局唯一的名字。Zookeeper可以实现一套分布式全局唯一ID的分配机制。

　　通过调用Zookeeper节点创建的API接口就可以创建一个顺序节点，并且在API返回值中会返回这个节点的完整名字，利用此特性，可以生成全局ID，其步骤如下

　　1. 客户端根据任务类型，在指定类型的任务下通过调用接口创建一个顺序节点，如"job-"。

　　2. 创建完成后，会返回一个完整的节点名，如"job-00000001"。

　　3. 客户端拼接type类型和返回值后，就可以作为全局唯一ID了，如"type2-job-00000001"。
分布式锁

　　分布式锁用于控制分布式系统之间同步访问共享资源的一种方式，可以保证不同系统访问一个或一组资源时的一致性，主要分为排它锁和共享锁。

　　排它锁又称为写锁或独占锁，若事务T1对数据对象O1加上了排它锁，那么在整个加锁期间，只允许事务T1对O1进行读取和更新操作，其他任何事务都不能再对这个数据对象进行任何类型的操作，直到T1释放了排它锁。

　　① 获取锁，在需要获取排它锁时，所有客户端通过调用接口，在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock。Zookeeper可以保证只有一个客户端能够创建成功，没有成功的客户端需要注册/exclusive_lock节点监听。

　　② 释放锁，当获取锁的客户端宕机或者正常完成业务逻辑都会导致临时节点的删除，此时，所有在/exclusive_lock节点上注册监听的客户端都会收到通知，可以重新发起分布式锁获取。

　　共享锁又称为读锁，若事务T1对数据对象O1加上共享锁，那么当前事务只能对O1进行读取操作，其他事务也只能对这个数据对象加共享锁，直到该数据对象上的所有共享锁都被释放。

　　① 获取锁，在需要获取共享锁时，所有客户端都会到/shared_lock下面创建一个临时顺序节点，如果是读请求，那么就创建例如/shared_lock/host1-R-00000001的节点，如果是写请求，那么就创建例如/shared_lock/host2-W-00000002的节点。

　　② 判断读写顺序，不同事务可以同时对一个数据对象进行读写操作，而更新操作必须在当前没有任何事务进行读写情况下进行，通过Zookeeper来确定分布式读写顺序，大致分为四步。

　　　　1. 创建完节点后，获取/shared_lock节点下所有子节点，并对该节点变更注册监听。

　　　　2. 确定自己的节点序号在所有子节点中的顺序。

　　　　3. 对于读请求：若没有比自己序号小的子节点或所有比自己序号小的子节点都是读请求，那么表明自己已经成功获取到共享锁，同时开始执行读取逻辑，若有写请求，则需要等待。对于写请求：若自己不是序号最小的子节点，那么需要等待。

　　　　4. 接收到Watcher通知后，重复步骤1。

　　③ 释放锁，其释放锁的流程与独占锁一致。

　　上述共享锁的实现方案，可以满足一般分布式集群竞争锁的需求，但是如果机器规模扩大会出现一些问题，下面着重分析判断读写顺序的步骤3。

　　针对如上图所示的情况进行分析

　　1. host1首先进行读操作，完成后将节点/shared_lock/host1-R-00000001删除。

　　2. 余下4台机器均收到这个节点移除的通知，然后重新从/shared_lock节点上获取一份新的子节点列表。

　　3. 每台机器判断自己的读写顺序，其中host2检测到自己序号最小，于是进行写操作，余下的机器则继续等待。

　　4. 继续...

　　可以看到，host1客户端在移除自己的共享锁后，Zookeeper发送了子节点更变Watcher通知给所有机器，然而除了给host2产生影响外，对其他机器没有任何作用。大量的Watcher通知和子节点列表获取两个操作会重复运行，这样会造成系能鞥影响和网络开销，更为严重的是，如果同一时间有多个节点对应的客户端完成事务或事务中断引起节点小时，Zookeeper服务器就会在短时间内向其他所有客户端发送大量的事件通知，这就是所谓的羊群效应。

　　可以有如下改动来避免羊群效应。

　　1. 客户端调用create接口常见类似于/shared_lock/[Hostname]-请求类型-序号的临时顺序节点。

　　2. 客户端调用getChildren接口获取所有已经创建的子节点列表（不注册任何Watcher）。

　　3. 如果无法获取共享锁，就调用exist接口来对比自己小的节点注册Watcher。对于读请求：向比自己序号小的最后一个写请求节点注册Watcher监听。对于写请求：向比自己序号小的最后一个节点注册Watcher监听。

　　4. 等待Watcher通知，继续进入步骤2。

　　此方案改动主要在于：每个锁竞争者，只需要关注/shared_lock节点下序号比自己小的那个节点是否存在即可。
分布式队列

　　分布式队列可以简单分为先入先出队列模型和等待队列元素聚集后统一安排处理执行的Barrier模型。

　　① FIFO先入先出，先进入队列的请求操作先完成后，才会开始处理后面的请求。FIFO队列就类似于全写的共享模型，所有客户端都会到/queue_fifo这个节点下创建一个临时节点，如/queue_fifo/host1-00000001。

　　创建完节点后，按照如下步骤执行。

　　1. 通过调用getChildren接口来获取/queue_fifo节点的所有子节点，即获取队列中所有的元素。

　　2. 确定自己的节点序号在所有子节点中的顺序。

　　3. 如果自己的序号不是最小，那么需要等待，同时向比自己序号小的最后一个节点注册Watcher监听。

　　4. 接收到Watcher通知后，重复步骤1。

　　② Barrier分布式屏障，最终的合并计算需要基于很多并行计算的子结果来进行，开始时，/queue_barrier节点已经默认存在，并且将结点数据内容赋值为数字n来代表Barrier值，之后，所有客户端都会到/queue_barrier节点下创建一个临时节点，例如/queue_barrier/host1。

　　创建完节点后，按照如下步骤执行。

　　1. 通过调用getData接口获取/queue_barrier节点的数据内容，如10。

　　2. 通过调用getChildren接口获取/queue_barrier节点下的所有子节点，同时注册对子节点变更的Watcher监听。

　　3. 统计子节点的个数。

　　4. 如果子节点个数还不足10个，那么需要等待。

　　5. 接受到Wacher通知后，重复步骤3。

zookeeper知识点总结--持续更新中

猜你喜欢