使用Redisson实现分布式锁

Python021

使用Redisson实现分布式锁,第1张

Redisson的分布式可重入锁RLock Java对象实现了java.util.concurrent.locks.Lock接口，同时还支持自动过期解锁。

Redisson同时还为分布式锁提供了异步执行的相关方法：

Redisson分布式可重入公平锁也是实现了java.util.concurrent.locks.Lock接口的一种RLock对象。在提供了自动过期解锁功能的同时，保证了当多个Redisson客户端线程同时请求加锁时，优先分配给先发出请求的线程。

Redisson同时还为分布式可重入公平锁提供了异步执行的相关方法：

Redisson的RedissonMultiLock对象可以将多个RLock对象关联为一个联锁，每个RLock对象实例可以来自于不同的Redisson实例。

Redisson的RedissonRedLock对象实现了 Redlock 介绍的加锁算法。该对象也可以用来将多个RLock

对象关联为一个红锁，每个RLock对象实例可以来自于不同的Redisson实例。

Redisson的分布式可重入读写锁RReadWriteLock Java对象实现了java.util.concurrent.locks.ReadWriteLock接口。同时还支持自动过期解锁。该对象允许同时有多个读取锁，但是最多只能有一个写入锁。

Redisson的分布式信号量（Semaphore）Java对象RSemaphore采用了与java.util.concurrent.Semaphore相似的接口和用法。

Redisson的可过期性信号量（PermitExpirableSemaphore）实在RSemaphore对象的基础上，为每个信号增加了一个过期时间。每个信号可以通过独立的ID来辨识，释放时只能通过提交这个ID才能释放。

Redisson的分布式闭锁（CountDownLatch）Java对象RCountDownLatch采用了与java.util.concurrent.CountDownLatch相似的接口和用法。

Redisson 分布式锁和同步器

首先，分布式锁和我们平常讲到的锁原理基本一样，目的就是确保在多个线程并发时，只有一个线程在同一刻操作这个业务或者说方法、变量。

在一个进程中，也就是一个jvm或者说应用中，我们很容易去处理控制，在 java.util 并发包中已经为我们提供了这些方法去加锁，比如 synchronized 关键字或者 Lock 锁，都可以处理。

但是如果在分布式环境下，要保证多个线程同时只有1个能访问某个资源，就需要用到分布式锁。这里我们将介绍用Redis的 setnx 命令来实现分布式锁。

其实目前通常所说的 setnx 命令，并非单指redis的 setnx key value 这条命令，这条命令可能会在后期redis版本中删除。

一般代指redis中对 set 命令加上 nx 参数进行使用， set 这个命令，目前已经支持这么多参数可选：

从 Redis 2.6.12 版本开始， SET 命令的行为可以通过一系列参数来修改：

注入bean

这里同时启动5个线程并发往redis中存储 lock 这个key（key可以自定义，但需要一致），同时设置10秒的过期时间。

setIfAbsent 这个函数实现的功能与 setnx 命令一样，代表如果没有这个key则set成功获取到锁，否则set失败没有获取到锁。

获得锁后进行资源的操作，最后释放锁。

执行效果 ：

可以看到同时只有1个线程能够获取到锁。

使用 setnx 命令方式虽然操作比较简单方便，但是会有如下问题：

可以在再次获取锁时，如果锁被占用就get值，判断值是否是当前线程存的随机值，如果是则再次执行 set 命令重新上锁；当然为了保证原子性这些操作都要用 lua 脚本来执行。

可以使用 while 循环重复执行 setnx 命令，并设置一个超时时间退出循环。

可以尽量把锁自动过期的时间设的冗余一些。但也不能彻底解决。

可以在删除锁的时候先get值，判断值是否是当前线程存的随机值，只有相同才执行删锁的操作；当然也要使用 lua 脚本执行来保证原子性。

分布式锁需要满足的特性

综上：使用 setnx 命令来实现分布式锁并不是一个很严谨的方案，如果是Java技术栈，我们可以使用 Redisson 库来解决以上问题，接下来的文章会介绍如何使用。

Redisson实现分布式锁

Redlock实现分布式锁

单体架构的应用可以直接使用synchronized或者ReentrantLock就可以解决多线程资源竞争的问题。如果公司业务发展较快，可以通过部署多个服务节点来提高系统的并行处理能力。由于本地锁的作用范围只限于当前应用的线程。高并发场景下，集群中某个应用的本地锁并不会对其它应用的资源访问产生互斥，就会产生数据不一致的问题，所以分布锁就派上了用场。

利用select … where … for update 排他锁

所谓乐观锁与前边最大区别在于基于CAS思想，是不具有互斥性，不会产生锁等待而消耗资源，操作过程中认为不存在并发冲突，只有update version失败后才能觉察到。我们的抢购、秒杀就是用了这种实现以防止超卖。通过增加递增的版本号字段实现乐观锁

思路： 另启一个服务，利用jdk并发工具来控制唯一资源，如在服务中维护一个concurrentHashMap，其他服务对某个key请求锁时，通过该服务暴露的端口，以网络通信的方式发送消息，服务端解析这个消息，将concurrentHashMap中的key对应值设为true，分布式锁请求成功，可以采用基于netty通信调用，当然你想用java的bio、nio或者整合dubbo、spring cloud feign来实现通信也没问题

在高并发场景下，应用程序在执行过程中往往会受到网络、CPU、内存等因素的影响，所以实现一个线程安全的分布式组件，往往需要考虑很多case，这个分布式锁有 3 个重要的考量点：

下面是redis分布式锁的各种实现方式和缺点，按照时间的发展排序:

直接利用setnx，执行完业务逻辑后调用del释放锁，简单粗暴!

为了改正第一个方法的缺陷，我们用setnx获取锁，然后用expire对其设置一个过期时间，如果服务挂了，过期时间一到自动释放

redis官方为了解决第二种方式存在的缺点，在2.8版本为set指令添加了扩展参数nx和ex，保证了setnx+expire的原子性，使用方法：set key value ex 5 nx

上面所说的第一个缺点，没有特别好的解决方法，只能把过期时间尽量设置的长一点，并且最好不要执行耗时任务 第二个缺点，可以理解为当前线程有可能会释放其他线程的锁，那么问题就转换为保证线程只能释放当前线程持有的锁，即setnx的时候将value设为任务的唯一id，释放的时候先get key比较一下value是否与当前的id相同，是则释放，否则抛异常回滚，其实也是变相地解决了第一个问题

我们可以用lua来写一个getkey并比较的脚本，jedis/luttce/redisson对lua脚本都有很好的支持

为了解决上面提到的redis集群中的分布式锁问题，redis的作者antirez的提出了red lock的概念，假设集群中所有的n个master节点完全独立，并且没有主从同步，此时对所有的节点都去setnx，并且设置一个请求过期时间re和锁的过期时间le，同时re必须小于le（可以理解，不然请求3秒才拿到锁，而锁的过期时间只有1秒也太蠢了），此时如果有n / 2 + 1个节点成功拿到锁，此次分布式锁就算申请成功

ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。基于ZooKeeper实现分布式锁的步骤如下：

（1）redis set px nx + 唯一id + lua脚本

综上所得：

没有绝对完美的实现方式，具体要选择哪一种分布式锁，需要结合每一种锁的优缺点和业务特点而定。