Redis分布式锁

时间  2020-02-04
标签 redis 分布式 栏目 Redis 繁體版
原文   原文链接

1.概述

分布式锁通常有三种实现方式：1.基于数据库实现分布式锁；2. 基于缓存（Redis，memcached，tair）实现分布式锁； 3.基于Zookeeper实现分布式锁。本片博客将介绍基于缓存实现分布式锁，这里主讲分别针对Redis 2.6.12 以前版本和Redis 2.6.12 及以后版本分布式锁的实现。html

2.基于Redis（Redis 2.6.12版本以前）分布式锁的实现方式

（1）命令介绍

　　1）SETX

　　SETNX key value: setnx是『set if not exists』（即当key不存在时，则set）的简写。setnx具备原子性，当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不作，返回0.java

　　2)GETSET

　　GETSET key value：将给定 key 的值设为 value ，并返回 key 的旧值(old value)。当 key 存在但不是字符串类型时，返回一个错误。当 key 没有旧值时，也便是， key 不存在时，返回 nil 。redis

 

　　3)GET

　　GET key：返回 key 所关联的字符串值；若是 key 不存在那么返回特殊值 nil 。假如 key 储存的值不是字符串类型，返回一个错误，由于GET只能用于处理字符串值。sql

　　4)EXPIRE

　　EXPIRE key timeout：为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。数据库

 

　　5)DELETE

　　DELETE key:删除key缓存

（2）Redis实现分布式锁的原理

 

* 1.经过setnx(lock_timeout)实现，若是设置了锁返回1， 已经有值没有设置成功返回0服务器


* 2.死锁问题：经过实践来判断是否过时，若是已通过期，获取到过时时间get(lockKey)，而后getset(lock_timeout)判断是否和get相同，多线程


* 相同则证实已经加锁成功，由于可能致使多线程同时执行getset(lock_timeout)方法，这可能致使多线程都只需getset后，对于判断加锁成功的线程，并发


* 再加expire(lockKey, LOCK_TIMEOUT, TimeUnit.MILLISECONDS)过时时间，防止多个线程同时叠加时间，致使锁时效时间翻倍dom


* 3.针对集群服务器时间不一致问题，能够调用redis的time()获取当前时间

 

（3）图解Redis分布式锁原理

 

1. setnx(lockkey, 当前时间+过时超时时间) ，若是返回1，则获取锁成功；若是返回0则没有获取到锁，转向2。 
2. get(lockkey)获取锁的过时时间lockValueA ，并将这个lockValueA 值与当前的系统时间currentTime进行比较，若是小于当前系统时间，则认为这个锁已经超时，能够容许别的请求从新获取，转向3。 
3. 计算新的过时时间 newExpireTime=当前时间+过时超时时间，而后getset(lockkey, newExpireTime) 会返回当前lockkey的值lockValueB。 
4. 判断lockValueA与lockValueB 是否相等，若是相等，说明当前getset设置成功，获取到了锁。若是不相等，说明这个锁又被别的请求获取走了，那么当前请求能够直接返回失败，或者继续重试。 
5. 在获取到锁以后，当前线程能够开始本身的业务处理，当处理完毕后，比较本身的处理时间和对于锁设置的超时时间，若是小于锁设置的超时时间，则直接执行delete释放锁；若是大于锁设置的超时时间，则不须要再锁进行处理。

（4）缺点

Redis 2.6.12以前版本，使用SETNX命令实现Redis分布式锁，可是会出现各类各样的问题。具体罗列出如下几种：

1）setnx和expire的非原子性

设想一个极端场景，当某线程执行setnx，成功获得了锁：

 

 

setnx刚执行成功，还将来得及执行expire指令，节点1 Duang的一声挂掉了。 

 

 

这样一来，这把锁就没有设置过时时间，变得“长生不老”，别的线程再也没法得到锁了。如示例代码所示

示例代码

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()方法做用就是SET IF NOT EXIST，expire()方法就是给锁加一个过时时间。乍一看好像和前面的set()方法结果同样，然而因为这是两条Redis命令，不具备原子性，若是程序在执行完setnx()以后忽然崩溃，致使锁没有设置过时时间。那么将会发生死锁。网上之因此有人这样实现，是由于低版本的jedis并不支持多参数的set()方法。

2）出现并发的可能性

这里使用示例代码来描述

示例代码

这一种错误示例就比较难以发现问题，并且实现也比较复杂。实现思路：使用jedis.setnx()命令实现加锁，其中key是锁，value是锁的过时时间。执行过程：1. 经过setnx()方法尝试加锁，若是当前锁不存在，返回加锁成功。2. 若是锁已经存在则获取锁的过时时间，和当前时间比较，若是锁已通过期，则设置新的过时时间，返回加锁成功。代码以下：

 

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. 锁不具有拥有者标识，即任何客户端均可以解锁。

 

3）del 致使误删

又是一个极端场景，假如某线程成功获得了锁，而且设置的超时时间是30秒。

 

 

若是某些缘由致使线程A执行的很慢很慢，过了30秒都没执行完，这时候锁过时自动释放，线程B获得了锁。

 

 

随后，线程A执行完了任务，线程A接着执行del指令来释放锁。但这时候线程B还没执行完，线程A实际上删除的是线程B加的锁。 

 

怎么避免这种状况呢？能够在del释放锁以前作一个判断，验证当前的锁是否是本身加的锁。

至于具体的实现，能够在加锁的时候把当前的线程ID当作value，并在删除以前验证key对应的value是否是本身线程的ID。

加锁：

String threadId = Thread.currentThread().getId()
set（key，threadId ，30，NX）

 

解锁：

if（threadId .equals(redisClient.get(key))）{
    del(key)
}

 也能够在释放锁的时候，经过锁的默认value值UUID判断是否是该锁，如果该锁，则执行delete进行锁释放。可是，这样作又隐含了一个新的问题，判断和释放锁是两个独立操做，不是原子性的。具体如代码所示：

示例代码1

最多见的解锁代码就是直接使用jedis.del()方法删除锁，这种不先判断锁的拥有者而直接解锁的方式，会致使任何客户端均可以随时进行解锁，即便这把锁不是它的。

 

public static void wrongReleaseLock1(Jedis jedis, String lockKey) {
    jedis.del(lockKey);
}

 

 示例代码2

这种解锁代码乍一看也是没问题，甚至我以前也差点这样实现，与正确姿式差很少，惟一区别的是分红两条命令去执行，代码以下：

 

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

 

 如代码注释，问题在于若是调用jedis.del()方法的时候，这把锁已经不属于当前客户端的时候会解除他人加的锁。那么是否真的有这种场景？答案是确定的，好比客户端A加锁，一段时间以后客户端A解锁，在执行jedis.del()以前，锁忽然过时了，此时客户端B尝试加锁成功，而后客户端A再执行del()方法，则将客户端B的锁给解除了。

 

从Redis 2.6.12版本开始很好的解决了上述的问题，下面是采用Redis2.6.12版本对以上问题的解决

 

3.基于Redis（Redis 2.6.12版本起）分布式锁的实现方式

（1）命令介绍

从Redis2.6.12版本开始，redis为SET命令增长了一系列选项：

  • EX second ：设置键的过时时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。
  • PX millisecond ：设置键的过时时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value。
  • NX ：只在键不存在时，才对键进行设置操做。 SET key value NX 效果等同于 SETNX key value 。
  • XX ：只在键已经存在时，才对键进行设置操做。

注意: 因为SET命令加上选项已经能够彻底取代SETNX, SETEX, PSETEX的功能，因此在未来的版本中，redis可能会不推荐使用而且最终抛弃这几个命令。使用SET代替SETNX，至关于SETNX+EXPIRE实现了原子性，没必要担忧SETNX成功，EXPIRE失败的问题！有效的避免死锁，解决了Redis2.6.12以前版本存在的问题。

（2）分布式锁的实现

1）解决非原子性和并发的出现

示例代码

public class RedisTool {
 
    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";
 
    /**
     * 尝试获取分布式锁
     * @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()方法一共有五个形参：

  • 第一个为key，咱们使用key来当锁，由于key是惟一的。
  • 第二个为value，咱们传的是requestId，不少童鞋可能不明白，有key做为锁不就够了吗，为何还要用到value？缘由就是咱们在上面讲到可靠性时，分布式锁要知足第四个条件解铃还须系铃人，经过给value赋值为requestId，咱们就知道这把锁是哪一个请求加的了，在解锁的时候就能够有依据。requestId可使用UUID.randomUUID().toString()方法生成。
  • 第三个为nxxx，这个参数咱们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，咱们进行set操做；若key已经存在，则不作任何操做；
  • 第四个为expx，这个参数咱们传的是PX，意思是咱们要给这个key加一个过时的设置，具体时间由第五个参数决定。
  • 第五个为time，与第四个参数相呼应，表明key的过时时间。

总的来讲，执行上面的set()方法就只会致使两种结果：1. 当前没有锁（key不存在），那么就进行加锁操做，并对锁设置个有效期，同时value表示加锁的客户端。2. 已有锁存在，不作任何操做。

心细的童鞋就会发现了，咱们的加锁代码知足咱们可靠性里描述的三个条件。首先，set()加入了NX参数，能够保证若是已有key存在，则函数不会调用成功，也就是只有一个客户端能持有锁，知足互斥性。其次，因为咱们对锁设置了过时时间，即便锁的持有者后续发生崩溃而没有解锁，锁也会由于到了过时时间而自动解锁（即key被删除），不会发生死锁。最后，由于咱们将value赋值为requestId，表明加锁的客户端请求标识，那么在客户端在解锁的时候就能够进行校验是不是同一个客户端。因为咱们只考虑Redis单机部署的场景，因此容错性咱们暂不考虑。

2）解决锁误删

示例代码

 

public class RedisTool {
 
    private static final Long RELEASE_SUCCESS = 1L;
 
    /**
     * 释放分布式锁
     * @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服务端执行。

那么这段Lua代码的功能是什么呢？其实很简单，首先获取锁对应的value值，检查是否与requestId相等，若是相等则删除锁（解锁）。那么为何要使用Lua语言来实现呢？由于要确保上述操做是原子性的。那么为何执行eval()方法能够确保原子性，源于Redis的特性，简单来讲，就是在eval命令执行Lua代码的时候，Lua代码将被当成一个命令去执行，而且直到eval命令执行完成，Redis才会执行其余命令。

 

4.总结

本文主要介绍了Redis分布式锁的实现原理，以及如何使用java代码正确实现Redis分布式锁，对于加锁和解锁也分别针对Redis两个版本给出了示例。

5.参考资料

https://blog.csdn.net/qq_33666373/article/details/78870294

https://www.cnblogs.com/SophieLSR/p/9001789.html

https://blog.csdn.net/hxpjava1/article/details/81068355

http://www.importnew.com/27477.html

https://blog.csdn.net/qq_21033663/article/details/79967158

https://blog.csdn.net/andy86869/article/details/81668355

https://blog.csdn.net/kongmin_123/article/details/82080962

http://www.redis.cn/commands/set.html

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程