文档章节

【分布式缓存系列】Redis实现分布式锁的正确姿势

编辑之路
 编辑之路
发布于 01/21 14:02
字数 2700
阅读 3967
收藏 203

一、前言

  在我们日常工作中,除了Spring和Mybatis外,用到最多无外乎分布式缓存框架——Redis。但是很多工作很多年的朋友对Redis还处于一个最基础的使用和认识。所以我就像把自己对分布式缓存的一些理解和应用整理一个系列,希望可以帮助到大家加深对Redis的理解。本系列的文章思路先从Redis的应用开始。再解析Redis的内部实现原理。最后以经常会问到Redist相关的面试题为结尾。

二、分布式锁的实现要点

 为了实现分布式锁,需要确保锁同时满足以下四个条件:

  1. 互斥性。在任意时刻,只有一个客户端能持有锁
  2. 不会发送死锁。即使一个客户端持有锁的期间崩溃而没有主动释放锁,也需要保证后续其他客户端能够加锁成功
  3. 加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给释放了。
  4. 容错性。只要大部分的Redis节点正常运行,客户端就可以进行加锁和解锁操作。

三、Redis实现分布式锁的错误姿势

3.1 加锁错误姿势

   在讲解使用Redis实现分布式锁的正确姿势之前,我们有必要来看下错误实现方式。

  首先,为了保证互斥性和不会发送死锁2个条件,所以我们在加锁操作的时候,需要使用SETNX指令来保证互斥性——只有一个客户端能够持有锁。为了保证不会发送死锁,需要给锁加一个过期时间,这样就可以保证即使持有锁的客户端期间崩溃了也不会一直不释放锁。

  为了保证这2个条件,有些人错误的实现会用如下代码来实现加锁操作:

/**
     * 实现加锁的错误姿势
     * @param jedis
     * @param lockKey
     * @param requestId
     * @param expireTime
     */
    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 和expire是两条Redis指令,不具备原子性,如果程序在执行完setnx之后突然崩溃,导致没有设置锁的过期时间,从而就导致死锁了。因为这个客户端持有的所有不会被其他客户端释放,持有锁的客户端又崩溃了,也不会主动释放。从而该锁永远不会释放,导致其他客户端也获得不能锁。从而其他客户端一直阻塞。所以针对该代码正确姿势应该保证setnx和expire原子性

  实现加锁操作的错误姿势2。具体实现如下代码所示

/**
     * 实现加锁的错误姿势2
     * @param jedis
     * @param lockKey
     * @param expireTime
     * @return
     */
    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;
    }

  这个加锁操作咋一看没有毛病对吧。那以上这段代码的问题毛病出在哪里呢?

  1. 由于客户端自己生成过期时间,所以需要强制要求分布式环境下所有客户端的时间必须同步。

  2. 当锁过期的时候,如果多个客户端同时执行jedis.getSet()方法,虽然最终只有一个客户端加锁,但是这个客户端的锁的过期时间可能被其他客户端覆盖。不具备加锁和解锁必须是同一个客户端的特性。解决上面这段代码的方式就是为每个客户端加锁添加一个唯一标示,已确保加锁和解锁操作是来自同一个客户端。

3.2 解锁错误姿势

  分布式锁的实现无法就2个方法,一个加锁,一个就是解锁。下面我们来看下解锁的错误姿势。

  错误姿势1.

/**
     * 解锁错误姿势1
     * @param jedis
     * @param lockKey
     */
    public static void wrongReleaseLock1(Jedis jedis, String lockKey) {
        jedis.del(lockKey);
    }

  上面实现是最简单直接的解锁方式,这种不先判断拥有者而直接解锁的方式,会导致任何客户端都可以随时解锁。即使这把锁不是它上锁的。

  错误姿势2:

/**
     * 解锁错误姿势2
     * @param jedis
     * @param lockKey
     * @param requestId
     */
    public static void wrongReleaseLock2(Jedis jedis, String lockKey, String requestId) {

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

  既然错误姿势1中没有判断锁的拥有者,那姿势2中判断了拥有者,那错误原因又在哪里呢?答案又是原子性上面。因为判断和删除不是一个原子性操作。在并发的时候很可能发生解除了别的客户端加的锁。具体场景有:客户端A加锁,一段时间之后客户端A进行解锁操作时,在执行jedis.del()之前,锁突然过期了,此时客户端B尝试加锁成功,然后客户端A再执行del方法,则客户端A将客户端B的锁给解除了。从而不也不满足加锁和解锁必须是同一个客户端特性。解决思路就是需要保证GET和DEL操作在一个事务中进行,保证其原子性。

四、Redis实现分布式锁的正确姿势

   刚刚介绍完了错误的姿势后,从上面错误姿势中,我们可以知道,要使用Redis实现分布式锁。加锁操作的正确姿势为:

  1. 使用setnx命令保证互斥性
  2. 需要设置锁的过期时间,避免死锁
  3. setnx和设置过期时间需要保持原子性,避免在设置setnx成功之后在设置过期时间客户端崩溃导致死锁
  4. 加锁的Value 值为一个唯一标示。可以采用UUID作为唯一标示。加锁成功后需要把唯一标示返回给客户端来用来客户端进行解锁操作

  解锁的正确姿势为:

  1. 需要拿加锁成功的唯一标示要进行解锁,从而保证加锁和解锁的是同一个客户端

        在此我向大家推荐一个架构学习交流圈:830478757  帮助突破瓶颈 提升思维能力

  2. 解锁操作需要比较唯一标示是否相等,相等再执行删除操作。这2个操作可以采用Lua脚本方式使2个命令的原子性。

  Redis分布式锁实现的正确姿势的实现代码:

public interface DistributedLock {
    /**
     * 获取锁
     * @author zhi.li
     * @return 锁标识
     */
    String acquire();

    /**
     * 释放锁
     * @author zhi.li
     * @param indentifier
     * @return
     */
    boolean release(String indentifier);
}

/**
 * @author zhi.li
 * @Description
 * @created 2019/1/1 20:32
 */
@Slf4j
public class RedisDistributedLock implements DistributedLock{

    private static final String LOCK_SUCCESS = "OK";
    private static final Long RELEASE_SUCCESS = 1L;
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";

    /**
     * redis 客户端
     */
    private Jedis jedis;

    /**
     * 分布式锁的键值
     */
    private String lockKey;

    /**
     * 锁的超时时间 10s
     */
    int expireTime = 10 * 1000;

    /**
     * 锁等待,防止线程饥饿
     */
    int acquireTimeout  = 1 * 1000;

    /**
     * 获取指定键值的锁
     * @param jedis jedis Redis客户端
     * @param lockKey 锁的键值
     */
    public RedisDistributedLock(Jedis jedis, String lockKey) {
        this.jedis = jedis;
        this.lockKey = lockKey;
    }

    /**
     * 获取指定键值的锁,同时设置获取锁超时时间
     * @param jedis jedis Redis客户端
     * @param lockKey 锁的键值
     * @param acquireTimeout 获取锁超时时间
     */
    public RedisDistributedLock(Jedis jedis,String lockKey, int acquireTimeout) {
        this.jedis = jedis;
        this.lockKey = lockKey;
        this.acquireTimeout = acquireTimeout;
    }

    /**
     * 获取指定键值的锁,同时设置获取锁超时时间和锁过期时间
     * @param jedis jedis Redis客户端
     * @param lockKey 锁的键值
     * @param acquireTimeout 获取锁超时时间
     * @param expireTime 锁失效时间
     */
    public RedisDistributedLock(Jedis jedis, String lockKey, int acquireTimeout, int expireTime) {
        this.jedis = jedis;
        this.lockKey = lockKey;
        this.acquireTimeout = acquireTimeout;
        this.expireTime = expireTime;
    }

    @Override
    public String acquire() {
        try {
            // 获取锁的超时时间,超过这个时间则放弃获取锁
            long end = System.currentTimeMillis() + acquireTimeout;
            // 随机生成一个value
            String requireToken = UUID.randomUUID().toString();
            while (System.currentTimeMillis() < end) {
                String result = jedis.set(lockKey, requireToken, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
                if (LOCK_SUCCESS.equals(result)) {
                    return requireToken;
                }
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        } catch (Exception e) {
            log.error("acquire lock due to error", e);
        }

        return null;
    }

    @Override
    public boolean release(String identify) {
    if(identify == null){
            return false;
        }

        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        Object result = new Object();
        try {
            result = jedis.eval(script, Collections.singletonList(lockKey),
                Collections.singletonList(identify));
        if (RELEASE_SUCCESS.equals(result)) {
            log.info("release lock success, requestToken:{}", identify);
            return true;
        }}catch (Exception e){
            log.error("release lock due to error",e);
        }finally {
            if(jedis != null){
                jedis.close();
            }
        }

        log.info("release lock failed, requestToken:{}, result:{}", identify, result);
        return false;
    }
}
  下面就以秒杀库存数量为场景,测试下上面实现的分布式锁的效果。具体测试代码如下:

public class RedisDistributedLockTest {
    static int n = 500;
    public static void secskill() {
        System.out.println(--n);
    }

    public static void main(String[] args) {
        Runnable runnable = () -> {
            RedisDistributedLock lock = null;
            String unLockIdentify = null;
            try {
                Jedis conn = new Jedis("127.0.0.1",6379);
                lock = new RedisDistributedLock(conn, "test1");
                unLockIdentify = lock.acquire();
                System.out.println(Thread.currentThread().getName() + "正在运行");
                在此我向大家推荐一个架构学习交流圈:830478757 帮助突破瓶颈 提升思维能力
                secskill();
            } finally {
                if (lock != null) {
                    lock.release(unLockIdentify);
                }
            }
        };

        for (int i = 0; i < 10; i++) {
            Thread t = new Thread(runnable);
            t.start();
        }
    }
}

  运行效果如下图所示。从图中可以看出,同一个资源在同一个时刻只能被一个线程获取,从而保证了库存数量N的递减是顺序的。

  

五、总结

  这样是不是已经完美使用Redis实现了分布式锁呢?答案是并没有结束。上面的实现代码只是针对单机的Redis没问题。但是现实生产中大部分都是集群的或者是主备的。但上面的实现姿势在集群或者主备情况下会有相应的问题。这里先买一个关子,在后面一篇文章将详细分析集群或者主备环境下Redis分布式锁的实现方式。

© 著作权归作者所有

共有 人打赏支持
编辑之路
粉丝 48
博文 38
码字总数 87213
作品 0
长沙
私信 提问
加载中

评论(18)

耒耒耒耒耒
耒耒耒耒耒
可以试试 redssion
搁羽
搁羽

引用来自“xiaour”的评论

引用来自“Mr_陈”的评论

可以试试 Lua 脚本

@Mr_陈 codis好像不支持script命令

codis支持,不过只能落在某一台机器上,所以,一些复杂操作可能会出错,不过简单的加锁,足够了。。。
J
JavaGok
我觉得费劲了。

通过jedis.set(xx, xx, xx, xx); 来原子存储并且设置过期时间即可。死锁即等待过期时间通过,然后把key存储到ThreadLocal中。
解锁的时候只需要通过 ThreadLocal 的值是否和key相同就行了。
依然藏锋

引用来自“搁羽”的评论

嵌lua脚本 直接保证原子性, 写这么多,还不够麻烦的
确实 Lua script 就行,搞这么多本地锁。。。可能是为了推广那个群号吧!😬
xiaour
xiaour

引用来自“Mr_陈”的评论

可以试试 Lua 脚本

@Mr_陈 codis好像不支持script命令
小树鹿鸣
小树鹿鸣

引用来自“银杏卡卡”的评论

正确姿势就是懒得整,用redission,哈哈哈
正解
前端攻城老湿
前端攻城老湿
在此我向大家推荐一个架构学习交流圈:830478757 帮助突破瓶颈 提升思维能力
江南红衣
江南红衣
https://github.com/yujiasun/Distributed-Kit
目前使用这个
n
nilei
任何用本地时钟的锁都是错的。
搁羽
搁羽
嵌lua脚本 直接保证原子性, 写这么多,还不够麻烦的
Redis 分布式锁的正确实现方式( Java 版 )

原文出处:吴兆锋 前言 分布式锁一般有三种实现方式:1. 数据库乐观锁;2. 基于Redis的分布式锁;3. 基于ZooKeeper的分布式锁。本篇博客将介绍第二种方式,基于Redis实现分布式锁。虽然网上已...

吴兆锋
2017/12/02
0
0
经典:Redis分布式锁的正确实现方式

分布式锁一般有三种实现方式:1. 数据库乐观锁;2. 基于Redis的分布式锁;3. 基于ZooKeeper的分布式锁。本篇博客将介绍第二种方式,基于Redis实现分布式锁。虽然网上已经有各种介绍Redis分布...

架构之家
2018/01/14
0
0
2016文章汇总

Java系列: JVM系列:jvm基本结构 JVM系列:java中JVM的原理 JVM系列:解决JVM最大内存设置问题 JVM系列:JVM参数设置、分析 HashMap , HashTable , ConcurrentHashMap 源码比较 从使用到原理学习...

www19
2017/01/03
0
0
一种基于分布式锁实现Redis与MYSQL数据一致性的方法

Abstract   本发明公开一种基于分布式锁实现Redis与MYSQL数据一致性的方法,包括以下步骤:一、加锁:对要读写的记录先添加分布式同步锁,该分布式同步锁只针对记录进行锁操作,当记录添加...

qwfys
2018/08/06
0
0
一文弄懂“分布式锁”,一直以来你的选择依据正确吗?

我们本文主要会关注的问题是“分布式锁”的问题。 多线程情况下对共享资源的操作需要加锁,避免数据被写乱,在分布式系统中,这个问题也是存在的,此时就需要一个分布式锁服务。 常见的分布式...

向南
2018/12/04
0
0

没有更多内容

加载失败,请刷新页面

加载更多

Httpd 整合 Tomcat 步骤

环境:Tomcat8 + Httpd2.4 工作原理:借助于Tomcat的AJP连接器实现Apache与Tomcat的通信 配置步骤: 1. 配置httpd.conf 新增: Include conf/extra/mod_jk.conf 修改:添加 index.jsp <IfM...

ZeroneLove
昨天
1
0
Docker笔记3——容器命令(未写完,明天整理接着写)

未写完,明天整理接着写 新建并启动容器 docker run docker run [OPTIONS] IMAGE [COMMEND] [ARG...] OPTIONS: --name=[容器新名字] :为容器指定一个名称 -d:后台运行容器,并返回容器ID,...

HappyBKs
昨天
1
0
2018个人年终总结

感谢领导的信任和指导,新的一年获得了很多成长和提高,改掉了很多不好的习惯。 在这一年里,我在领导的帮助下,主要完成了以下功能: 1、完成上海银行版本投资营销相关功能的开发。 2、完成车...

万山红遍
昨天
12
0
保密工作与linux系统的发展

保密工作从性质上可以分成商业方面的保密和国家安全方面的保密。由于自己从事的是IT方面的工作,工作中必然会接触涉及到计算机信息方面的相关文件。加上单位已近通过武器装备科研生产单位二级...

linux-tao
昨天
3
0
Spark共享变量

概述 Spark程序的大部分操作都是RDD操作,通过传入函数给RDD操作函数来计算。这些函数在不同的节点上并发执行,但每个内部的变量有不同的作用域,不能相互访问,所以有时会不太方便,Spark提...

仟昭
昨天
2
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部