七、Zookeeper分布式协调配置实现

最新推荐文章于 2022-12-09 01:22:04 发布

努力的布布

最新推荐文章于 2022-12-09 01:22:04 发布

阅读量167

点赞数

分类专栏： zookeeper 文章标签： zookeeper 分布式云原生

本文链接：https://blog.csdn.net/qq_37200262/article/details/125154343

版权

zookeeper 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

为什么需要分布式配置中心

对于刚开始的时候，很多公司的服务器可能是由单个组成，但是随着业务的发展，单一节点的服务无法满足业务的飞速发展，后面就出现了分布式、集群的概念，到了现在形成的微服务，技术的改进能够更好的满足业务的需要。

假设我们线上有很多个微服务分布在不同的服务器上，其中一个微服务，我们就叫它 goods-service，当 goods-service的IP地址需要变更的时候，但是 goods-service又对很多其他的程序提供了服务，这个时候如果没有一个统一配置的东西，每一个应用到 goods-service的应用程序都要做相应的IP地址修改，这是一个很麻烦的事情！

如果使用ZooKeeper来做分布式配置的话，是可以解决这个问题的。
因为通过zookeeper的监听回调机制的实现，将所有服务的数据存放在zookeeper的文件树中，监听该节点，如果节点发生变化就回调通知监听该节点的服务做出响应。
在这里插入图片描述
配置中心的核心
低延迟：配置改变（create/update/delete）后能够最快的把最新的配置同步到其他节点中

高可用：配置中心可以稳定的对外提供服务
其中低延迟我们可以通过 ZooKeeper 的 Watcher 机制来实现（等下会讲到Watcher机制）。约定一个节点用来存放配置信息，每个客户端都来监听这个节点的NodeDataChanged事件，当配置发生改变时将最新的配置更新到这个节点上，谁更新无所谓，任何节点都可以更新，当这个节点触发 NodeDataChanged 事件后，在去通知所有监听这个节点的客户端去获取这个节点的最新信息，因为watcher 是一次性的，所以当我们在获取最新信息的时候需要设置监听事件，大部分查询信息都是具有原子性的，所以ZooKeeper中的 getData 也是具有原子性操作，能够保证我们取得的信息是最新的。

对于高可用我们首先需要保证的多集群操作来进行ZooKeeper进行部署，在代码层不太需要做过多的工作。

在这里插入图片描述
Watch 机制
Watch 是 ZooKeeper 针对节点的一次性观察者机制，就如同我们上面 ** 低延迟** 中讲到的，一次触发后就失效，需要手工重新创建Watch。

当Watch监视的数据发生变化的时候，就会通知设置了 Watch 的客户端，就是我们API中的Watcher，Watcher机制就是为了监听Znode节点发生了哪些变化，所以会有对应的事件类型和状态类型，用过代码中switch进行监听，一个客户端可以链接多个节点，只要Znode节点发生变化就会执行 process(WatchedEvent event)。
在这里插入图片描述
从上图中我们可以看到，在ZooKeeper中，Watch采用的是推送机制，而不是客户端轮询，有些中间件采用的是拉取的模式，例如：KafKa。

Watch有两种监听模式，分别为事件类型和状态类型：

事件类型：Znode 节点关联，主要是针对节点的操作

创建节点：EventType.NodeCreated
节点数据发生变化：EventType.NodeDataChanged
当前节点的子节点发生变化：EventType.NodeChildrenChanged
删除节点：EventType.NodeDeleted
状态类型：客户端关联，主要是针对于ZooKeeper集群和应用服务之间的状态的变更
未连接：KeeperState.Disconnected
已连接：KeeperState.SyncConnected
认证失败：KeeperState.AuthFailed
过期：KeeperState.Expired
客户端连接到只读服务器：KeeperState.ConnectedReadOnly

watch的特性

一次性触发：对于ZooKeeper的Watcher事件，是一次性触发的，当 Watch 监视的数据发生变化的时候，通知设置当前Watch 的 Client，就是我们对应的 Watcher，因为ZooKeeper 的监控都是一次性的，所以我们需要在每次触发后设置监控。

客户端串行执行：客户端Watcher回调的过程是一个串行同步的过程，可以为我们保证顺序的执行。

轻量级： WatchedEvent是ZooKeeper整个Watcher通知机制的最小通知单元，总共包含三个部分（通知状态、事件类型和节点路径），Watcher通知，只会告诉客户端发生事件而不会告知具体内容，需要客户端主动去进行获取，比如当监听到 WatchedEvent.NodeDataChanged 信息变化的时候，只会告诉我们这个节点的数据发生了变更，你快来获取最新的值吧。

客户端设置的每个监视点与会话关联，如果会话过期，等待中的监视点将会被删除。不过监视点可以跨越不同服务端的连接而保持，例如，当一个ZooKeeper客户端与一个ZooKeeper服务端的连接断开后连接到集合中的另一个服务端，客户端会发送未触发的监视点列表，在注册监视点时，服务端将要检查已监视的znode节点在之前注册监视点之后是否已经变化，如果znode节点已经发生变化，一个监视点的事件就会被发送给客户端，否则在新的服务端上注册监视点。这一机制使得我们可以关心逻辑层会话，而非底层连接本身。

客户端注册
在这里插入图片描述
ZooKeeper 注册的时候会向ZooKeeper 服务端请求注册，服务端会返回请求响应，不管成功失败，都会返回响应结果，当响应成功的时候，ZooKeeper服务端会把Watcher对象放到客户端的WatchManager管理并返回响应给客户端
服务端注册

在这里插入图片描述 FinalRequest Processor.ProcessRequest()会判断当前请求是否需要注册Watcher

如果ZooKeeper判断当前客户端需要进行Watcher注册，会将当前的ServerCnxn 对象和数据路径传入 getData 方法中去。ServerCnxn 是ZooKeeper 客户端和服务端之间的连接接口，代表了一个客户端和服务端的连接，可以将 ServerCnxn 当做一个 Watcher 对象，因为它实现了 Watcher 的 process 接口。

WatcherManager

WatcherManager是 ZK服务端 Watcher 的管理器，分为 WatchTable 和 Watch2Paths 两个存储结构，这两个是不同的存储结构
1）WatchTable：从数据节点路径的颗粒度管理 Watcher
2）Watch2Paths：从Watcher的颗粒度来控制时间出发的数据节点

在服务端，DataTree 中会托管两个 WatchManager，分别是 dataWatches （数据变更Watch）和 childWatches（子节点变更Watch）。

Watcher 触发逻辑

1）封装WatchedEven：将（KeeperState(通知状态),EventType(事件类型),Path(节点路径)）封装成一个 WatchedEvent 对象
2）查询Watcher：根据路径取出对应的Watcher，如果存在，取出数据同时从 WatcherManager(WatchTable/Watch2Paths) 中删除
3）调用Process方法触发Watcher

客户端回调 Watcher

1）反序列化：字节流转换成 WatcherEvent 对象
2）处理 chrootPath：如果客户端设置了 chrootPath 属性，那么需要对服务器传过来的完整节点路径进行 chrootPath 处理，生成客户端的一个相对节点路径。比如（/mxn/app/love，经过chrootPath处理，会变成 /love）
3）还原 WatchedEvent：WatcherEvent 转换成 WatchedEvent
4）回调 Watcher：将 WatcherEvent 对象交给 EventThread 线程，在下一个轮询周期中进行 Watcher 回调

EventThread 处理时间通知

1） SendThread 接收到服务端的通知事件后，会通过调用 EventThread.queueEvent 方法将事件传给 EventThread 线程
2）queueEvent 方法首先会根据该通知事件，从 ZKWatchManager 中取出所有相关的 Watcher 客户端识别出事件类型 EventType 后，会从相应的 Watcher 存储（即3个注册方法( dataWatches、existWatcher 或 childWatcher）中去除对应的 Watcher
3）获取到相关的所有 Watcher 后，会将其放入 waitingEvents 这个队列去

代码实现

引入依赖

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

Watcher

创建ZooKeeper的时候，我们需要一个Watcher进行监听，后续对Znode节点操作的时候，我们也需要使用到Watcher，但是这两类的功能不一样，所以我们需要定义一个自己的watcher类，如下所示：

import org.apache.zookeeper.WatchedEvent;
import org.apache.zookeeper.Watcher;

import java.util.concurrent.CountDownLatch;

public class DefaultWatch  implements Watcher {

    CountDownLatch cc ;

    public void setCc(CountDownLatch cc) {
        this.cc = cc;
    }

    @Override
    public void process(WatchedEvent event) {

        System.out.println(event.toString());

        switch (event.getState()) {
            case Unknown:
                break;
            case Disconnected:
                break;
            case NoSyncConnected:
                break;
            case SyncConnected:
                cc.countDown();
                break;
            case AuthFailed:
                break;
            case ConnectedReadOnly:
                break;
            case SaslAuthenticated:
                break;
            case Expired:
                break;
        }


    }
}

配置类
要模拟一个配置，这个配置用来同步服务的地址

//这个class使你未来最关心的地方？
public class MyConf {

    private  String conf ;

    public String getConf() {
        return conf;
    }

    public void setConf(String conf) {
        this.conf = conf;
    }
}

测试类：

import org.apache.zookeeper.ZooKeeper;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;


public class TestConfig {


    ZooKeeper zk;


    @Before
    public void conn (){
        zk  = ZKUtils.getZK();
    }

    @After
    public void close (){
        try {
            zk.close();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }


    @Test
    public void getConf(){

        WatchCallBack watchCallBack = new WatchCallBack();
        watchCallBack.setZk(zk);
        MyConf myConf = new MyConf();
        watchCallBack.setConf(myConf);

        watchCallBack.aWait();
        //1，节点不存在
        //2，节点存在

        while(true){

            if(myConf.getConf().equals("")){
                System.out.println("conf diu le ......");
                watchCallBack.aWait();
            }else{
                System.out.println(myConf.getConf());

            }

            try {
                Thread.sleep(200);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }

    }





}

由于是异步进行操作的，我们创建一个ZooKeeper对象之后，如果不进行阻塞操作的话，有可能还没有连接完成就执行后续的操作，所以这里我们用 CountDownLatch进行阻塞操作，当监测连接成功后，进行 countDown放行，执行后续的ZK的动作。

当我们连接成功 ZooKeeper 之后，我们需要通过 exists判断是否存在节点，存在就进行 getData操作。这里我们创建一个 WatchCallBack因为exists和getData都需要一个callback，所以除了实现Watcher以外还需要实现节点状态：AsyncCallback.StatCallback 数据监听：AsyncCallback.DataCallback


import org.apache.zookeeper.AsyncCallback;
import org.apache.zookeeper.WatchedEvent;
import org.apache.zookeeper.Watcher;
import org.apache.zookeeper.ZooKeeper;
import org.apache.zookeeper.data.Stat;

import java.util.concurrent.CountDownLatch;


public class WatchCallBack  implements Watcher ,AsyncCallback.StatCallback, AsyncCallback.DataCallback {

    ZooKeeper zk ;
    MyConf conf ;
    CountDownLatch cc = new CountDownLatch(1);

    public MyConf getConf() {
        return conf;
    }

    public void setConf(MyConf conf) {
        this.conf = conf;
    }

    public ZooKeeper getZk() {
        return zk;
    }

    public void setZk(ZooKeeper zk) {
        this.zk = zk;
    }


    public void aWait(){
        zk.exists("/AppConf",this,this ,"ABC");
        try {
            cc.await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
 
    /*
     * 
     * 实现DataCallback*/
    @Override
    public void processResult(int rc, String path, Object ctx, byte[] data, Stat stat) {

        if(data != null ){//不为空 节点已经存在
            String s = new String(data);
            conf.setConf(s);
            cc.countDown();
        }


    }

    /*
     * 实现StatCallback*/
    @Override
    public void processResult(int rc, String path, Object ctx, Stat stat) {
        if(stat != null){
            zk.getData("/AppConf",this,this,"sdfs");
        }

    }

    /*实现Watcher接口的方法
     * 
     * */
    @Override
    public void process(WatchedEvent event) {

        switch (event.getType()) {
            case None:
                break;
            case NodeCreated:
                zk.getData("/AppConf",this,this,"sdfs");

                break;
            case NodeDeleted:
                //容忍性
                conf.setConf("");
                cc = new CountDownLatch(1);
                break;
            case NodeDataChanged:
                zk.getData("/AppConf",this,this,"sdfs");

                break;
            case NodeChildrenChanged:
                break;
        }

    }
}

当前面准备好了之后，我们可以编写测试用例了：

ZKUtils 工具类

import org.apache.zookeeper.ZooKeeper;
import java.util.concurrent.CountDownLatch;

public class ZKUtils {

    private  static ZooKeeper zk;

    private static String address = "127.0.0.1:2181/testLock";

    private static DefaultWatch watch = new DefaultWatch();

    private static CountDownLatch init  =  new CountDownLatch(1);
    public static ZooKeeper  getZK(){

        try {
            zk = new ZooKeeper(address,1000,watch);
            watch.setCc(init);
            init.await();

        } catch (Exception e) {
            e.printStackTrace();
        }

        return zk;
    }


}

努力的布布

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
七、Zookeeper分布式协调配置实现

对于刚开始的时候，很多公司的服务器可能是由单个组成，但是随着业务的发展，单一节点的服务无法满足业务的飞速发展，后面就出现了分布式、集群的概念，到了现在形成的微服务，技术的改进能够更好的满足业务的需要。假设我们线上有很多个微服务分布在不同的服务器上，其中一个微服务，我们就叫它 goods-service，当 goods-service的IP地址需要变更的时候，但是 goods-service又对很多其他的程序提供了服务，这个时候如果没有一个统一配置的东西，每一个应用到 goods-service的应用程序都要
复制链接

扫一扫