美文网首页
Redis分布式锁

Redis分布式锁

作者: _ALID | 来源:发表于2018-08-30 23:07 被阅读15次

    为什么要用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组件,这里有一篇网易技术的博客可以看一下.

    相关文章

      网友评论

          本文标题:Redis分布式锁

          本文链接:https://www.haomeiwen.com/subject/mazdwftx.html