分布式利器Zookeeper(二):分布式锁原生API操作ZK Watch机制 分布式锁思路

《分布式利器Zookeeper(一)》中对ZK进行了初步的介绍以及搭建ZK集群环境,本篇博客将涉及的话题是:基于原生API方式操作ZK,Watch机制,分布式锁思路探讨等。

原生API操作ZK 

什么叫原生API操作ZK呢?实际上,利用zookeeper.jar这样的就是基于原生的API方式操作ZK,因为这个原生API使用起来并不是让人很舒服,于是出现了zkclient这种方式,以至到后来基于Curator框架,让人使用ZK更加方便。有一句话,Guava is to JAVA what Curator is to Zookeeper。

连接ZK的方式

说明: 在初始化Zookeeper时,有多种构造方法可以选择,有3个参数是必备的:connectionString(多个ZK SERVER之间以,分隔),sessionTimeout(就是zoo.cfg中的tickTime),Watcher(事件处理通知器)。 需要注意的是ZK的连接是异步的,因此我们需要CountDownLatch来帮助我们确保ZK初始化完成。 对于事件(WatchedEvent)而言,有状态以及类型。

事件状态及事件类型

下面,我们来看一看基于原生API方式的增删改查:

create

注意,节点有2大类型,持久化节点、临时节点。在此基础上,又可以分为持久化顺序节点(PERSISTENT_SEQUENTIAL)、临时顺序节点(EPHEMERAL_SEQUENTIAL)。 节点类型只支持byte[],也就是说我们是无法直接给一个对象给ZK,让ZK帮助我们完成序列化操作的!

get/delete

这里需要注意的是,原生API对于ZK的操作其实是分为同步和异步2种方式的。 rc表示return code,就是返回码,0即为正常。 path是传入API的参数,ctx也是传入的参数。 注意在删除过程中,是需要版本检查的,所以我们一般提供-1跳过版本检查机制。

Watch机制

ZK有watch事件,是一次性触发的。当watch监控的数据发生变化,会通知设置了该监控的client,即watcher。Zookeeper的watch是有自己的一些特性的: 一次性:请牢记,just watch one time! 因为ZK的监控是一次性的,所以每次必须设置监控。 轻量:WatchedEvent是ZK进行watch通知的最小单元,整个数据结构包含:事件状态、事件类型、节点路径。注意ZK只是通知client节点的数据发生了变化,而不会直接提供具体的数据内容。 客户端串行执行机制:注意客户端watch回调的过程是一个串行同步的过程,这为我们保证了顺序,我们也应该意识到不能因一个watch的回调处理逻辑而影响了整个客户端的watch回调。

下面我们来直接看代码:

提供Watcher的实现

提供process方法

main

一定得注意的是,监控该节点和监控该节点的子节点是2码子事。 比如exists(path,true)监控的就是该path节点的create/delete/setData;getChildren(path,watcher)监控的就是该path节点下的子节点的变化(子节点的创建、修改、删除都会监控到,而且事件类型都是一样的,想一想如何区分呢?给一个我的思路,就是我们得先有该path下的子节点的列表,然后watch触发后,我们对比下该path下面的子节点SIZE大小及内容,就知道是增加的是哪个子节点,删除的是哪个子节点了!) getChildren(path,true)和getChildren(path,watcher)有什么区别?前者是沿用上下文中的Watcher,而后者则是可以设置一个新的Watcher的!(因此,要想做到一直监控,那么就有2种方式,一个是注意每次设置成true,或者干脆每次设置一个新的Watcher) 从上面的讨论中,你大概能了解到原生的API其实功能上还不是很强大,有些还得我们去操心,到后面为大家介绍Curator框架,会有更好的方式进行处理。

分布式锁思路

首先,我们不谈Zookeeper是如何帮助我们处理分布式锁的,而是先来想一想,什么是分布式锁?为什么需要分布式锁?有哪些场景呢?分布式锁的使用又有哪些注意的?分布式锁有什么特性呢? 说起锁,我们自然想到Java为我们提供的synchronized/Lock,但是这显然不够,因为这只能针对一个JVM中的多个线程对共享资源的操作。那么对于多台机器,多个进程对同一类资源进行操作的话,就是所谓分布式场景下的锁。 各个电商平台经常搞的“秒杀”活动需要对商品的库存进行保护、12306火车票也不能多卖,更不允许一张票被多个人买到、这样的场景就需要分布式锁对共享资源进行保护! 既然,Java在分布式场景下的锁已经无能为力,那么我们只能借助其他东西了!

我们的老朋友:DB

对,没错,我们能否借助DB来实现呢?要知道DB是有一些特点供我们利用的,比如DB本身就存在锁机制(表锁、行锁),唯一约束等等。

假设,我们的DB中有一张表T(id,methodname,ip,threadname,......),其中id为主键,methodname为唯一索引。 对于多台机器,每台机器上的多个线程而言,对一个方法method进行操作前,先select下T表中是否存在method这条记录,如果没有,就插入一条记录到T中。当然可能并发select,但是由于T表的唯一约束,使得只有一个请求能插入成功,即获得锁。至于释放锁,就是方法执行完毕后delete这条记录即可。 考虑一些问题:如果DB挂了,怎么办?如果由于一些因素,导致delete没有执行成功,那么这条记录会导致该方法再也不能被访问!为什么要先select,为什么不直接insert呢?性能如何呢? 为了避免单点,可以主备之间实现切换;为了避免死锁的产生,那么我们可以有一个定时任务,定期清理T表中的记录;先select后insert,其实是为了保证锁的可重入性,也就是说,如果一台IP上的某个线程获取了锁,那么它可以不用在释放锁的前提下,继续获得锁;性能上,如果大量的请求,将会对DB考验,这将成为瓶颈。 到这里,还有一个明显的问题,需要我们考虑:上述的方案,虽然保证了只会有一个请求获得锁,但其他请求都获取锁失败返回了,而没有进行锁等待!当然,我们可以通过重试机制,来实现阻塞锁,不过数据库本身的锁机制可以帮助我们完成。别忘了select ... for update这种阻塞式的行锁机制,commit进行锁的释放。而且对于for update这种独占锁,如果长时间不提交释放,会一直占用DB连接,连接爆了,就跪了! 不说了,老朋友也只能帮我们到这里了!

我们的新朋友:Redis or 其他分布式缓存(Tair/...)

既然说是缓存,相较DB,有更好的性能;既然说是分布式,当然避免了单点问题; 比如,用Redis作为分布式锁的setnx,这里我就不细说了,总之分布式缓存需要特别注意的是缓存的失效时间。(有效时间过短,搞不好业务还没有执行完毕,就释放锁了;有效时间过长,其他线程白白等待,浪费了时间,拖慢了系统处理速度)

看Zookeeper是如何帮助我们实现分布式锁

Zookeeper中临时顺序节点的特性: 第一,节点的生命周期和client回话绑定,即创建节点的客户端回话一旦失效,那么这个节点就会被删除。(临时性) 第二,每个父节点都会维护子节点创建的先后顺序,自动为子节点分配一个整形数值,以后缀的形式自动追加到节点名称中,作为这个节点最终的节点名称。(顺序性)

那么,基于临时顺序节点的特性,Zookeeper实现分布式锁的一般思路如下:

1.client调用create()方法创建“/root/lock_”节点,注意节点类型是EPHEMERAL_SEQUENTIAL 2.client调用getChildren("/root/lock_",watch)来获取所有已经创建的子节点,并同时在这个节点上注册子节点变更通知的Watcher 3.客户端获取到所有子节点Path后,如果发现自己在步骤1中创建的节点是所有节点中最小的,那么就认为这个客户端获得了锁 4.如果在步骤3中,发现不是最小的,那么等待,直到下次子节点变更通知的时候,在进行子节点的获取,判断是否获取到锁 5.释放锁也比较容易,就是删除自己创建的那个节点即可

上面的这种思路,在集群规模很大的情况下,会出现“羊群效应”(Herd Effect):

在上面的分布式锁的竞争中,有一个细节,就是在getChildren上注册了子节点变更通知Watcher,这有什么问题么?这其实会导致客户端大量重复的运行,而且绝大多数的运行结果都是判断自己并非是序号最小的节点,从而继续等待下一次通知,也就是很多客户端做了很多无用功。更加要命的是,在集群规模很大的情况下,这显然会对Server的性能造成影响,而且一旦同一个时间,多个客户端断开连接,服务器会向其余客户端发送大量的事件通知,这就是所谓的羊群效应!

出现这个问题的根源,其实在于,上述的思路并没有找准客户端的“痛点”:

客户端的核心诉求在于判断自己是否是最小的节点,所以说每个节点的创建者其实不用关心所有的节点变更,它真正关心的应该是比自己序号小的那个节点是否存在! 1.client调用create()方法创建“/root/lock_”节点,注意节点类型是EPHEMERAL_SEQUENTIAL 2.client调用getChildren("/root/lock_",false)来获取所有已经创建的子节点,这里并不注册任何Watcher 3.客户端获取到所有子节点Path后,如果发现自己在步骤1中创建的节点是所有节点中最小的,那么就认为这个客户端获得了锁 4.如果在步骤3中,发现不是最小的,那么找到比自己小的那个节点,然后对其调用exist()方法注册事件监听 5.之后一旦这个被关注的节点移除,客户端会收到相应的通知,这个时候客户端需要再次调用getChildren("/root/lock_",false)来确保自己是最小的节点,然后进入步骤3

OK,talk is cheap show me the code,下一篇文章会为大家带来Zookeeper实现分布式锁的代码。不早啦,上班去啦!

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏L宝宝聊IT

Nagios监控系统

2403
来自专栏听雨堂

VPC下访问FTP的问题

        最近用VPC一直用的很爽,用来调试安装包,实在太好用了。但是,最近却遇到一个问题,FTP总是无法正常工作,经过漫长而痛苦的跟踪定位,找到原因: ...

2448
来自专栏蓝天

揭开Linux的Swap之谜

为什么选择Linux?因为Linux能让你掌握你所做的一切!   为什么痛恨Windows?因为Windows让你不知道自己在做什么!   这就是我喜欢Linu...

1403
来自专栏用户画像

4.1.6 文件系统基础

文件是以计算机硬盘为载体存储在计算机上的信息集合,它的形式很多样化,可以是文本文档、图片、程序等。

682
来自专栏代码世界

Python之IO模型

IO模型介绍 为了更好地了解IO模型,我们需要事先回顾下:同步、异步、阻塞、非阻塞     同步(synchronous) IO和异步(asynchronous...

43611
来自专栏沈唁志

ThinkPHP-PHP开发中的主流框架

8004
来自专栏JAVA高级架构

2018年一线互联网公司Java高级面试题总结

1、hashcode相等两个类一定相等吗?equals呢?相反呢? 2、介绍一下集合框架? 3、hashmap hastable 底层实现什么区别?hashta...

5788
来自专栏Kevin-ZhangCG

什么是死锁?死锁发生的四个必要条件是什么?如何避免和预防死锁产生?

2065
来自专栏Android开发实战

HTTP1.0、HTTP1.1和HTTP2.0的区别

早在HTTP建立之初,主要就是为了将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。也是说对于前端来说,我们所写的HTML页面将要放在我们的w...

1953
来自专栏架构师之路

线上服务内存OOM问题定位三板斧

相信大家都有感触,线上服务内存OOM的问题,是最难定位的问题,不过归根结底,最常见的原因: 本身资源不够 申请的太多 资源耗尽 58到家架构部,运维部,58速运...

3306

扫码关注云+社区

领取腾讯云代金券