zookeeper学习心得一:基础讲解---zk节点类型以及对节点的相应操作

本文深入解析Zookeeper中的四种节点类型:持久节点、持久顺序节点、临时节点和临时顺序节点,阐述各自特点及应用场景,尤其针对分布式锁实现进行详细说明。

zookeeper节点类型

    持久节点(PERSISTENT)
    所谓持久节点,是指在节点创建后,就一直存在,直到有删除操作来主动清除这个节点——不会因为创建该节点的客户端会话失效而消失。
    持久顺序节点(PERSISTENT_SEQUENTIAL)
    这类节点的基本特性和上面的节点类型是一致的。额外的特性是,在ZK中,每个父节点会为他的第一级子节点维护一份时序,会记录每个子节点创建的先后顺序。基于这个特性,在创建子节点的时候,可以设置这个属性,那么在创建节点过程中,ZK会自动为给定节点名加上一个数字后缀,作为新的节点名。这个数字后缀的范围是整型的最大值。
    在创建节点的时候只需要传入节点 “/test_”,这样之后,zookeeper自动会给”test_”后面补充数字。
    临时节点(EPHEMERAL)
    和持久节点不同的是,临时节点的生命周期和客户端会话绑定。也就是说,如果客户端会话失效,那么这个节点就会自动被清除掉。注意,这里提到的是会话失效,而非连接断开。另外,在临时节点下面不能创建子节点。
    这里还要注意一件事,就是当你客户端会话失效后,所产生的节点也不是一下子就消失了,也要过一段时间,大概是10秒以内,可以试一下,本机操作生成节点,在服务器端用命令来查看当前的节点数目,你会发现客户端已经stop,但是产生的节点还在。
    临时顺序节点(EPHEMERAL_SEQUENTIAL)
    此节点是属于临时节点,不过带有顺序,客户端会话结束节点就消失。下面是一个利用该特性的分布式锁的案例流程。
    (1)客户端调用create()方法创建名为“locknode/
    guid-lock-”的节点,需要注意的是,这里节点的创建类型需要设置为EPHEMERAL_SEQUENTIAL。
    (2)客户端调用getChildren(“locknode”)方法来获取所有已经创建的子节点,注意,这里不注册任何Watcher。
    (3)客户端获取到所有子节点path之后,如果发现自己在步骤1中创建的节点序号最小,那么就认为这个客户端获得了锁。
    (4)如果在步骤3中发现自己并非所有子节点中最小的,说明自己还没有获取到锁。此时客户端需要找到比自己小的那个节点,然后对其调用exist()方法,同时注册事件监听。
    (5)之后当这个被关注的节点被移除了,客户端会收到相应的通知。这个时候客户端需要再次调用getChildren(“locknode”)方法来获取所有已经创建的子节点,确保自己确实是最小的节点了,然后进入步骤3。
---------------------
作者:荷马先生
来源:优快云
原文:https://blog.youkuaiyun.com/randompeople/article/details/70500076
版权声明:本文为博主原创文章,转载请附上博文链接!

--- kind: Deployment apiVersion: apps/v1 metadata: name: kafka annotations: {} spec: replicas: 1 selector: matchLabels: app: kafka template: metadata: creationTimestamp: null labels: app: kafka spec: volumes: - name: kafka-data hostPath: path: /data/local/kafka/kafka_data type: '' containers: - name: kafka image: >- showcon-registry-registry.cn-hangzhou.cr.aliyuncs.com/library/kafka:2.13-2.7.0 ports: - containerPort: 9092 protocol: TCP env: - name: KAFKA_LISTENERS value: 'PLAINTEXT://0.0.0.0:9092' - name: KAFKA_ADVERTISED_LISTENERS value: 'PLAINTEXT://kafka-svc:9092' - name: KAFKA_ZOOKEEPER_CONNECT value: 'zookeeper:2181' - name: KAFKA_BROKER_ID value: '0' - name: KAFKA_AUTO_CREATE_TOPICS_ENABLE value: 'true' resources: requests: cpu: 125m memory: 512Mi volumeMounts: - name: kafka-data mountPath: /bitnami terminationMessagePath: /dev/termination-log terminationMessagePolicy: File imagePullPolicy: IfNotPresent restartPolicy: Always terminationGracePeriodSeconds: 30 dnsPolicy: ClusterFirst securityContext: {} imagePullSecrets: - name: regsecret schedulerName: default-scheduler strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 25% maxSurge: 25% revisionHistoryLimit: 10 progressDeadlineSeconds: 600 --- kind: Deployment apiVersion: apps/v1 metadata: name: zookeeper annotations: {} spec: replicas: 1 selector: matchLabels: app: zookeeper template: metadata: creationTimestamp: null labels: app: zookeeper spec: volumes: - name: zookeeper-data hostPath: path: /data/local/kafka/zookeeper_data type: '' containers: - name: zookeeper image: >- showcon-registry-registry.cn-hangzhou.cr.aliyuncs.com/library/zookeeper:3.4.13 ports: - containerPort: 2181 protocol: TCP resources: requests: cpu: 125m memory: 256Mi volumeMounts: - name: zookeeper-data mountPath: /opt/zookeeper-3.4.13/data terminationMessagePath: /dev/termination-log terminationMessagePolicy: File imagePullPolicy: IfNotPresent restartPolicy: Always terminationGracePeriodSeconds: 30 dnsPolicy: ClusterFirst securityContext: {} imagePullSecrets: - name: regsecret schedulerName: default-scheduler strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 25% maxSurge: 25% revisionHistoryLimit: 10 progressDeadlineSeconds: 600 --- kind: Service apiVersion: v1 metadata: name: kafka-svc labels: name: kafka annotations: {} spec: ports: - name: kafka-port protocol: TCP port: 9092 targetPort: 9092 selector: app: kafka type: ClusterIP sessionAffinity: None --- kind: Service apiVersion: v1 metadata: name: zookeeper labels: app: zookeeper spec: ports: - name: client protocol: TCP port: 2181 targetPort: 2181 - name: follower protocol: TCP port: 2888 targetPort: 2888 - name: leader protocol: TCP port: 3888 targetPort: 3888 selector: app: zookeeper type: ClusterIP sessionAffinity: None 分析下这个配置文件,如果我要将zookeeper类型改为headless 我需要怎么改
最新发布
09-17
在Kubernetes环境中,将Zookeeper服务类型改为headless服务,可按如下步骤操作。 首先要理解headless服务的特性,它不分配Cluster IP,而是通过域名直接解析到后端Pod的IP地址,常用于需要直接访问Pod网络层的场景,如Zookeeper节点间通信。 以下是将Zookeeper服务类型改为headless服务的具体修改方法: ### 定义Headless Service 定义个Headless Service来实现节点间通信,在配置文件中添加如下内容: ```yaml apiVersion: v1 kind: Service metadata: name: zk-headless labels: app: zookeeper spec: clusterIP: None # 设置为None以创建Headless Service ports: - port: 2888 name: server - port: 3888 name: election selector: app: zookeeper ``` ### 部署StatefulSet 使用StatefulSet来保证节点顺序性和持久化存储,配置如下: ```yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: zk spec: serviceName: zk-headless # 关联到上面创建的Headless Service replicas: 3 template: metadata: labels: app: zookeeper spec: containers: - name: zk image: zookeeper:3.8.0 env: - name: ZOO_MY_ID value: "$(POD_NAME.split('-')[1])" - name: ZOO_SERVERS valueFrom: configMapKeyRef: name: zk-config key: servers ``` 在上述配置中,`clusterIP: None` 是将服务定义为Headless Service的关键配置。`serviceName: zk-headless` 则将StatefulSet与Headless Service关联起来,确保Pod能通过Headless Service进行通信。 ### 扩缩容操作 若后续需要对Zookeeper进行扩缩容,以扩容到4节点为例,可使用如下命令: ```bash kubectl patch zk zookeeper --type='json' -p='[{"op":"replace","path":"/spec/replicas","value":4}]' ``` 通过上述步骤,就可以将Zookeeper服务类型改为headless服务,实现节点间的有效通信和扩缩容操作 [^1][^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值