四、Redis分布式锁

L_D_Y_K

已于 2022-08-25 10:33:17 修改

阅读量720

点赞数 1

分类专栏： Redis 文章标签： redis 分布式锁 redisson 死锁

于 2021-01-07 16:02:28 首次发布

本文链接：https://blog.csdn.net/L_D_Y_K/article/details/112316182

版权

Redis 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

四、Redis分布式锁

Java中的锁我们通常以synchronized 、Lock来使用它，但是只能保证在同一个JVM进程内中执行。如果在分布式集群环境下呢？分布式锁的实现有很多，比如基于数据库乐观锁、Redis、zookeeper、memcached、系统文件等。

1、命令行加锁：SET lock_key random_value NX PX 5000 执行成功，则证明客户端获取到了锁。

random_value：是客户端生成的唯一的字符串。

NX：代表只在键不存在时，才对键进行设置操作。

PX：5000 设置键的过期时间为5000毫秒。

EX：可以让该 key 在超时之后自动删除。

2、Jedis加锁代码实现

(1)、Long setnx(final String key, final String value)：该方法只会对不存在的key设值，返回1代表获取锁成功；对存在的key设值，会返回0代表获取锁失败。value是客户端锁的唯一标识，不能重复，例：UUID或System.currentTimeMillis() (获取锁的时间)+锁持有的时间。

命令格式：SETNX key value

注：执行setnx加了锁，需要再次执行语句设置过期时间，如果在setnx之后宕机，所就不会释放，就会产生死锁。无法保证两步操作的原子性，不可取

(2)、String getSet(final String key, final String value)：返回redis中key对应的oldValue，然后再把key原来的值oldValue更新为新传入的值value。

命令格式：GETSET key value

注：当某个客户端锁过期时间，多个客户端开始争抢锁。虽然最后只有一个客户端能成功锁，但是获取锁失败的客户端调用getSet能覆盖获取锁成功客户端的value。当客户端的value被覆盖，会造成锁不具有标识性，会造成客户端没有释放锁。该方式同样不可取。

(3)、String set(final String key, final String value, final String nxxx, final String expx, final long time)：该方法合并普通的set()和expire()操作，保证NX和EX的原子性。不能把两个命令(NX EX)分开执行，如果在 NX 之后程序出现问题就有可能产生死锁。

private static final String SET_IF_NOT_EXIST = "NX";
private static final String SET_WITH_EXPIRE_TIME = "PX”;
private final String LOCK_PREFIX = "test:lock:key-";

public  boolean lock(String key, String value, long expireSeconds) {
    String key = LOCK_PREFIX + MD5.convertToMD5(key);
    String result = this.jedis.set(LOCK_PREFIX +key, value, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireSeconds);
    if (LOCK_MSG.equals(result)){
        return true ;
    }else {
        return false ;
    }
}

Jedis（单机）、JedisCluster（集群）

3、RedisTemplate加锁代码实现

(1)、加锁：

private final String LOCK_PREFIX = "test:lock:key-";
@Resource
private RedisTemplate<String, String> redisTemplate;

public boolean lock(String keyLock, String value, long expireSeconds){
    redisTemplate.opsForValue().setIfAbsent(LOCK_PREFIX + keyLock, value, expireSeconds, TimeUnit.SECONDS);
}

(2)、解锁：

//单个删除
redisTemplate.delete(keyLock);
//批量删除
List<String> keys;
redisTemplate.delete(keys);

(3)、指定key失效时间：redisTemplate.getExpire(key,TimeUnit.SECONDS);

(4)、根据key获取过期时间：redisTemplate.expire(key, time, TimeUnit.SECONDS);

(5)、判断key是否存在：redisTemplate.hasKey(key);

(6)、Jedis和RedisTemplate区别

Jedis是Redis官方推荐的面向Java的操作Redis的客户端，而RedisTemplate是spring-data-redis.jar中对JedisApi的高度封装。spring-data-redis.jar相对于Jedis来说可以方便地更换Redis的Java客户端，比Jedis多了自动管理连接池的特性，方便与其他Spring框架进行搭配使用如SpringCache。原生Jedis效率优于RedisTemplate。

4、解锁：将key键删除，加锁时需要传递一个参数，将该参数作为这个 key 的 value，这样每次解锁时判断 value 是否相等从而知道这个锁是不是该进程自己的。

//此方式无法保证get和del的原子性
if(value.equals(redisTemplate.opsForValue().get(keyLock))){
    redisTemplate.delete(keyLock);
}

解决方案：

(1)、使用lua脚本

使用lua脚本合并get()和del()操作，先判断value是否相等，相等再执行del命令。lua脚本能保证这里两个操作的原子性。

try {
    ...
} catch (Exception e) {
    ...
} finally {
    //获取Jedis资源
    Jedis jedis = RedisUtils.getJedis();
    //定义lua脚本
    String script = "if redis.call('get',KEYS[1]) == ARGV[1]" +
            "then" +
            "    return redis.call('del',KEYS[1])" +
            "else" +
            "    return 0" +
            "end";
    try {
        //对指定的key、value执行脚本
        Object o = jedis.eval(script, Collections.singletonList(keyLock), Collections.singletonList(value));
        if ("1".equals(o.toString())) {
            System.out.println("del redis lock ok");
        }else {
            System.out.println("del redis lock error");
        }
    }finally {
        //关闭Jedis资源
        if (null != jedis) {
            jedis.close();
        }
    }
}

(2)、使用Redis事务

while (true) {
    //监视key
    redisTemplate.watch(keyLock);
    if(value.equals(redisTemplate.opsForValue().get(keyLock))){
        //开启事务支持
        redisTemplate.setEnableTransactionSupport(true);
        //开始事务
        redisTemplate.multi();
        redisTemplate.delete(keyLock);
        //执行命令，如果返回null，则事务执行失败，key对应的value被别人修改过，需要重新执行。
        List<Object> list = redisTemplate.exec();
        if(list == null){
            continue;
        }
    }
    //解除监视
    redisTemplate.unwatch();
    break;
}

5、Redisson分布式锁实现原理：

Redisson这个开源框架对Redis分布式锁的实现原理，Jedis和Redisson都是Java中对Redis操作的封装。Jedis只是简单的封装了Redis的API库，可以看作是Redis客户端，它的方法和Redis的命令很类似。Redisson不仅封装了redis，还封装了对更多数据结构的支持，以及锁等功能，相比于Jedis更强大。但Jedis相比于Redisson更原生一些，更灵活。

//获取Redisson对象
RLock lock = redisson.getLock(keyLock);
//加锁
redissonLock.lock();
try {
 ...
} catch (Exception e) {
  ...
} finally {
    //判断当前锁仍在锁定状态 && 是当前线程所持有。
    //如果当前判断不加可能会出现异常：attempt to unlock lock, not locked by current thread by node id: 0dsad...
    if (lock.isLocked() && lock.isHeldByCurrentThread()) {
        //解锁
        lock.unlock();
    }
}

某个客户端要加锁，如果该客户端面对的是一个redis cluster集群，首先会根据hash节点只选择一台机器，然后发送一段LOCK的lua脚本到redis上，lua脚本用来封装复杂的业务逻辑，并保证这段复杂业务逻辑执行的原子性。

String LOCK = "if(redis.call('exists', KEYS[1]) == 0) then " +
        "redis.call('hset', KEYS[1], ARGV[2], 1); " +
        "redis.call('pexpire', KEYS[1], ARGV[1]); " +
        "return nil; " +
        "end;" +
        "if(redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
        "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
        "redis.call('pexpire', KEYS[1], ARGV[1]); " +
        "return nil; " +
        "end;" +
        "return redis.call('pttl', KEYS[1]); ";

锁的数据结构：

     lockKey:{
          "8743c9c0-0795-4907-87fd-6c719a6b4586:1": 1
     }

(1)、加锁机制：客户端1加锁，因为没有，所以执行第一个if

参数释义：

KEYS[1]：要加锁的key

ARGV[1]：锁key的默认有效时间

ARGV[2]：加锁的客户端的ID，例：8743c9c0-0795-4907-87fd-6c719a6b4586:1

语句解析：

exists KEYS[1]：判断要加的锁是否存在

hset KEYS[1] ARGV[2] 1：执行加锁操作

pexpire KEYS[1] ARGV[1]：设置有效时间

(2)、锁互斥机制：客户端2加锁，因为存在客户端1之前加了锁，所以这个key的锁已存在，则执行第二个if，锁key的hash数据结构中，是否包含客户端2的ID，不包含返回锁key的剩余生存时间，此时客户端2会进入一个while循环，不停的尝试加锁。

(3)、可重入加锁机制：重复执行lock.lock()，同一客户端多次加锁

第一个if判断肯定不成立，“exists myLock”显示锁key已经存在。第二个if判断会成立，因为myLock的hash数据结构中包含的那个ID，就是客户端1的那个ID，也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”。此时就会执行可重入加锁的逻辑，会用：incrby lockKey

通过这个命令，对客户端1的加锁次数，累加1。此时myLock数据结构变为下面这样：

     lockKey:{
          "8743c9c0-0795-4907-87fd-6c719a6b4586:1": 2
     }

(4)、释放锁机制：如果执行lock.unlock()，就可以释放分布式锁，其实就是每次都对lockKey数据结构中的那个加锁次数减1。如果加锁次数是0了，说明这个客户端已经不再持有锁了，此时就会用："del lockKey"命令，从redis里删除这个key。然后，另外的客户端2就可以尝试完成加锁了。

6、Redis分布式锁的缺点：

如果你对某个redis master实例，写入了lockKey这种锁key的value，此时会异步复制给对应的master slave实例。但是这个过程中一旦发生redis master宕机，主备切换，redis slave变为了redis master。就会导致，客户端2来尝试加锁的时候，在新的redis master上完成了加锁，而客户端1也以为自己成功加了锁。此时就会导致多个客户端对一个分布式锁完成了加锁。这时系统在业务语义上一定会出现问题，导致各种脏数据的产生。所以这个就是redis cluster，或者是redis master-slave架构的主从异步复制导致的redis分布式锁的最大缺陷：在redis master实例宕机的时候，可能导致多个客户端同时完成加锁。

7、死锁的四个必须要条件及解决方案

(1)、必要条件

①、互斥条件：某种资源一次只允许一个进程访问，即该资源一旦分配给某个进程，其他进程就不能再访问，直到该进程访问结束。

②、占有且等待条件：一个进程本身占有资源（一种或多种），同时还有资源未得到满足，正在等待其他进程释放该资源。

③、不可剥夺条件：一个进程已经占有了某项资源，在末使用完之前，其他进程不能强行剥夺该资源。

④、循环等待条件：存在一个进程链，使得每个进程都占有下一个进程所需的至少一种资源。

L_D_Y_K

关注

1
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
四、Redis分布式锁

四、Redis分布式锁Java中的锁我们通常以synchronized 、Lock来使用它，但是只能保证在同一个JVM进程内中执行。如果在分布式集群环境下呢？分布式锁的实现有很多，比如基于数据库乐观锁、Redis、zookeeper、memcached、系统文件等。 1、命令行加锁：SET lock_key random_value NX PX 5000 执行成功，则证明客户端获取到了锁。 random_value：是客户端生成的唯一的字符串。 NX：...
复制链接

扫一扫