Redis分布式锁

为什么要用Redis

分布式环境考虑加锁,可以想到如下方法

1. 数据库字段
2. 基于Zookeeper管理机器
3. 基于缓存,可以适用Redis

基于数据库的方式个人感觉意义不大，因为大多数锁说需要保存的值非常少，为此建库建表意义不大，而且查询速度还比较慢。性能不佳。

而基于Zookeeper，可以对于每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。 问题是较为麻烦，而且效率没有使用缓存高。

如果基于缓存呢?首先性能比较好读取很快，而且像Redis都是已有部署好的集群可以直接使用。

实现

主要是使用SETNX()方法 全称就是SET IF NOT EXIST

• 返回1 说明在Redis中set了key，获得锁
• 返回0 说明该key已经被set，不能获得锁

看似很美好 直接一句话就可以实现了 但是其实存在死锁的问题

死锁问题

无论这个锁是干什么用的 都要在使用后放开锁 否则会让其他竞争者永久等待
对于这个问题一般都是考虑使用设置超时来实现的

错误的处理

先来看几个我亲自犯过的错误 一定认真看一下 可能你第一次写也是这样考虑的 如果实在等不急可以先去偷看一下正确答案。

错误A

Long result = jedis.setnx(lockKey, requestId);
if (result == 1) {
    // 若在这里程序突然崩溃，则无法设置过期时间，将发生死锁
    jedis.expire(lockKey, expireTime);
}

这是是第一次写的时候出现的问题 先通过一条命令尝试加锁再设置过期时间，但是这里有个坑，就是如果在尝试加锁完成以后程序崩了。GG这个锁这辈子也释放不了了，标准的死锁。

错误B

public static boolean wrongGetLock2(Jedis jedis, String lockKey, int expireTime) {
 
    long expires = System.currentTimeMillis() + expireTime;
    String expiresStr = String.valueOf(expires);
 
    // 如果当前锁不存在，返回加锁成功
    if (jedis.setnx(lockKey, expiresStr) == 1) {
        return true;
    }
 
    // 如果锁存在，获取锁的过期时间
    String currentValueStr = jedis.get(lockKey);
    if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
        // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间
        String oldValueStr = jedis.getSet(lockKey, expiresStr);
        if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
            // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才有权利加锁
            return true;
        }
    }
 
    // 其他情况，一律返回加锁失败
    return false;
 
}

这里看似很完美，通过对Value设置时间戳的方式防止之前的线程挂掉的情况，但是我们再看一下释放锁的方法

public static void wrongReleaseLock2(Jedis jedis, String lockKey, String requestId) {
 
    // 判断加锁与解锁是不是同一个客户端
    if (requestId.equals(jedis.get(lockKey))) {
        // 若在此时，这把锁突然不是这个客户端的，则会误解锁
        jedis.del(lockKey);
    }
}

设想一个情况，线程A加锁并设置过期时间。突然线程A挂了这是线程B苦苦等到了过期时间成功拿到了锁。正准备爽一下的时候，突然A满血复活了，可能会“正常”的释放锁。B就不能忍了，我等你这么长时间好不容易拿到了锁，你回来直接给我释放了。

A加锁 - A死亡 - 超时 - B加锁 - A复活 - A释放锁（这时B还在执行）

说了这么多，都感觉Redis是不是不适合做分布式锁啊！那我们来看一下正确答案。

正确答案

这里我也是学习了别人的代码，需要使用Lua脚本。

 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代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。

那么这段Lua代码的功能是什么呢？其实很简单，首先获取锁对应的value值，检查是否与requestId相等，如果相等则删除锁（解锁）。那么为什么要使用Lua语言来实现呢？因为要确保上述操作是原子性的。

因为：eval命令执行Lua代码的时候，Lua代码将被当成一个命令去执行，并且直到eval命令执行完成，Redis才会执行其他命令。保证了其原子性。

最后

其实Redis本身实现的分布式锁的确存在各种问题。有人认为它并不安全
但是对于Redis是多机部署的，那么可以尝试使用Redisson实现分布式锁，这是Redis官方提供的Java组件,这里有一篇网易技术的博客可以看一下.