Redis分布式锁——小心求证

最新推荐文章于 2024-08-13 14:41:03 发布

litteTc

最新推荐文章于 2024-08-13 14:41:03 发布

阅读量436

点赞数

分类专栏：工作记录文章标签： redis 分布式锁

本文链接：https://blog.csdn.net/qq_15769369/article/details/84646447

版权

工作记录专栏收录该内容

5 篇文章 0 订阅

订阅专栏

Redis分布式锁

大胆假设，小心求证 —— 前辈们这样说道。

近期在项目中为了防止恶意并发操作，使用到了分布式锁。

几种常见的方案：

1.Mysql乐观锁。

2.缓存

3.zookeeper。

从性能来选择：

mysql由于要走磁盘io，读写性能较差。

redis内存读写快。

zookeeper文件系统相对于内存来说还是稍有不足。

实现难度上来说：

mysql和redis都比较简单，公司也有组件支持。

zookeeper由于公司不支持安装配置，需要自己搭建集群，难度较大。

综上所述，结合一下实际场景，这里我便使用了redis作为分布式锁实现的工具。

先说一下分布式锁需要具备哪些特征：

1.互斥性，在任意时刻，只有一个客户端能够持有当前锁。

2.不会发生死锁，即使有一个客户端在拿到锁之后崩溃没有主动释放锁，也能保证之后的客户端能正常持有锁。

3.唯一性，加锁和解锁必须是同一个客户端，A客户端不能去释放B客户端的锁。

网上有许多前辈说过redis实现分布式锁是坑很多，那么我们就一步一步的看下，坑在哪，如何把坑填上吧~

第一个坑：

public static boolean lock(Jedis jedis, String key, String requestId, int expireTime) {

if(jedis.setnx(key, requestId) == 1) {

//在这个地方，客户端崩溃了~ o(╥﹏╥)o

jedis.expire(key, expireTime);

return true;

}

return false;

}

一般的写法都是通过jedis.setnx()来获取锁，之后再对锁设置过期时间。

这种写法不满足分布式锁的第二个特性，也就是说如果在如图所示的地方崩溃了，客户端获取锁之后还没来得及给锁设置过期时间，那么这个锁就一直在redis中并且不会释放，导致后续客户端永远拿不到锁。

那么，我们得想办法把坑填上去，于是补充了一段判断，并且把过期时间的设置改成了value值：

    public static boolean lock( String key, long timeout ){

        //先获取当前系统时间

        long currentTime = System.currentTimeMillis();

        //获取锁，并且设置锁到期时间=（当前时间+过期时间）

        if( jedis.setnx( key, String.valueOf( currentTime + timeout ) ) == 1 ){

            return true;

        }else{

            //如果获取锁失败，再次获取当前系统时间

            currentTime = System.currentTimeMillis();

            //拿到锁之前设置的到期时间

            long oldTime = NumberUtils.toLong( jedis.get( key ));

            //判断当前系统时间是否大于到期时间，如果大于锁的到期时间，说明锁本应该被释放

            if( currentTime > oldTime ){

                //那么重新给锁设置到期时间=（当前客户端的系统时间+过期时间）

                long getSetTime = NumberUtils.toLong( jedis.getSet( key, String.valueOf( currentTime + timeout )));

            //这里再次判断当前系统时间是否大于锁的过期时间

            //假设一下，如果两个客户端同时进行了上一步操作，都重新给锁设置了新的到期时间，A先设置，B在设置，这时A拿到的getSetTime应该是之前的的oldTime，B拿到的getSetTime则为A设置的新的过期时间。那么加上这个判断就能保证只有一个客户端能真正拿到锁，返回true。

                if( currentTime > getSetTime ){

                    return true;

                }

            }

        }
        

    return false;

}

当然，这种实现方式的问题在于

1.如果客户端的系统时间不一致，那么互斥性也不会满足，

2.如果redis节点是主从分布的，由于主从切换是异步同步数据的，所以redis并不能完全的实现锁的安全性。举个例子来说：

A客户端在master实例上获得一个锁。
在对象锁key传送到slave之前，master崩溃掉。
一个slave被选举成master。
B客户端可以获取到同个key的锁，但A也已经拿到锁，导致锁失效。

由于在公司内部所有的节点都能保证系统时间一致，并且redis节点是集群分布的，所以我采用了这种实现方式。

第二个坑：

public static void releaseLock(Jedis jedis, String Key) {

//A客户端能解B客户端的锁。

jedis.del(Key);

}

改进一下：

public static void releaseLock(Jedis jedis, String lockKey, String requestId) {

//判断当前客户端是不是加锁的客户端

if (requestId.equals(jedis.get(lockKey))) {

//如果在这一时刻，A客户端的锁突然过期了，那么B客户端获得了锁，A客户端就释放了B客户端的锁。

jedis.del(lockKey);

}

}

在释放锁阶段，一定要保证锁拥有者的唯一性，即只有当前客户端能释放自己的锁。

填坑，结合在加锁阶段的填坑方式，保证当前拿到锁的客户端不会自动释放锁的前提：

public static boolean unlock( String key ){

    if( System.currentTimeMillis() < NumberUtils.toLong( jedis.get( key ) ) && jedis.del( key ) <= 0 ){

        return false;

    }

    return true;

}

由于加锁填坑的地方并没有对锁设置过期时间，而是把时间当做了它的一个value值，那么就不存在判断是当前客户端之后锁自动释放的问题。

通过这样的一个组合方式，能很好的解决redis实现分布式锁中间遇到由于原子性的问题导致的各种坑。

小彩蛋（后续思考）：

当然，针对于redis集群来实现分布式锁现在还有更好的方式，可以直接使用redis官方实现的Redlock，或者通过以下方法加锁保证设置key和过期时间两个操作的原子性，并且释放锁的时候使用lua代码交由redis来执行，实现判断与删除的原子性：

加锁：

jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

解锁：

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));