分布式锁一般有三种实现方式:1. 数据库乐观锁;2. 基于Redis的分布式锁;3. 基于ZooKeeper的分布式锁。本篇博客将介绍第二种方式,基于Redis实现分布式锁。虽然网上已经有各种介绍Redis分布式锁实现的博客,然而他们的实现却有着各种各样的问题,本篇博客将详细介绍如何正确地实现Redis分布式锁。
需满足如下条件:
-互斥性。在任意时刻,只有一个客户端能持有锁。
- 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁。
- 具有容错性。只要大部分的Redis节点正常运行,客户端就可以加锁和解锁。
- 解铃还须系铃人。加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了。
正确方式:
首先我们要通过Maven引入Jedis开源组件,在pom.xml文件加入下面的代码:
redis.clients
jedis
2.9.0
注:如果在springBoot,可以使用springBoot自己封装的redisTemplate.自行百度。
加锁代码:
public class RedisTool {
private static final String LOCK_SUCCESS = "OK";
private static final String SET_IF_NOT_EXIST = "NX";
private static final String SET_WITH_EXPIRE_TIME = "PX";
/**
* 尝试获取分布式锁
* @param jedis Redis客户端
* @param lockKey 锁
* @param requestId 请求标识 (可通过UUID生成唯一标识)
* @param expireTime 超期时间
* @return 是否获取成功
*/
public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {
String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
if (LOCK_SUCCESS.equals(result)) {
return true;
}
return false;
}
}
错误实例1:
比较常见的错误示例就是使用jedis.setnx()和jedis.expire()组合实现加锁,代码如下:
public static void wrongGetLock1(Jedis jedis, String lockKey, String requestId, int expireTime) {
Long result = jedis.setnx(lockKey, requestId);
if (result == 1) {
// 若在这里程序突然崩溃,则无法设置过期时间,将发生死锁
jedis.expire(lockKey, expireTime);
}
}
setnx()方法作用就是SET IF NOT EXIST,expire()方法就是给锁加一个过期时间。乍一看好像和前面的set()方法结果一样,然而由于这是两条Redis命令,不具有原子性,如果程序在执行完setnx()之后突然崩溃,导致锁没有设置过期时间。那么将会发生死锁。网上之所以有人这样实现,是因为低版本的jedis并不支持多参数的set()方法。
正确方式:
public class RedisTool {
private static final Long RELEASE_SUCCESS = 1L;
/**
* 释放分布式锁
* @param jedis Redis客户端
* @param lockKey 锁
* @param requestId 请求标识
* @return 是否释放成功
*/
public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));
if (RELEASE_SUCCESS.equals(result)) {
return true;
}
return false;
}
}
可以看到,我们解锁只需要两行代码就搞定了!第一行代码,我们写了一个简单的Lua脚本代码,第二行代码,我们将Lua代码传到jedis.eval()方法里,并使参数KEYS[1]赋值为lockKey,ARGV[1]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。那么这段Lua代码的功能是什么呢?其实很简单,首先获取锁对应的value值,检查是否与requestId相等,如果相等则删除锁(解锁)。那么为什么要使用Lua语言来实现呢?因为要确保上述操作是原子性的。简单来说,就是在eval命令执行Lua代码的时候,Lua代码将被当成一个命令去执行,并且直到eval命令执行完成,Redis才会执行其他命令。
错误示例1:
public static void wrongReleaseLock1(Jedis jedis, String lockKey) {
jedis.del(lockKey);
}
最常见的解锁代码就是直接使用jedis.del()方法删除锁,这种不先判断锁的拥有者而直接解锁的方式,会导致任何客户端都可以随时进行解锁,即使这把锁不是它的。
错误示例2:
public static void wrongReleaseLock2(Jedis jedis, String lockKey, String requestId) {
// 判断加锁与解锁是不是同一个客户端
if (requestId.equals(jedis.get(lockKey))) {
// 若在此时,这把锁突然不是这个客户端的,则会误解锁
jedis.del(lockKey);
}
}
如代码注释,问题在于如果调用jedis.del()方法的时候,这把锁已经不属于当前客户端的时候会解除他人加的锁。那么是否真的有这种场景?答案是肯定的,比如客户端A加锁,一段时间之后客户端A解锁,在执行jedis.del()之前,锁突然过期了,此时客户端B尝试加锁成功,然后客户端A再执行del()方法,则将客户端B的锁给解除了。
首先需要引入redisson
org.springframework.boot
spring-boot-starter-data-redis
org.redisson
redisson
3.4.3
生成Redisson的bean
支持单机,主从,哨兵,集群等模式,具体方式请参考https://github.com/redisson/redisson/wiki/2.-%E9%85%8D%E7%BD%AE%E6%96%B9%E6%B3%95,这里只演示集群环境。
@Bean
Redisson redissonSentinel() {
Config config = new Config();
config.useClusterServers()
.setScanInterval(2000) // 集群状态扫描间隔时间,单位是毫秒
//可以用"rediss://"来启用SSL连接
.addNodeAddress("redis://10.82.0.102:7000")
.addNodeAddress("redis://10.82.0.102:7001")
.addNodeAddress("redis://10.82.0.102:7002")
.addNodeAddress("redis://10.82.0.102:7003")
.addNodeAddress("redis://10.82.0.102:7004")
.addNodeAddress("redis://10.82.0.102:7005");
return (Redisson)Redisson.create(config);
}
这里只是简单展示,配置更加详细的,参考上面网站。
简单使用实现:
@Autowired
Redisson redisson;
RLock lock = redisson.getLock(key);
lock.lock(60, TimeUnit.SECONDS); //设置60秒自动释放锁 (默认是30秒自动过期)
//执行的业务代码
lock.unlock(); //释放锁
关于Redisson 更加全面详细锁的情况,前往:https://github.com/redisson/redisson/wiki/8.-%E5%88%86%E5%B8%83%E5%BC%8F%E9%94%81%E5%92%8C%E5%90%8C%E6%AD%A5%E5%99%A8
就这样通过redisson就实现redis分布式锁,内部帮我们解决了上一篇提到的注意的地方。使用redisson更加体现一切皆对象,我们不需要知道内部如何实现,只需知道如何使用就行。当然作为一个积极进取的程序员还是要了解底层实现的。
java.util.concurrent.locks
中包含了 JDK 提供的在多线程情况下对共享资源的访问控制的一系列工具,它们可以帮助我们解决进程内多线程并发时的数据一致性问题。
但是在分布式系统中,JDK 原生的并发锁工具在一些场景就无法满足我们的要求了,这就是为什么要使用分布式锁。我总结了一句话,分布式锁是用于解决分布式系统中操作共享资源时的数据一致性问题。
分布式系统中运行着多个节点,必须确保在同一时刻只能有一个节点的一个线程获得锁,这是最基本的一点。
分布式系统中,可能产生死锁的情况要相对复杂一些。分布式系统是处在复杂网络环境中的,当一个节点获取到锁,如果它在释放锁之前挂掉了,或者因网络故障无法执行释放锁的命令,都会导致其他节点无法申请到锁。
因此分布式锁有必要设置时效,确保在未来的一定时间内,无论获得锁的节点发生了什么问题,最终锁都能被释放掉。
对于访问量大的共享资源,如果针对其获取锁时造成长时间的等待,导致大量节点阻塞,是绝对不能接受的。
所以设计分布式锁时要能够掌握锁持有者的动态,若判断锁持有者处于不活动状态,要能够强制释放其持有的锁。
此外,排队等待锁的节点如果不知道锁何时会被释放,则只能隔一段时间尝试获取一次锁,这样无法保证资源的高效利用,因此当锁释放时,要能够通知等待队列,使一个等待节点能够立刻获得锁。
考虑到一些应用场景和资源的高效利用,锁要设计成可重入的,就像 JDK 中的 ReentrantLock 一样,同一个线程可以重复拿到同一个资源的锁。
本文中 Redisson 的代码版本为 2.2.17-SNAPSHOT。
这里以 lock()
方法为例,其他一系列方法与其核心实现基本一致。
先来看 lock() 的基本用法
RLock lock = redisson.getLock("foobar"); // 1.获得锁对象实例
lock.lock(); // 2.获取分布式锁
try {
// do sth.
} finally {
lock.unlock(); // 3.释放锁
}
getLock()
方法取得一个 RLock 实例。lock()
方法尝试获取锁,如果成功获得锁,则继续往下执行,否则等待锁被释放,然后再继续尝试获取锁,直到成功获得锁。unlock()
方法释放获得的锁,并通知等待的节点锁已释放。下面来看看 RedissonLock 的具体实现
org.redisson.Redisson#getLock()
@Override
public RLock getLock(String name) {
return new RedissonLock(commandExecutor, name, id);
}
这里的 RLock 是继承自 java.util.concurrent.locks.Lock 的一个 interface,getLock
返回的实际上是其实现类 RedissonLock 的实例。
来看看构造 RedissonLock 的参数
eval
命令来执行 Lua 脚本,所以要求 Redis 的版本必须为 2.6 或以上,否则你可能要自己来实现 CommandExecutor。关于 Redisson 的 CommandExecutor 以后会专门解读,所以本次就不多说了。"foobar"
,具体业务中通常可能使用共享资源的唯一标识作为该名称。org.redisson.RedissonLock#lock()
此处略过前面几个方法的层层调用,直接看最核心部分的方法 lockInterruptibly()
,该方法在 RLock 中声明,支持对获取锁的线程进行中断操作。在直接使用 lock()
方法获取锁时,最后实际执行的是 lockInterruptibly(-1, null)
。
@Override
public void lockInterruptibly(long leaseTime, TimeUnit unit) throws InterruptedException {
// 1.尝试获取锁
Long ttl = tryAcquire(leaseTime, unit);
// 2.获得锁成功
if (ttl == null) {
return;
}
// 3.等待锁释放,并订阅锁
long threadId = Thread.currentThread().getId();
Future future = subscribe(threadId);
get(future);
try {
while (true) {
// 4.重试获取锁
ttl = tryAcquire(leaseTime, unit);
// 5.成功获得锁
if (ttl == null) {
break;
}
// 6.等待锁释放
if (ttl >= 0) {
getEntry(threadId).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
} else {
getEntry(threadId).getLatch().acquire();
}
}
} finally {
// 7.取消订阅
unsubscribe(future, threadId);
}
}
null
则说明没有已存在的锁并成功获得锁。release()
方法会被调用,此时被信号量阻塞的等待队列中的一个线程就可以继续尝试获取锁了。下面着重看看 tryAcquire()
方法的实现,
private Long tryAcquire(long leaseTime, TimeUnit unit) {
// 1.将异步执行的结果以同步的形式返回
return get(tryAcquireAsync(leaseTime, unit, Thread.currentThread().getId()));
}
private Future tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId) {
if (leaseTime != -1) {
return tryLockInnerAsync(leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
}
// 2.用默认的锁超时时间去获取锁
Future ttlRemainingFuture = tryLockInnerAsync(LOCK_EXPIRATION_INTERVAL_SECONDS,
TimeUnit.SECONDS, threadId, RedisCommands.EVAL_LONG);
ttlRemainingFuture.addListener(new FutureListener() {
@Override
public void operationComplete(Future future) throws Exception {
if (!future.isSuccess()) {
return;
}
Long ttlRemaining = future.getNow();
// 成功获得锁
if (ttlRemaining == null) {
// 3.锁过期时间刷新任务调度
scheduleExpirationRenewal();
}
}
});
return ttlRemainingFuture;
}
Future tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId,
RedisStrictCommand command) {
internalLockLeaseTime = unit.toMillis(leaseTime);
// 3.使用 EVAL 命令执行 Lua 脚本获取锁
return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,
"if (redis.call('exists', KEYS[1]) == 0) then " +
"redis.call('hset', KEYS[1], ARGV[2], 1); " +
"redis.call('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
"if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
"redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
"redis.call('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
"return redis.call('pttl', KEYS[1]);",
Collections.
EVAL
命令执行上面的 Lua 脚本来完成获取锁的操作:exists
命令发现当前 key 不存在,即锁没被占用,则执行 hset
写入 Hash 类型数据 key:全局锁名称(例如共享资源ID), field:锁实例名称(Redisson客户端ID:线程ID), value:1,并执行 pexpire
对该 key 设置失效时间,返回空值 nil
,至此获取锁成功。hexists
命令发现 Redis 中已经存在当前 key 和 field 的 Hash 数据,说明当前线程之前已经获取到锁,因为这里的锁是可重入的,则执行 hincrby
对当前 key field 的值加一,并重新设置失效时间,返回空值,至此重入获取锁成功。pttl
获取锁的剩余存活时间并返回,至此获取锁失败。以上就是对 lock()
的解读,不过在实际业务中我们可能还会经常使用 tryLock()
,虽然两者有一定差别,但核心部分的实现都是相同的,另外还有其他一些方法可以支持更多自定义参数,本文中就不一一详述了。
org.redisson.RedissonLock#unlock()
最后来看锁的释放,
@Override
public void unlock() {
// 1.通过 EVAL 和 Lua 脚本执行 Redis 命令释放锁
Boolean opStatus = commandExecutor.evalWrite(getName(), LongCodec.INSTANCE,
RedisCommands.EVAL_BOOLEAN,
"if (redis.call('exists', KEYS[1]) == 0) then " +
"redis.call('publish', KEYS[2], ARGV[1]); " +
"return 1; " +
"end;" +
"if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " +
"return nil;" +
"end; " +
"local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " +
"if (counter > 0) then " +
"redis.call('pexpire', KEYS[1], ARGV[2]); " +
"return 0; " +
"else " +
"redis.call('del', KEYS[1]); " +
"redis.call('publish', KEYS[2], ARGV[1]); " +
"return 1; "+
"end; " +
"return nil;",
Arrays.
EVAL
命令执行 Lua 脚本来释放锁:publish
命令发布释放锁消息并返回 1
。nil
。hincrby
对锁的值减一。0
;如果刚才释放的已经是最后一把锁,则执行 del
命令删除锁的 key,并发布锁释放消息,返回 1
。nil
的情况(即第2中情况),因为自己不是锁的持有者,不允许释放别人的锁,故抛出异常。1
的情况,该锁的所有实例都已全部释放,所以不需要再刷新锁的失效时间。写了这么多,其实最主要的就是上面的两段 Lua 脚本,基于 Redis 的分布式锁的设计完全体现在其中,看完这两段脚本,再回顾一下前面的 设计分布式锁要注意的问题 就豁然开朗了。