阿八博客
  • 100000+

    文章

  • 23

    评论

  • 20

    友链

  • 最近新加了很多技术文章,大家多来逛逛吧~~~~
  • 喜欢这个网站的朋友可以加一下QQ群,我们一起交流技术。

Redis 分布式锁的正确实现方式

欢迎来到阿八个人博客网站。本 阿八个人博客 网站提供最新的站长新闻,各种互联网资讯。 喜欢本站的朋友可以收藏本站,或者加QQ:我们大家一起来交流技术! URL链接:https://www.abboke.com/jsh/2019/1010/116497.html
转载:https://wudashan.cn/2017/10/2...

前言

分布式锁一般有三种实现方式:

数据库乐观锁;基于 Redis 的分布式锁;基于 ZooKeeper 的分布式锁

本篇博客将介绍第二种方式,基于 Redis 实现分布式锁
虽然网上已经有各种介绍 Redis 分布式锁实现的博客,然而他们的实现却有着各种各样的问题,为了避免误人子弟,本篇博客将详细介绍如何正确地实现 Redis 分布式锁

可靠性

首先,为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件:

互斥性
在任意时刻,只有一个客户端能持有锁
不会发生死锁
即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁
具有容错性
只要大部分的 Redis 节点正常运行,客户端就可以加锁和解锁
解铃还须系铃人
加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了

代码实现

组件依赖

首先我们要通过 Maven 引入 Jedis 开源组件,在 pom.xml 文件加入下面的代码:

可以看到,我们加锁就一行代码:jedis.set(String key, String value, String nxxx, String expx, int time),这个 set()方法一共有五个形参:

第一个为 key,我们使用 key 来当锁,因为 key 是唯一的
第二个为 value,我们传的是 requestId,很多童鞋可能不明白,有 key 作为锁不就够了吗,为什么还要用到 value?原因就是我们在上面讲到可靠性时,分布式锁要满足第四个条件解铃还须系铃人,通过给 value 赋值为 requestId,我们就知道这把锁是哪个请求加的了,在解锁的时候就可以有依据
requestId 可以使用 UUID.randomUUID().toString()方法生成
第三个为 nxxx,这个参数我们填的是 NX,意思是 SET IF NOT EXIST,即当 key 不存在时,我们进行 set 操作;若 key 已经存在,则不做任何操作;第四个为 expx,这个参数我们传的是 PX,意思是我们要给这个 key 加一个过期的设置,具体时间由第五个参数决定
第五个为 time,与第四个参数相呼应,代表 key 的过期时间

总的来说,执行上面的 set()方法就只会导致两种结果:

当前没有锁(key 不存在),那么就进行加锁操作,并对锁设置个有效期,同时 value 表示加锁的客户端
已有锁存在,不做任何操作

心细的童鞋就会发现了,我们的加锁代码满足我们可靠性里描述的三个条件
首先,set()加入了 NX 参数,可以保证如果已有 key 存在,则函数不会调用成功,也就是只有一个客户端能持有锁,满足互斥性
其次,由于我们对锁设置了过期时间,即使锁的持有者后续发生崩溃而没有解锁,锁也会因为到了过期时间而自动解锁(即 key 被删除),不会发生死锁
最后,因为我们将 value 赋值为 requestId,代表加锁的客户端请求标识,那么在客户端在解锁的时候就可以进行校验是否是同一个客户端
由于我们只考虑 Redis 单机部署的场景,所以容错性我们暂不考虑

错误示例 1

比较常见的错误示例就是使用 jedis.setnx()和 jedis.expire()组合实现加锁,代码如下:

那么这段代码问题在哪里?

由于是客户端自己生成过期时间,所以需要强制要求分布式下每个客户端的时间必须同步
当锁过期的时候,如果多个客户端同时执行 jedis.getSet()方法,那么虽然最终只有一个客户端可以加锁,但是这个客户端的锁的过期时间可能被其他客户端覆盖
锁不具备拥有者标识,即任何客户端都可以解锁

解锁代码

正确姿势

还是先展示代码,再带大家慢慢解释为什么这样实现:

可以看到,我们解锁只需要两行代码就搞定了!第一行代码,我们写了一个简单的 Lua 脚本代码,上一次见到这个编程语言还是在《黑客与画家》里,没想到这次居然用上了
第二行代码,我们将 Lua 代码传到 jedis.eval()方法里,并使参数 KEYS[1]赋值为 lockKey,ARGV[1]赋值为 requestId

eval()方法是将 Lua 代码交给 Redis 服务端执行

那么这段 Lua 代码的功能是什么呢?

其实很简单,首先获取锁对应的 value 值,检查是否与 requestId 相等,如果相等则删除锁(解锁)
那么为什么要使用 Lua 语言来实现呢?因为要确保上述操作是原子性的
关于非原子性会带来什么问题,可以阅读【解锁代码-错误示例 2】
那么为什么执行 eval()方法可以确保原子性,源于 Redis 的特性,下面是官网对 eval 命令的部分解释:

简单来说,就是在 eval 命令执行 Lua 代码的时候,Lua 代码将被当成一个命令去执行,并且直到 eval 命令执行完成,Redis 才会执行其他命令

错误示例 1

最常见的解锁代码就是直接使用 jedis.del()方法删除锁,这种不先判断锁的拥有者而直接解锁的方式,会导致任何客户端都可以随时进行解锁,即使这把锁不是它的

这种解锁代码乍一看也是没问题,甚至我之前也差点这样实现,与正确姿势差不多,唯一区别的是分成两条命令去执行,代码如下:


												

相关文章

暂住......别动,不想说点什么吗?
  • 全部评论(0
    还没有评论,快来抢沙发吧!