缓存锁

 我们常常将缓存作为分布式锁的解决方案,但是却不能单纯的判断某个 key 是否存在 来作为锁的获得依据,因为无论是 exists 和 get 命名都不是线程安全的,都无法保证只有一个线程可以获得锁,存在线程争抢,可能会有多个线程同时拿到锁的情况(经典的 Redis “读后写”的问题)。

incr 缓存锁

@Component
public class LockClient { private StringRedisTemplate stringRedisTemplate; private ValueOperations<String, String> valueOperations; @Autowired
public void setStringRedisTemplate(StringRedisTemplate stringRedisTemplate) {
this.stringRedisTemplate = stringRedisTemplate;
this.valueOperations = stringRedisTemplate.opsForValue();
} public void lockIncr() {
Long lockIncr = valueOperations.increment("lockIncr", 1);
// 说明拿到了锁
if (lockIncr == 1) {
// 业务操作
}
}
}
  1. incr:递增指定键对应的数值,如果不存在 key 对应的值,那么会先将 key 的值设置为 0,然后执行 incr 操作,返回递增的值。
  2. 这种锁的实现原理主要是利用 incr 命令的原子性,同一时间只会有一个线程操作这个命令。
  3. 这种锁的实现方式,不在乎结果数据。保证只有唯一线程能够执行到业务代码。

setnx 缓存锁

 上面的锁实现方式,我们对资源做了隔离,保证只有唯一线程可以拿到资源并执行操作。但是如果资源并不是唯一线程执行的呢?存在多个线程争抢的情况下呢?

    public void lockSetnx() {
String lock = "lockSetnx";
long millis = System.currentTimeMillis();
long timeout = millis + 3000L + 1;
try {
while (true) {
boolean setnx = valueOperations.setIfAbsent(lock, timeout + "");
if (setnx == true) {
break;
}
String oldTimeout = valueOperations.get(lock);
// 这一步是为了解决客户端异常宕机,锁没有被正常释放的时候。
// 当 p1、p2 同时执行到这里,发现锁的时间过期了。p1、p2 同时执行 getSet 命令。
// 假设 p1 先执行成功了,那么 p1 得到的值就是原来锁的过期时间(可以符合下面的判断式),表示争抢锁成功。
// 假设 p2 后执行成功了,那么 p2 得到的值就是 p1 set 进去的值(不会符合下面的表达式),表示争抢锁失败。
String oldValue = valueOperations.getAndSet(lock, timeout + "");
if (millis > Long.valueOf(oldTimeout) && millis > Long.valueOf(oldValue)) {
break;
}
// 休眠 100 毫秒,再去争抢锁
Thread.sleep(100);
} // 执行业务代码
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
if (millis < timeout) {
stringRedisTemplate.delete(lock);
}
} }
  1. setnx:只有第一个线程会执行成功,返回 true,其余线程执行失败,返回 false。
  2. getSet:返回 key 中的旧值,并把新的值 set 进去。
  3. 细细看来,好像似乎 setnx 命令就能够实现分布式锁了,为什么还要 getSet 命名呢?getSet 命令是为了解决客户端异常宕机,锁没有被正常释放的情况下,结合过期时间来保证线程安全。可以看看官网的介绍,有详细解释这个问题。

zookeeper 锁

zookeeper,天生的分布式协调工具,生来就是为了解决各种分布式的难题,比如分布式锁、分布式计数器、分布式队列等等。

zookeeper 分布式锁,如果自己实现的话,大抵的实现方式如下:

公平锁:

  • 在 zookeeper 的指定节点(locks)下创建临时顺序节点 node_n ;
  • 获取 locks 下面的所有子节点 children。
  • 对子节点按节点自增序号从小到大排序。
  • 判断本节点是不是第一个子节点,如果是,则获取到锁。如果不是,则监听比该节点小的那个节点的删除事件。
  • 若监听事件生效,则回到第二步重新判断,直到获取到锁。

不公平锁

  • 在 zookeeper 的某个节点(lock)上创建临时节点 znode。
  • 创建成功,就表示获取到了这个锁;其他客户端来创建锁会失败,只能注册对这个锁的监听。
  • 其他客户端监听到这个锁被释放(znode节点被删除),就会尝试加锁(创建节点),继续执行第二步。

幸运的是,zookeeper recipes 客户端为我们提供了多种分布式锁实现:

  • InterProcessMutex(可重入排他锁)
  • InterProcessSemaphoreMutex(不可重入排他锁)
  • InterProcessReadWriteLock(分布式读写锁)
  • InterProcessSemaphore(共享信号量 —— 设置最大并行数量)

zookeeper recipes 锁的简单使用:

        <dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>3.4.14</version>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>4.0.1</version>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-recipes</artifactId>
<version>4.0.1</version>
</dependency>
    public InterProcessMutex interProcessMutex(String lockPath) {
CuratorFramework client = CuratorFrameworkFactory.newClient(zookeeper, new ExponentialBackoffRetry(1000, 3));
// 启用命名空间,做微服务间隔离
client.usingNamespace(namespace);
client.start();
return new InterProcessMutex(client, lockPath);
}
    public void lockUse() {
InterProcessMutex interProcessMutex = interProcessMutex("/lockpath");
try {
// 获取锁
if (interProcessMutex.acquire(100, TimeUnit.MILLISECONDS)) {
// 执行业务代码
}
} catch (Exception e) {
e.printStackTrace();
} finally {
// 释放锁
try {
interProcessMutex.release();
} catch (Exception e) {
e.printStackTrace();
}
}
}

比较

  • 缓存分布式锁,必须采用轮询的方式去尝试加锁,对性能浪费很大;zookeeper 分布式锁,可以通过监听的方式等待通知或超时,当有锁释放,通知使用者即可。
  • 如果缓存获取锁的那个客户端宕机了,锁不会被释放,只能通过其它方式解决(上面的 getSet 判断);而 zookeeper 的话,因为创建的是临时 znode,只要客户端挂了,znode 就没了,此时就自动释放锁。

基于缓存或zookeeper的分布式锁实现的更多相关文章

  1. 基于 Zookeeper 的分布式锁实现

    1. 背景 最近在学习 Zookeeper,在刚开始接触 Zookeeper 的时候,完全不知道 Zookeeper 有什么用.且很多资料都是将 Zookeeper 描述成一个“类 Unix/Linu ...

  2. 基于Zookeeper的分布式锁

    实现分布式锁目前有三种流行方案,分别为基于数据库.Redis.Zookeeper的方案,其中前两种方案网络上有很多资料可以参考,本文不做展开.我们来看下使用Zookeeper如何实现分布式锁. 什么是 ...

  3. 10分钟看懂!基于Zookeeper的分布式锁

    实现分布式锁目前有三种流行方案,分别为基于数据库.Redis.Zookeeper的方案,其中前两种方案网络上有很多资料可以参考,本文不做展开.我们来看下使用Zookeeper如何实现分布式锁. 什么是 ...

  4. 基于ZooKeeper实现——分布式锁与实现

    引言 ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件.它是一个为分布式应用提供一致性服务的软件,提 ...

  5. 【连载】redis库存操作,分布式锁的四种实现方式[一]--基于zookeeper实现分布式锁

    一.背景 在电商系统中,库存的概念一定是有的,例如配一些商品的库存,做商品秒杀活动等,而由于库存操作频繁且要求原子性操作,所以绝大多数电商系统都用Redis来实现库存的加减,最近公司项目做架构升级,以 ...

  6. 分布式锁(3) ----- 基于zookeeper的分布式锁

    分布式锁系列文章 分布式锁(1) ----- 介绍和基于数据库的分布式锁 分布式锁(2) ----- 基于redis的分布式锁 分布式锁(3) ----- 基于zookeeper的分布式锁 代码:ht ...

  7. 基于Zookeeper的分布式锁(干干干货)

    原文地址: https://juejin.im/post/5df883d96fb9a0163514d97f 介绍 为什么使用锁 锁的出现是为了解决资源争用问题,在单进程环境下的资源争夺可以使用 JDK ...

  8. 基于zookeeper实现分布式锁和基于redis实现分布所的区别

    1,实现方式不同 zookeeper实现分布式锁:通过创建一个临时节点,创建的成功节点的服务则抢占到分布式锁,可做业务逻辑.当业务逻辑完成,连接中断,节点消失,继续下一轮的锁的抢占. redis实现分 ...

  9. java就业指南 zookeeper分布式系统 zookeeper实现分布式锁 有用

    目前几乎很多大型网站及应用都是分布式部署的,分布式场景中的数据一致性问题一直是一个比较重要的话题.分布式的CAP理论告诉我们“任何一个 分布式系统都无法同时满足一致性(Consistency).可用性 ...

随机推荐

  1. .Net中使用数据库(sqlite)的大体流程(简单向)

    说来数据库,各种语言各种数据库在操作上大体无异,基本都是连接数据库.操作数据库.关闭数据库连接的流程,不过Sqlite由于是单文件数据库,相比其他服务器的数据库连接更简单,只需要给定数据库文件的路径即 ...

  2. Win10中解决Prolific PL2303出现错误代码10的问题

    PL2303 是Prolific 公司生产的一种高度集成的RS232-USB接口转换器,在Win10中默认安装的驱动程序会出现错误代码10的问题,如下图所示: 下载Win10上可以用的PL2303驱动 ...

  3. QT 自定义消息(超级简单的一个例子)

    #define TEST_EVENT QEvent::User + 100   class CVxActuatorMain : public QMainWindow {   protected:    ...

  4. Win10如何关闭自动更新服务

    原文:Win10如何关闭自动更新服务 第一步: 小娜搜索"gpedit.msc",进入本地计算机策略设置. 第二步: 找到策略位置:本地计算机策略-计算机配置-管理模板-Windo ...

  5. Qt for windows消息循环、libqxt分析和wince快捷键处理

    Qt for windows消息循环.libqxt分析和wince快捷键处理 利用Qt做windows图形界面开发和MFC相比,个人感觉还是比较简单好用的:首先利用Designer工具搞个ui文件:然 ...

  6. webform的图片防盗链

    最近用到域的问题,不是同一主机的请求将不允许请求此页面. 这其实和图片防盗链的本质是一样的. 通过两个属性:由于当时用的aspx视图引擎,所以需要通过HttpContext.Current才能拿到ht ...

  7. 可以用GetObjectProp来获取对象的属性

    原来可以用GetObjectProp来获取对象的属性,还有这用法,哈哈哈哈…… var SL: TStrings; UseDBTools: Boolean;begin SL := nil; if Me ...

  8. qt5.7交叉编译gstreamer-1.0

    一.交叉编译glib1.提前需先交叉编译libffiCC=/home/mjl/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-gcc ...

  9. 开源代码分析工具 good

    checkstyle - static code analysis tool for JavaPMD - A source code analyzer

  10. FMXUI中的三大杀器:TView、TLinearLayout、TRelativeLayout

    好了,今天我们来介绍下FMXUI中的三大杀器:TView.TLinearLayout.TRelativeLayout. [名词定义] 非布局组件: 组件名不是以Layout结尾的组件,Delphi自带 ...