基于zookeeper实现分布式锁的底层原理

注:关于什么是分布式锁及其应用场景这里不赘述,需要了解请自行百度!

一 zookeeper分布式锁原理:

原理图基于curator(zookeeper客户端框架),具体代码实现看下官网API(很简单),此图解释了以下问题:

  1. 多线程间如何获取锁资源?
  2. 一个线程内重复加锁如何处理?
  3. 争抢锁资源时如何保证性能?
  4. 节点挂机是否会造成死锁?
  5. 如何解决高可用?
    在这里插入图片描述

二 redis分布式锁RedLock算法简单介绍(java API基于Redisson):

1)获取当前时间戳,单位是毫秒;
2)尝试在大多数节点上建立一个锁,必须在大多数redis节点上都成功创建锁,才能算这个整体的RedLock加锁成功(保证高可用),过期时间较短,一般就几十毫秒,在每个节点上创建锁的过程中,需要加一个超时时间,一般来说比如几十毫秒如果没有获取到锁就超时了,标识为获取锁失败;
4)客户端计算建立好锁的时间,如果建立锁的时间小于超时时间,就算建立成功了;
5)要是锁建立失败了,那么就依次删除已经创建的锁;
6)只要别人创建了一把分布式锁,你就得不断轮询去尝试获取锁。

三 基于zookeeper和redis实现分布式锁的比较和选型:

  1. 基于组件架构而言
    redis从一开始设计架构的时候就不是作为分布式协调组件来设计的,而zookeeper的设计初衷就是作为分布式系统的基础技术;
  2. 基于性能和健壮性而言:
    redisson锁支持的很好,但是比较复杂,RedLock需要轮询获取锁需要考虑性能消耗,而curator是通过注册监听器由线程主动告知,可以用zk就不建议使用redis,zk锁模型很健壮,而且有良好的curator客户端对各种类型的分布式锁的支持。
展开阅读全文

没有更多推荐了,返回首页