如何用redis正确实现分布式锁?

先把结论抛出来:redis无法正确实现分布式锁!即使是redis单节点也不行!redis的所谓分布式锁无法用在对锁要求严格的场景下,比如:同一个时间点只能有一个客户端获取锁。

首先来看下单节点下一般redis分布式锁的实现,其实就是个set:

加锁:

 /**
     * 尝试获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @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;
    }
 

可以看到,加锁其实就一行代码:jedis.set(String key, String value, String nxxx, String expx, int time),这个set()方法一共有五个参数:

(1)第一个为key,我们使用key来当锁,因为key是唯一的。

(2)第二个为value,我们传的是requestId,很多童鞋可能不明白,有key作为锁不就够了吗,为什么还要用到value?原因就是我们在上面讲到可靠性时,分布式锁要满足第四个条件解铃还须系铃人,通过给value赋值为requestId,我们就知道这把锁是哪个请求加的了,在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成。

(3)第三个为nxxx,这个参数我们填的是NX,意思是SET IF NOT EXIST,即当key不存在时,我们进行set操作;若key已经存在,则不做任何操作;

(4)第四个为expx,这个参数我们传的是PX,意思是我们要给这个key加一个过期的设置,具体时间由第五个参数决定。

(5)第五个为time,与第四个参数相呼应,代表key的过期时间

解锁:

/**
     * 释放分布式锁
     * @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服务端执行,首先获取锁对应的value值,检查是否与requestId相等,如果相等则删除锁(解锁)。使用Lua语言主要是确保上述操作是原子性的。

看上去似乎是完美无瑕的一种分布式锁的实现方式,我们重新看下加锁的代码:

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:

线程1在执行set的时候,redis服务端已经执行成功,但是因为网络原因,响应还没有返回给客户端,过了expireTime时间以后,响应终于回来了,对于线程1来说,它是拿到了分布式锁的,但是注意,此时的锁已经是失效的了!如果此时又来个线程2申请加锁,显然也能获取锁,因为线程1的锁已经失效了,此时就会有2个线程同时获取锁!

场景2:

线程1执行完set以后,redis服务端执行成功,在执行if的时候,jvm发生了FullGC,应用暂停,超过了expireTime以后,GC完成,程序继续执行,此时线程1仍然认为自己是持有锁的,实际上锁已经过期了!如果此时线程2又来申请加锁,成功,此时线程2也获得了锁,因此也会出现2个线程同时执行被锁保护的代码的情况!

综上,可以看出来,就算是在单节点情况下,redis也是无法实现严格意义上的分布式锁的!

如果想要实现严格意义上的分布式锁呢?最常用的就是zookeeper了。我们来看下zookeeper为啥可以实现分布式锁。

zookeeper实现分布式锁的步骤:

假设锁空间的根节点为/lock:

(1)客户端连接zookeeper,并在/lock下创建临时的且有序的子节点,第一个客户端对应的子节点为/lock/lock-0000000000,第二个为/lock/lock-0000000001,以此类推。

(2)客户端获取/lock下的子节点列表,判断自己创建的子节点是否为当前子节点列表中序号最小的子节点,如果是则认为获得锁,否则监听/lock的子节点变更消息,获得子节点变更通知后重复此步骤直至获得锁;

(3)执行业务代码;

(4)完成业务流程后,删除对应的子节点释放锁。

上面的步骤可以看出来,zookeeper跟redis不一样,它是完全不依赖客户端的状态的,因此zookeeper才可以严格实现分布式锁!

redis的分布式锁是不是就一无是处了呢?当然不是!在一些要求不是那么严格的场景下还是可以使用的,比如:凌晨1点执行定时任务出报表,哪怕是执行2次也没什么问题。

参考文献:

https://www.cnblogs.com/linjiqin/p/8003838.html

http://zhangtielei.com/posts/blog-redlock-reasoning.html

https://blog.csdn.net/qiangcuo6087/article/details/79067136

原文地址:https://www.cnblogs.com/yaphetsfang/p/12069042.html

时间: 2024-11-05 18:35:24

如何用redis正确实现分布式锁?的相关文章

如何用 redis 造一把分布式锁

基本概念 锁 wiki:In computer science, a lock or mutex (from mutual exclusion) is a synchronization mechanism for enforcing limits on access to a resource in an environment where there are many threads of execution. A lock is designed to enforce a mutual e

基于Redis的简单分布式锁的原理

参考资料:https://redis.io/commands/setnx 加锁是为了解决多线程的资源共享问题.Java中,单机环境的锁可以用synchronized和Lock,其他语言也都应该有自己的加锁机制.但是到了分布式环境,单机环境中的锁就没什么作用了,因为每个节点只能获取到自己机器内存中的锁,而无法获取到其他节点的锁状态. 分布式环境中,应该用专门的分布式锁来解决需要加锁的问题.分布式锁有很多实现,Redis,zookeeper都可以.这里以Redis为例,讲述一下基于Redis的分布式

基于redis实现的分布式锁

RedisLockHelper.java /** * Created by BingZhong on 2017/7/29. * * 基于Redis实现的分布式锁 */ public final class RedisLockHelper { private static Logger logger = LoggerFactory.getLogger(RedisLockHelper.class); /** * redis操作帮助类,可以是其他封装了redis操作的类 */ private Redi

阿里JAVA面试题剖析:一般实现分布式锁都有哪些方式?使用 Redis 如何设计分布式锁?

面试原题 一般实现分布式锁都有哪些方式?使用 redis 如何设计分布式锁?使用 zk 来设计分布式锁可以吗?这两种分布式锁的实现方式哪种效率比较高? 面试官心理分析 其实一般问问题,都是这么问的,先问问你 zk,然后其实是要过度到 zk 关联的一些问题里去,比如分布式锁.因为在分布式系统开发中,分布式锁的使用场景还是很常见的. 面试题剖析 Redis 分布式锁 官方叫做 RedLock 算法,是 Redis 官方支持的分布式锁算法. 这个分布式锁有 3 个重要的考量点: 互斥(只能有一个客户端

redis系列:分布式锁

redis系列:分布式锁 1 介绍 这篇博文讲介绍如何一步步构建一个基于Redis的分布式锁.会从最原始的版本开始,然后根据问题进行调整,最后完成一个较为合理的分布式锁. 本篇文章会将分布式锁的实现分为两部分,一个是单机环境,另一个是集群环境下的Redis锁实现.在介绍分布式锁的实现之前,先来了解下分布式锁的一些信息. 2 分布式锁 2.1 什么是分布式锁? 分布式锁是控制分布式系统或不同系统之间共同访问共享资源的一种锁实现,如果不同的系统或同一个系统的不同主机之间共享了某个资源时,往往需要互斥

Redis .net 客户端 分布式锁

关于Redis分布式锁的参考链接:http://redis.io/topics/distlock. 在我们项目中,之前琢磨用:ServiceStack.Redis,发现ServiceStack.Redis收费的,每小时内操作6000次以上报错:“The free-quota limit on '6000 Redis requests per hour' has been reached……” 那么看看别的Redis客户端: StackExchange.Redis貌似不支持分布式锁,还是我不知道?

使用redis构建可靠分布式锁

关于分布式锁的概念,具体实现方式,直接参阅下面两个帖子,这里就不多介绍了. 分布式锁的多种实现方式 分布式锁总结 对于分布式锁的几种实现方式的优劣,这里再列举下 1. 数据库实现方式 优点:易理解 缺点:操作数据库消耗较大,性能较低.为了处理一些异常,会使得整个方案越来越复杂 2. 缓存实现方式 优点:性能好,实现起来较为方便. 缺点:通过超时时间来控制锁的失效时间并不是十分的靠谱. 3 zookeeper实现 优点:有效的解决单点问题,不可重入问题,非阻塞问题以及锁无法释放的问题. 缺点:性能

一个Redis实现的分布式锁

import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.data.redis.connection.RedisConnection; import org.springframework.data.redis.core.RedisTemplate; import

Redis实现分布式锁

http://redis.io/topics/distlock 在不同进程需要互斥地访问共享资源时,分布式锁是一种非常有用的技术手段. 有很多三方库和文章描述如何用Redis实现一个分布式锁管理器,但是这些库实现的方式差别很大,而且很多简单的实现其实只需采用稍微增加一点复杂的设计就可以获得更好的可靠性. 这篇文章的目的就是尝试提出一种官方权威的用Redis实现分布式锁管理器的算法,我们把这个算法称为RedLock,我们相信这个算法会比一般的普通方法更加安全可靠.我们也希望社区能一起分析这个算法,