dubbo源码解析-zookeeper创建节点

前言

在之前dubbo源码解析-本地暴露中的前言部分提到了两道高频的面试题,其中一道dubbo中zookeeper做注册中心,如果注册中心集群都挂掉,那发布者和订阅者还能通信吗?在上周的dubbo源码解析-zookeeper连接中已经讲到,这周解析的是另一道,即服务提供者能实现失效踢出是根据什么原理?

上周就有朋友问到我,为什么我的源码解析总是偏偏要和面试题挂上钩呢?原因很简单

1.dubbo源码这么多,试问你从哪里做为切入点?也就是说该从哪里看起?所以以面试题为切入点,你可以理解为我是在回答"怎么看源码"这个问题.

2.我们研发飞机大炮并不是为了侵略,有时候可能只是单纯的想保护自己.

3.我的源码解析虽然以面试题为基础,但却不以面试为目的.因为面试如果问到dubbo的问题,绝大多数都是官方文档的内容,根本就没到需要看源码的程度.看源码的最终目的是为了解决实际问题,后面我会以实际的问题为例子,实战讲一讲看源码我究竟解决了什么网上搜不到,必须要看源码才能弄清楚的问题.所以现在就可以大胆在简书关注肥朝,已免后面错过精彩内容.

插播面试题

  • 服务提供者能实现失效踢出是什么原理(高频题)
  • zookeeper的有哪些节点,他们有什么区别?讲一下应用场景

直入主题

同上周的zookeeper连接一样,这周我们讲的还是一行代码,如下图

那么我们打上断点开始

下面就要开始创建节点了

现在我们虽然看完源码了,但是还是没法回答面试题?那么下面就要敲黑板划重点了

敲黑板画重点

zookeeper中节点是有生命周期的.具体的生命周期取决于节点的类型.节点主要分为持久节点(Persistent)临时节点(Ephemeral),但是更详细的话还可以加上时序节点(Sequential),创建节点中往往组合使用,因此也就是4种.

  • 持久节点
  • 持久顺序节点
  • 临时节点
  • 临时顺序节点

其实不要纠结于分为几种,这就和语文的断句一样,你断句的方法不同,断出来的结果也不同.那么我们主要讲讲持久节点临时节点的区别

持久节点

所谓持久节点,是指在节点创建后,就一直存在,直到有删除操作来主动清除这个节点,也就是说不会因为创建该节点的客户端会话失效而消失

临时节点

临时节点的生命周期和客户端会话绑定,也就是说,如果客户端会话失效,那么这个节点就会自动被清除掉

应用场景

zookeeper常用的应用场景我在上周已经画了思维导图,这里就不重复展示了.就拿分布式协调/通知来举例(这个例子既是在回答第一个面试题,也是在回答第二个面试题).

在分布式系统中,我们常常需要知道某个机器是否可用,传统的开发中,可以通过Ping某个主机来实现,Ping得通说明对方是可用的,相反是不可用的,ZK 中我们让所有的机其都注册一个临时节点,我们判断一个机器是否可用,我们只需要判断这个节点在ZK中是否存在就可以了,不需要直接去连接需要检查的机器,降低系统的复杂度

写在最后

集群容错后,服务发布的内容讲得也差不多了.下周来和大家一起对服务发布做一个总结.期待下周继续与你相遇.鉴于本人才疏学浅,不对的地方还望斧正,也欢迎关注我的简书,名称为肥朝

dubbo使用的 zkclient 会自动给 zookeeper发送心跳检测的

18:29:10.363 [main-SendThread(114.67.228.245:2181)] DEBUG org.apache.zookeeper.ClientCnxn - Got ping response for sessionid: 0x165add7ce0d000e after 9ms
18:29:20.363 [main-SendThread(114.67.228.245:2181)] DEBUG org.apache.zookeeper.ClientCnxn - Got ping response for sessionid: 0x165add7ce0d000e after 9ms
18:29:30.366 [main-SendThread(114.67.228.245:2181)] DEBUG org.apache.zookeeper.ClientCnxn - Got ping response for sessionid: 0x165add7ce0d000e after 9ms
18:29:40.369 [main-SendThread(114.67.228.245:2181)] DEBUG org.apache.zookeeper.ClientCnxn - Got ping response for sessionid: 0x165add7ce0d000e after 11ms
18:29:50.366 [main-SendThread(114.67.228.245:2181)] DEBUG org.apache.zookeeper.ClientCnxn - Got ping response for sessionid: 0x165add7ce0d000e after 8ms
18:30:00.369 [main-SendThread(114.67.228.245:2181)] DEBUG org.apache.zookeeper.ClientCnxn - Got ping response for sessionid: 0x165add7ce0d000e after 9ms
18:30:10.370 [main-SendThread(114.67.228.245:2181)] DEBUG org.apache.zookeeper.ClientCnxn - Got ping response for sessionid: 0x165add7ce0d000e after 9ms

测试发送心跳代码 会自动打印出debug的日志

package com.TestZookeeper;

import org.I0Itec.zkclient.IZkDataListener;
import org.I0Itec.zkclient.ZkClient;

public class ZookerProgram {
    //zookeeper连接地址
    private static final String CONNECT_ADR="XX.XX.XX.XX:2181";

    public static void main(String[]args)  throws Exception{
        ZkClient zkClient = new ZkClient(CONNECT_ADR,5000);
        String path="/qq";
   System.out.println("链接成功");
   zkClient.createEphemeral(path,"contentaaa");

        System.out.println("创建临时节点成功");
      //  String msg=   zkClient.getChildren("/qq");

        zkClient.subscribeDataChanges(path, new IZkDataListener() {
            public void handleDataDeleted(String dataPath) throws Exception {
                System.out.println("Node " + dataPath + " deleted.");
            }
            public void handleDataChange(String dataPath, Object data) throws Exception {
                System.out.println("Node " + dataPath + " changed, new data: " + data);
            }
        });
      System.out.println("关闭前:"+zkClient.getCreationTime(path));
//       zkClient.close();
//        System.out.println("关闭后:"+zkClient.getCreationTime(path));
      // zkClient.writeData(path,"456");
     //   Thread.sleep(1000);
     //   zkClient.delete(path);
       Thread.sleep( Integer.MAX_VALUE );

    }
    }

原文地址:https://www.cnblogs.com/tiancai/p/9600197.html

时间: 2024-11-08 07:08:42

dubbo源码解析-zookeeper创建节点的相关文章

Dubbo源码解析之SPI(一):扩展类的加载过程

Dubbo是一款开源的.高性能且轻量级的Java RPC框架,它提供了三大核心能力:面向接口的远程方法调用.智能容错和负载均衡,以及服务自动注册和发现. Dubbo最早是阿里公司内部的RPC框架,于 2011 年开源,之后迅速成为国内该类开源项目的佼佼者,2018年2月,通过投票正式成为 Apache基金会孵化项目.目前宜信公司内部也有不少项目在使用Dubbo. 本系列文章通过拆解Dubbo源码,帮助大家了解Dubbo,做到知其然,并且知其所以然. 一.JDK SPI 1.1 什么是SPI? S

浅谈RxJava源码解析(观察者),创建(create、from、just),变换(Map、flatMap)、线程调度

一.创建操作: 1.观察者模式:RxJava的世界里,我们有四种角色: Observable<T>(被观察者).Observer(观察者) Subscriber(订阅者).Subject Observable和Subject是两个"生产"实体,Observer和Subscriber是两个"消费"实体.Observable 和 Observer 通过 subscribe() 方法实现订阅关系,从而 Observable 可以在需要的时候发出事件来通知 Ob

【Dubbo 源码解析】02_Dubbo SPI

Dubbo SPI:(version:2.6.*) Dubbo 微内核 + 插件 模式,得益于 Dubbo SPI .其中 ExtentionLoader是 Dubbo SPI 最核心的类,它负责扩展点的加载和生命周期管理. ExtensionLoader ExtensionLoader 类似于 Java SPI 的 ServiceLoader,负责扩展的加载和生命周期维护,它是 Dubbo SPI 最核心的类. 使用最频繁的 API 有如下几个: public static <T> Exte

【Dubbo 源码解析】03_Dubbo Protocol&amp;Filter

Protocol & Filter Dubbo 服务暴露和服务引用都是通过的 com.alibaba.dubbo.rpc.Protocol 来实现的.它是一个 SPI 扩展. @SPI("dubbo") public interface Protocol { int getDefaultPort(); @Adaptive <T> Exporter<T> export(Invoker<T> invoker) throws RpcExceptio

【Dubbo 源码解析】06_Dubbo 服务调用

Dubbo 服务调用 根据上图,可以看出,服务调用过程为: Consumer 端的 Proxy 调用 Cluster 层选择集群中的某一个 Invoker(负载均衡) Invoker 最终会调用 Protocol 层进行 RPC 通讯(netty,tcp 长连接),将服务调用信息和配置信息进行传递 Provider 端 Protocol 层接收到服务调用信息后,最终会调用真实的服务实现 Consumer 端调用过程 通过前面 Dubbo 服务发现&引用 的学习,我们知道,Consumer 端的调

【Dubbo 源码解析】07_Dubbo 重试机制

Dubbo 重试机制 通过前面 Dubbo 服务发现&引用 的分析,我们知道,Dubbo 的重试机制是通过 com.alibaba.dubbo.rpc.cluster.support.FailoverClusterInvoker 来实现的: public Result doInvoke(Invocation invocation, final List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcExce

【Dubbo 源码解析】08_Dubbo与Spring结合

Dubbo 与 Spring 结合 基于 dubbo.jar 内的 META-INF/spring.handlers 配置,Spring 在遇到 dubbo 名称空间时,会回调 DubboNamespaceHandler. 所有 dubbo 的标签,都统一用 DubboBeanDefinitionParser 进行解析,基于一对一属性映射,将 XML 标签解析为 Bean 对象. 在 ServiceConfig.export() 或 ReferenceConfig.get() 初始化时,将 Be

【Dubbo 源码解析】01_Dubbo 设计简介

Dubbo 设计简介 Dubbo 采用 Microkernel + Plugin (微内核 + 插件)模式,Microkernel 只负责组装 Plugin,Dubbo 自身的功能也是通过扩展点实现的,也就是 Dubbo 的所有功能点都可被用户自定义扩展所替换. Dubbo 的核心领域模型 Protocol 是服务域,它是 Invoker 暴露和引用的主功能入口,它负责 Invoker 的生命周期管理. Invoker 是实体域,它是 Dubbo 的核心模型,其它模型都向它靠扰,或转换成它,它代

rocketmq源码解析之NamesrvController创建

说在前面 本次开始进行rocketmq源码解析,比较喜欢rocketmq的架构设计,rocketmq内嵌了namesrv注册中心保存了元数据,进行负载均衡.容错的一些处理,4.3以上支持消息事务,有管理控制台.命令行工具,底层namesrv与broker.client与server交互netty实现. 源码解析 创建NamesrvController,进入这个方法org.apache.rocketmq.namesrv.NamesrvStartup#main,再进入这个方法org.apache.r