北京网站制作一般多少钱,游戏源码搭建,做博客网站赚钱,怎么做网站引流#x1f680; 优质资源分享 #x1f680;
学习路线指引#xff08;点击解锁#xff09;知识定位人群定位#x1f9e1; Python实战微信订餐小程序 #x1f9e1;进阶级本课程是python flask微信小程序的完美结合#xff0c;从项目搭建到腾讯云部署上线#xff0c;打造一… 优质资源分享
学习路线指引点击解锁知识定位人群定位 Python实战微信订餐小程序 进阶级本课程是python flask微信小程序的完美结合从项目搭建到腾讯云部署上线打造一个全栈订餐系统。Python量化交易实战入门级手把手带你打造一个易扩展、更安全、效率更高的量化交易系统前面我们剖析了Redisson的源码主要分析了Redisson实现Redis分布式锁的15问理清了Redisson是如何实现的分布式锁和一些其它的特性。这篇文章就来接着剖析Zookeeper分布式锁的实现框架Curator的源码看看Curator是如何实现Zookeeper分布式锁的以及它提供的哪些其它的特性。
Curator框架是封装对于zk操作的api其中就包括了对分布式锁的实现当然Curator框架也包括其它的功能分布式锁只是Curator的一部分功能。
本文的目录跟Redisson文章的目录比较相似主要是为了方便大家对比redis和zk分布式锁的实现。如需要Redisson源码剖析的文章请关注微信公众号 三友的java日记回复 Redisson 即可。
一、ZK分布式锁实现原理
实现Zookeeper分布式锁主要是基于Zookeeper的临时顺序节点来实现的。
当客户端来加锁的时候会先在加锁的节点下建立一个子节点这个节点就有一个序号类似 lock-000001 创建成功之后会返回给客户端所创建的节点然后客户端会去获取这个加锁节点下的所有客户端创建的子节点当然也包括自己创建的子节点。拿到所有节点之后给这些节点进行排序然后判断自己创建的节点在这些节点中是否排在第一位如果是的话那么就代表当前客户端就算加锁成功了如果不是的话那么就代表当前客户端加锁失败。
加锁失败的节点并不会不停地循环去尝试加锁而是在自己创建节点的前一个节点上加一个监听器然后就进行等待。当前面一个节点释放了锁就会反过来通知等待的客户端然后客户端就加锁成功了。
为什么需要在前一个节点加个监听器
假设有很多客户端来加锁然后加锁失败的都对前一个节点加一个监听。那么一旦第一个加锁成功的客户端线程释放了锁那么被唤醒的就是第二个客户端线程第二个客户端线程就会加锁成功执行完任务之后就释放了锁那么就会唤醒第三个客户端线程第三个客户端线程加锁成功执行完任务之后就释放了锁唤醒第四个客户端线程以此类推所以每次释放锁都会唤醒下一个节点这样每个加锁的线程都会加锁成功所以监听器的作用是唤醒加锁失败阻塞等待的客户端。
二、为什么使用临时顺序节点
下面介绍一下临时节点、持久化节点、顺序节点的特性。
1临时节点
临时节点指的是节点创建后如果创建节点的客户端和 Zookeeper 服务端的会话失效(例如断开连接)那么节点就会被删除。
2持久化节点
持久化节点指的是节点创建后即使创建节点的客户端和 Zookeeper 服务端的会话失效(例如断开连接)节点也不会被删除只有客户端主动发起删除节点的请求节点才会被删除。
3有序节点
有序节点这种节点在创建时会有一个序号这个序号是自增的。有序节点既可以是有序临时节点也可以是有序持久化节点。
从上面节点的特性可以知道临时节点相比持久节点最主要的是对会话失效的情况处理不一样如果使用临时节点的话如果客户端发生异常的话没有来得及主动释放锁就能避免锁无法释放导致死锁的情况。因为一旦客户端异常那么客户端和服务端之间的会话就会失效然后临时节点就会被删除这样就释放了锁而持久化节点在由于会话失效无法被删除那么就不会去释放锁这样就会产生死锁的问题。
从这里可以看出redis和zk防止死锁的实现是不同的redis是通过过期时间来防止死锁而zk是通过临时节点来防止死锁的。
为什么使用顺序节点其实为了防止羊群效应。如果没有使用顺序节点假设很多客户端都会去加锁那么加锁就会都失败都会对加锁的节点加个监听器那么一旦锁释放那么所有的加锁客户端都会被唤醒来加锁那么一瞬间就会造成很多加锁的请求增加服务端的压力。
所以综上临时顺序节点是个比较好的选择。
三、加锁的逻辑是如何实现的****
前面关于ZK分布式锁实现原理已经说过了接下来就来看一下代码的实现。
加锁的使用方法如下接下来几节会着重讲解这段代码背后的逻辑 acquire方法的实现 acquire方法会去调用internalLock方法传入超时时间 -1 和单位 null也就代表了如果加锁不成功会一直阻塞直至加锁成功不会超时。 internalLock方法会先去获取当前线程然后从threadData中获取当前线程对应的LockData这里面封装了加锁的信息和次数是实现可重入锁的关键当然第一次加锁这里肯定是没有的会继续下走 internals.attemptLock 加锁。
attemptLock方法 先通过driver的createsTheLock去创建节点。 从这里看出创建的节点类型是临时顺序节点创建成功之后就会返回当前创建的节点。
节点创建成功之后会调用internalLockLoop方法来加锁。 通过getSortedChildren方法获取排好序的子节点然后获取当前的节点名称再通过 driver.getsTheLock判断当前的节点有没有加锁成功返回一个PredicateResults判断的结果这里面存的就是否加锁成功的信息。
第一次加锁那么到这里就加锁成功了。之后就会封装一个LockData对象放入threadData 的map中。
加锁的流程如下图 四、如何实现可重入加锁
上文加锁的时候提到了当第一次加锁成功之后会往threadData放入该加锁的线程对应的LockData。 LockData主要封装了当前线程、加锁的次数、加锁的节点。
此时如果第二次来加锁那么就会从threadData中获取到加锁的信息然后将加锁次数加1就代表了加锁成功然后直接返回。 所以可重入加锁的实现很简单就是在客户端中判断有没有加过锁加过的话就将加锁次数累加1压根就跟服务端没有交互。
注意Redisson可重入加锁的实现跟的Curator是不一样的Redisson的加锁次数是存在Redis的服务端的而Curator是存在客户端的。 五、加锁失败之后如何实现阻塞等待加锁
前面加锁的逻辑主要是说了加锁成功的情况这里就来说一下加锁失败的情况。
继续来看internalLockLoop方法。 前面说过判断有没有加锁成功会返回一个PredicateResults这里面包含了有没有加锁成功的信息同时如果没有加锁成功就会返回需要监听的节点也就是当前创建的节点的前一个节点。
所以没有加锁成功就会走else的逻辑对上一个节点加一个监听器 watcher 然后就会调用 wait 方法进行等待。 当前一个节点被删除了也就是释放了锁那么就会回调这个监听器watcher的方法。 所以这个watcher的作用就是调用notifyAll方法唤醒调用wait方法的线程这样线程就会继续尝试加锁因为是在一个while的循环中。
六、如何实现阻塞等待一定时间还未加锁成功就放弃加锁
可通过下面这个方法来实现实现阻塞等待一定时间还未加锁成功就放弃加锁。
?
| 1 | boolean acquire(long time, TimeUnit unit) throws Exception |
这个方法相比不指定等待时间的方法最主要的区别就是加锁失败之后调用的阻塞的方法不一样。当不指定超时时间就会调用wait()方法不会传入等待时间不被唤醒就会一直阻塞指定超时时间的时候就会调用wait(long timeout)指定等待的时间这样如果等待时间一到线程就会醒过来然后再次尝试加锁一旦加锁失败就会放弃加锁。 七、如何主动释放锁和避免其它线程释放锁
释放锁release方法 释放锁其实很简单就是拿出当前线程对应的LockData如果没有就说明当前线程没有加过锁就会抛出异常所以Curator就是通过这个判断来防止其它线程释放了自己线程加的锁。
如果加锁了那么LockData就不会为null然后将加锁次数递减1得到newLockCount代表了剩下的加锁次数。
如果newLockCount 0说明锁没释放完有可重入加锁然后什么事都不干直接返回了。如果newLockCount 0就抛异常但是一般不会出现。剩下的一种情况就是newLockCount 0 说明锁已经完完全全释放完了然后通过internals.releaseLock删除加锁的节点。
服务端删除节点之后就会通知监听该节点的客户端然后客户端就会回调watcher监听器唤醒阻塞等待的线程线程被唤醒后再进行一次判断就能加锁成功。
到这里就讲完了加锁和释放锁的过程整个加锁和释放锁的过程就如下图所示。 八、如何实现公平锁
其实使用临时顺序节点实现的分布式锁就是公平锁。所谓的公平锁就是加锁的顺序跟成功加锁的顺序是一样的。
因为节点的顺序就是被唤醒的顺序所以也就是加锁的顺序所以天生就是公平锁。
九、如何实现读写锁
读写锁使用如下。 创建节点的时候节点的内容中会有一个标记来代表当前节点加的是什么类型的锁。 当需要加写锁时需要判断自己创建的节点是否排在第一位如果是就能加锁成功所以一旦前面有节点不论前面加是读锁还是写锁那么都是加锁失败实现了读写互斥和写写互斥。当然写锁和读锁都是可以重入加锁的。
当需要加读锁的时候会去判断自己创建节点的前面有没有写锁如果没写锁那么说明前面加的都是读锁那么读锁就能加锁成功读读不互斥如果前面有写锁那么就加锁失败自己加的写锁除外读写互斥。
十、如何实现批量加锁
批量加锁的意思就是同时加几个锁只有这些锁都算加成功了才是真正的加锁成功。
Redisson也实现了批量加锁的功能Redisson的实现通过RedissonMultiLock类实现的RedissonMultiLock会去遍历需要加的锁然后每个都加成功之后才算加锁成功。Curator是封装了InterProcessMultiLock类来实现的批量加锁的那么InterProcessMultiLock如何实现的呢
使用代码如下。 InterProcessMultiLock的acquire的方法实现。 从这里可以看出InterProcessMultiLock也是遍历传入的锁然后每个锁都加锁成功了InterProcessMultiLock才算加锁成功。
所以从这里可以看出跟Redisson实现的批量加锁的实现思想上基本是一样的都是遍历加锁。
十一、ZK分布式锁和Redis分布式锁到底该选谁
这是一个比较常见的面试题。
redis分布式锁
优点性能高能保证AP保证其高可用缺点正如Redisson的那篇文章所言主要是如果出现主节点宕机从节点还未来得及同步主节点的加锁信息可能会导致重复加锁。虽然Redis官网提供了RedLock算法来解决这个问题Redisson也实现了但是RedLock算法其实本身是有一定的争议的有大佬质疑该算法的可靠性同时因为需要的机器过多也会浪费资源所以RedLock也不推荐使用。
zk分布式锁
优点zk本身其实就是CP的能够保证加锁数据的一致性。每个节点的创建都会同时写入leader和follwer节点半数以上写入成功才返回如果leader节点挂了之后选举的流程会优先选举zxid事务Id最大的节点就是选数据最全的又因为半数写入的机制这样就不会导致丢数据缺点性能没有redis高
所以通过上面的对比可以看出redis分布式锁和zk分布式锁的侧重点是不同的这是redis和zk本身的定位决定的redis分布式锁侧重高性能zk分布式锁侧重高可靠性。所以一般项目中redis分布式锁和zk分布式锁的选择是基于业务来决定的。如果你的业务需要保证加锁的可靠性不能出错那么zk分布式锁就比较符合你的要求如果你的业务对于加锁的可靠性没有那么高的要求那么redis分布式锁是个不错的选择。
最后希望通过这两篇文章让大家对于zookeeper分布式锁和redis分布式锁的实现有个更好的认识。如需要Redisson源码剖析的文章请关注微信公众号 三友的java日记回复 Redisson 即可。 往期热门文章推荐
有关循环依赖和三级缓存的这些问题你都会么面试常问万字28张图带你探秘小而美的规则引擎框架LiteFlow7000字24张图带你彻底弄懂线程池【SpringCloud原理】OpenFeign原来是这么基于Ribbon来实现负载均衡的【SpringCloud原理】Ribbon核心组件以及运行原理源码剖析【SpringCloud原理】OpenFeign之FeignClient动态代理生成原理
扫码或者搜索关注公众号 三友的java日记 及时干货不错过公众号致力于通过画图加上通俗易懂的语言讲解技术让技术更加容易学习。
