zkclient

作者：潘吉祥 要说最开始接触zookeeper，已经是很久很久以前了，应该是学习dubbo的时候了解的，简单地安装、启动一下，作为dubbo的注册中心。 那个时候觉得挺神奇的，居然能服务注册与发现！但是也仅限于这样的感觉，因为我觉得具体实现对于我来说太遥远了，那种感觉就像我在学习Java基础的时候听到负载均衡、集群这类概念。这么说可能还是没有确切地表达出那种感觉，尤其是作为一个文科生而言。 虽说如此，但是我还是有些不自量力地在简历上写了“熟悉zookeeper”……当然了，打脸的时候总会出现，只是迟早问题，大概一年后：那你说说zk有几种节点类型？我…… 不争馒头争口气，自己挖的坑自己得填好，这下怎么也得深入了解一下了。大概也是自己视野开阔的原因，此时抛开zookeeper不说，仔细想想注册中心简单点来说也就是存放对应关系的一个容器而已，再简单点就是一个map映射。有了思路，深入学了学zookeeper，于是开始试着把自己的服务注册到zookeeper。 这里关于zookeeper的知识就不再赘述，你可以把他当做一个存放键值对的数据库，当然zookeeper的功能远不限此。我们直接进入正题：把自己的服务注册到zookeeper并实现负载均衡（关于节点的操作不懂得小伙伴可以先学习一下zookeeper的基本操作）。 开拔之前我们先来理一下思路，这往往是最重要的：

背景 最近接的一个项目是基于公司产品Starring做的微服务支付平台，纯后台项目，实现三方支付公司和银行接口来完成用户账户扣款，整合成通用支付接口发布给前端调用。 但是扯蛋了，这边前端什么都不想做，只想我们提供一个链接，用户可以选择支付方式进行支付，这样的话相当于咱们又得起一个WEB版的收银台Project。 最近SpringBoot挺流行的，那就单独给起一个H5项目跑几个页面，调用后台的支付接口就完事了，如下？ 最终的系统架构成了这样吧，随便画一画，请客官别吐槽。 公司的产品的服务都是发布到Zookeeper注册中心的，结果我们SpringBoot收银台成了直连某个IP端口，要是交易量一起来把直连的12001压垮了怎么办？ 这样显然会存在问题，就因为一个收银台项目把整个微服务支付平台变成了单节点，所以我们收银台SpringBoot项目也必须连到上面的ZK中去查找平台服务。 环境 SpringBoot 2.2.1.Release 解决思路 从单web项目转成基于zookeeper调用的微服务项目： 1、Registry：服务注册，公司产品Starring 采取Zookeeper 作为我们的注册中心，我们现在要做的就是订阅服务。 2、Provider：服务提供者（生产者），提供具体的服务实现，这个是支付后台提供的服务。 3、Consumer：消费者，从注册中心中订阅服务

分布式锁三种实现方式： 1. 基于数据库实现分布式锁； 2. 基于缓存（Redis等）实现分布式锁； 3. 基于Zookeeper实现分布式锁； 一， 基于数据库实现分布式锁 1. 悲观锁 利用select … where … for update 排他锁 注意: 其他附加功能与实现一基本一致，这里需要注意的是“where name=lock ”，name字段必须要走索引，否则会锁表。有些情况下，比如表不大，mysql优化器会不走这个索引，导致锁表问题。 2. 乐观锁 所谓乐观锁与前边最大区别在于基于CAS思想，是不具有互斥性，不会产生锁等待而消耗资源，操作过程中认为不存在并发冲突，只有update version失败后才能觉察到。我们的抢购、秒杀就是用了这种实现以防止超卖。 通过增加递增的版本号字段实现乐观锁 二， 基于缓存（Redis等）实现分布式锁 1. 使用命令介绍： （1）SETNX SETNX key val：当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不做，返回0。 （2）expire expire key timeout：为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。 （3）delete delete key：删除key 在使用Redis实现分布式锁的时候，主要就会使用到这三个命令。 2

持续更新内容涵盖：Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Spring、Spring Boot、Spring Cloud、RabbitMQ、Kafka、 Linux 等技术栈（滴滴滴.会持续更新哦，记得点赞、关注、分享三连击哈）. 1. ZooKeeper 面试题？ ZooKeeper 是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群 中各个节点的状态根据节点提交的反馈进行下一步合理操作。 最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名 服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能. Zookeeper 保证了如下分布式一致性特性 ： 1、顺序一致性 2、原子性 3、单一视图 4、可靠性 5、实时性（最终一致性） 客户端的读请求可以被集群中的任意一台机器处理， 如果读请求在节点上注册了 监听器，这个监听器也是由所连接的 zookeeper 机器来处理 。 对于写请求，这些 请求会同时发给其他 zookeeper 机器并且达成一致后，请求才会返回成功. 因此， 随着 zookeeper 的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。

持续更新内容涵盖：Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Spring、Spring Boot、Spring Cloud、RabbitMQ、Kafka、 Linux 等技术栈（滴滴滴.会持续更新哦，记得点赞、关注、分享三连击哈）. 1. ZooKeeper 面试题？ ZooKeeper 是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群 中各个节点的状态根据节点提交的反馈进行下一步合理操作。 最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名 服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能. Zookeeper 保证了如下分布式一致性特性 ： 1、顺序一致性 2、原子性 3、单一视图 4、可靠性 5、实时性（最终一致性） 客户端的读请求可以被集群中的任意一台机器处理， 如果读请求在节点上注册了 监听器，这个监听器也是由所连接的 zookeeper 机器来处理 。 对于写请求，这些 请求会同时发给其他 zookeeper 机器并且达成一致后，请求才会返回成功. 因此， 随着 zookeeper 的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。

导读 真是有人( 锁 )的地方就有江湖( 事务 )，今天不谈江湖，来撩撩人。 分布式锁的概念、为什么使用分布式锁，想必大家已经很清楚了。前段时间作者写过Redis是如何实现分布式锁，今天这篇文章来谈谈Zookeeper是如何实现分布式锁的。 陈某今天分别从如下几个方面来详细讲讲ZK如何实现分布式锁： ZK的四种节点 排它锁的实现 读写锁的实现 Curator实现分步式锁 ZK的四种节点 持久性节点：节点创建后将会一直存在 临时节点：临时节点的生命周期和当前会话绑定，一旦当前会话断开临时节点也会删除，当然可以主动删除。 持久有序节点：节点创建一直存在，并且zk会自动为节点加上一个自增的后缀作为新的节点名称。 临时有序节点：保留临时节点的特性，并且zk会自动为节点加上一个自增的后缀作为新的节点名称。 排它锁的实现 排他锁的实现相对简单一点，利用了 zk的创建节点不能重名的特性 。如下图： 根据上图分析大致分为如下步骤： 尝试获取锁：创建 临时节点 ，zk会保证只有一个客户端创建成功。 创建临时节点成功，获取锁成功，执行业务逻辑，业务执行完成后删除锁。 创建临时节点失败，阻塞等待。 监听删除事件，一旦临时节点删除了，表示互斥操作完成了，可以再次尝试获取锁。 递归：获取锁的过程是一个递归的操作， 获取锁->监听->获取锁 。 如何避免死锁 ：创建的是临时节点

zookeeper 注册中心 Zookeeper 是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用 [1]。 流程说明： 服务提供者启动时: 向 /dubbo/com.foo.BarService/providers 目录下写入自己的 URL 地址 服务消费者启动时: 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者 URL 地址。并向 /dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址 监控中心启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者 URL 地址。 支持以下功能： 当提供者出现断电等异常停机时，注册中心能自动删除提供者信息 当注册中心重启时，能自动恢复注册数据，以及订阅请求 当会话过期时，能自动恢复注册数据，以及订阅请求 当设置 <dubbo:registry check="false" /> 时，记录失败注册和订阅请求，后台定时重试 可通过 <dubbo:registry username="admin" password="1234" /> 设置 zookeeper 登录信息 可通过 <dubbo:registry

起因 最近在做多租户改造，租户使用的配置项都要放到zk上（如数据库配置、redis配置、阿里oss配置、每个租户的域名配置等），每个子系统去zk读取配置。当配置信息改变时，通过zk的watch机制，给子系统发消息，子系统接收到消息之后，再去做相应的处理（如：租户1的数据库配置变了，就重新创建数据库连接池）。 图1：系统关系逻辑及问题描述 问题描述： 主要是只读的那些zkClient，不用账号密码，就能读(r)到zk上的数据。而不是给子系统分配账号密码。 子系统访问zk的时候，是不能带账号密码的。 如果用digest 给子系统分配统一的一个账号密码，在代码的层面是可以实现的。 但是老大要求，子系统访问zk的时候，不能带着密码。而且，只能有读(r)权限。 思路 注：这5种权限中，delete是指对子节点的删除权限，其它4种权限指对自身节点的操作权限 使用命令看一下world的权限是cdrwa（也就是anyone拥有所有权限） 所以，突然想到，能不能把world身份认证方式的默认权限设置成r，而admin的账号分配给crdwa权限。 于是使用代码： public void set(String path, String data) { createPathIfNotExists(path); zkClient.writeData(path, data); } /** *

上一篇实现了基于zookeeper集群实现的分布式配置中心的工程样例，并进行了总结，本篇进行基于zookeeper集群实现的分布式锁工程案例，当然也借鉴和参考了其他博客，这里先给出引用：https://blog.csdn.net/hongtaolong/article/details/88898875 一、定义上下文锁的抽象对象 package com . coderman . zookeeper . clusterdemo . distributelockdemo ; /** * @description: * @author: Fanchunshuai * @time: 2020/2/15 16:04 * 定义一个bean对象表示需要用锁的场景的上下文数据模型 * 分布式锁可能需要定义持久化节点和临时节点，以及临时顺序节点 * 这里假定持久化节点为：/group/appName * 临时节点为：/group/appName/lockPath * 临时顺序节点：/group/appName/lockPath0000000000001 */ public class LockConfigBean { /** * 集群节点目录一级分组 */ private String group ; /** * 集群中的应用名称 */ private String appName ; /** *

上一篇文章说到了一些zookeeper的应用场景，本篇将是对这些场景进行代码模拟实战的开篇文章。之前已经在本地搭建起了zk集群，并进行了一些api实践，因此本章主要讲述如何使用zk客户端模拟一个配置中心，推送变更的场景。 初始化配置bean package com . coderman . zookeeper . clusterdemo . configdemo ; import java . io . Serializable ; /** * @description: * @author: Fanchunshuai * @time: 2020/2/13 15:04 * zookeeper目录规则：/group/ip/appName * 这里的对象需要实现序列化 */ public class ServerConfigBean implements Serializable { /** * 集群节点目录一级分组 */ private String group ; /** * 集群节点数据内容 */ private String nodeData ; /** * 集群ip */ private String ip ; /** * 集群中的应用名称 */ private String appName ; public String getGroup ( ) { return