redis系列：分布式锁

一时失言乱红尘 2022-05-16 05:37 227阅读 0赞

[原文链接][Link 1]

*摘要：* 1 介绍 这篇博文讲介绍如何一步步构建一个基于Redis的分布式锁。会从最原始的版本开始，然后根据问题进行调整，最后完成一个较为合理的分布式锁。 本篇文章会将分布式锁的实现分为两部分，一个是单机环境，另一个是集群环境下的Redis锁实现。

# 1 介绍 #

这篇博文讲介绍如何一步步构建一个基于Redis的分布式锁。会从最原始的版本开始，然后根据问题进行调整，最后完成一个较为合理的分布式锁。

本篇文章会将分布式锁的实现分为两部分，一个是单机环境，另一个是集群环境下的Redis锁实现。在介绍分布式锁的实现之前，先来了解下分布式锁的一些信息。

# 2 分布式锁 #

## 2.1 什么是分布式锁？ ##

分布式锁是控制分布式系统或不同系统之间共同访问共享资源的一种锁实现，如果不同的系统或同一个系统的不同主机之间共享了某个资源时，往往需要互斥来防止彼此干扰来保证一致性。

## 2.2 分布式锁需要具备哪些条件 ##

1.  互斥性：在任意一个时刻，只有一个客户端持有锁。
2.  无死锁：即便持有锁的客户端崩溃或者其他意外事件，锁仍然可以被获取。
3.  容错：只要大部分Redis节点都活着，客户端就可以获取和释放锁

## 2.4 分布式锁的实现有哪些？ ##

1.  数据库
2.  Memcached（add命令）
3.  Redis（setnx命令）
4.  Zookeeper（临时节点）
5.  等等

# 3 单机Redis的分布式锁 #

## 3.1 准备工作 ##

### 3.1.1 定义常量类 ###

public class LockConstants {
        public static final String OK = "OK";
    
        /** NX|XX, NX -- Only set the key if it does not already exist. XX -- Only set the key if it already exist. **/
        public static final String NOT_EXIST = "NX";
        public static final String EXIST = "XX";
    
        /** expx EX|PX, expire time units: EX = seconds; PX = milliseconds **/
        public static final String SECONDS = "EX";
        public static final String MILLISECONDS = "PX";
    
        private LockConstants() {}
    }

### 3.1.2 定义锁的抽象类 ###

抽象类RedisLock实现java.util.concurrent包下的Lock接口，然后对一些方法提供默认实现，子类只需实现lock方法和unlock方法即可。代码如下

public abstract class RedisLock implements Lock {
    
        protected Jedis jedis;
        protected String lockKey;
    
        public RedisLock(Jedis jedis,String lockKey) {
            this(jedis, lockKey);
        }
    
    
        public void sleepBySencond(int sencond){
            try {
                Thread.sleep(sencond*1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    
    
        @Override
        public void lockInterruptibly(){}
    
        @Override
        public Condition newCondition() {
            return null;
        }
    
        @Override
        public boolean tryLock() {
            return false;
        }
    
        @Override
        public boolean tryLock(long time, TimeUnit unit){
            return false;
        }
    
    }

## 3.2 最基础的版本1 ##

先来一个最基础的版本，代码如下

public class LockCase1 extends RedisLock {
    
        public LockCase1(Jedis jedis, String name) {
            super(jedis, name);
        }
    
        @Override
        public void lock() {
            while(true){
                String result = jedis.set(lockKey, "value", NOT_EXIST);
                if(OK.equals(result)){
                    System.out.println(Thread.currentThread().getId()+"加锁成功!");
                    break;
                }
            }
        }
    
        @Override
        public void unlock() {
            jedis.del(lockKey);
        }
    }

LockCase1类提供了lock和unlock方法。  
其中lock方法也就是在reids客户端执行如下命令

SET lockKey value NX

而unlock方法就是调用DEL命令将键删除。  
好了，方法介绍完了。现在来想想这其中会有什么问题？  
假设有两个客户端A和B，A获取到分布式的锁。A执行了一会，突然A所在的服务器断电了（或者其他什么的），也就是客户端A挂了。这时出现一个问题，这个锁一直存在，且不会被释放，其他客户端永远获取不到锁。如下示意图

![1333208-20180814214858400-1031986913.png][]

可以通过设置过期时间来解决这个问题

## 3.3 版本2-设置锁的过期时间 ##

public void lock() {
        while(true){
            String result = jedis.set(lockKey, "value", NOT_EXIST,SECONDS,30);
            if(OK.equals(result)){
                System.out.println(Thread.currentThread().getId()+"加锁成功!");
                break;
            }
        }
    }

类似的Redis命令如下

SET lockKey value NX EX 30

> 注：要保证设置过期时间和设置锁具有原子性

这时又出现一个问题，问题出现的步骤如下

1.  客户端A获取锁成功，过期时间30秒。
2.  客户端A在某个操作上阻塞了50秒。
3.  30秒时间到了，锁自动释放了。
4.  客户端B获取到了对应同一个资源的锁。
5.  客户端A从阻塞中恢复过来，释放掉了客户端B持有的锁。

示意图如下

![1333208-20180814214909333-1017259889.png][]

这时会有两个问题

1.  过期时间如何保证大于业务执行时间?
2.  如何保证锁不会被误删除?

先来解决如何保证锁不会被误删除这个问题。  
这个问题可以通过设置value为当前客户端生成的一个随机字符串，且保证在足够长的一段时间内在所有客户端的所有获取锁的请求中都是唯一的。

版本2的完整代码：[Github地址][Github]

## 3.4 版本3-设置锁的value ##

抽象类RedisLock增加lockValue字段，lockValue字段的默认值为UUID随机值假设当前线程ID。

public abstract class RedisLock implements Lock {
    
        //...
        protected String lockValue;
    
        public RedisLock(Jedis jedis,String lockKey) {
            this(jedis, lockKey, UUID.randomUUID().toString()+Thread.currentThread().getId());
        }
    
        public RedisLock(Jedis jedis, String lockKey, String lockValue) {
            this.jedis = jedis;
            this.lockKey = lockKey;
            this.lockValue = lockValue;
        }
    
        //...
    }

加锁代码

public void lock() {
        while(true){
            String result = jedis.set(lockKey, lockValue, NOT_EXIST,SECONDS,30);
            if(OK.equals(result)){
                System.out.println(Thread.currentThread().getId()+"加锁成功!");
                break;
            }
        }
    }

解锁代码

public void unlock() {
        String lockValue = jedis.get(lockKey);
        if (lockValue.equals(lockValue)){
            jedis.del(lockKey);
        }
    }

这时看看加锁代码，好像没有什么问题啊。  
再来看看解锁的代码，这里的解锁操作包含三步操作：获取值、判断和删除锁。这时你有没有想到在多线程环境下的`i++`操作?

### 3.4.1 i++问题 ###

`i++`操作也可分为三个步骤：读i的值，进行i+1，设置i的值。  
如果两个线程同时对i进行i++操作，会出现如下情况

1.  i设置值为0
2.  线程A读到i的值为0
3.  线程B也读到i的值为0
4.  线程A执行了+1操作，将结果值1写入到内存
5.  线程B执行了+1操作，将结果值1写入到内存
6.  此时i进行了两次i++操作，但是结果却为1

在多线程环境下有什么方式可以避免这类情况发生?  
解决方式有很多种，例如用AtomicInteger、CAS、synchronized等等。  
这些解决方式的目的都是要确保`i++` 操作的原子性。那么回过头来看看解锁，同理我们也是要确保解锁的原子性。我们可以利用Redis的lua脚本来实现解锁操作的原子性。

版本3的完整代码：[Github地址][Github 1]

## 3.5 版本4-具有原子性的释放锁 ##

lua脚本内容如下

if redis.call("get",KEYS[1]) == ARGV[1] then
        return redis.call("del",KEYS[1])
    else
        return 0
    end

这段Lua脚本在执行的时候要把的lockValue作为ARGV\[1\]的值传进去，把lockKey作为KEYS\[1\]的值传进去。现在来看看解锁的java代码

public void unlock() {
        // 使用lua脚本进行原子删除操作
        String checkAndDelScript = "if redis.call('get', KEYS[1]) == ARGV[1] then " +
                                    "return redis.call('del', KEYS[1]) " +
                                    "else " +
                                    "return 0 " +
                                    "end";
        jedis.eval(checkAndDelScript, 1, lockKey, lockValue);
    }

好了，解锁操作也确保了原子性了，那么是不是单机Redis环境的分布式锁到此就完成了?  
别忘了[版本2-设置锁的过期时间][2-]还有一个，过期时间如何保证大于业务执行时间问题没有解决。

版本4的完整代码：[Github地址][Github 2]

## 3.6 版本5-确保过期时间大于业务执行时间 ##

抽象类RedisLock增加一个boolean类型的属性isOpenExpirationRenewal，用来标识是否开启定时刷新过期时间。  
在增加一个scheduleExpirationRenewal方法用于开启刷新过期时间的线程。

public abstract class RedisLock implements Lock {
        //...
    
        protected volatile boolean isOpenExpirationRenewal = true;
    
        /**
         * 开启定时刷新
         */
        protected void scheduleExpirationRenewal(){
            Thread renewalThread = new Thread(new ExpirationRenewal());
            renewalThread.start();
        }
    
        /**
         * 刷新key的过期时间
         */
        private class ExpirationRenewal implements Runnable{
            @Override
            public void run() {
                while (isOpenExpirationRenewal){
                    System.out.println("执行延迟失效时间中...");
    
                    String checkAndExpireScript = "if redis.call('get', KEYS[1]) == ARGV[1] then " +
                            "return redis.call('expire',KEYS[1],ARGV[2]) " +
                            "else " +
                            "return 0 end";
                    jedis.eval(checkAndExpireScript, 1, lockKey, lockValue, "30");
    
                    //休眠10秒
                    sleepBySencond(10);
                }
            }
        }
    }

加锁代码在获取锁成功后将isOpenExpirationRenewal置为true，并且调用scheduleExpirationRenewal方法，开启刷新过期时间的线程。

public void lock() {
        while (true) {
            String result = jedis.set(lockKey, lockValue, NOT_EXIST, SECONDS, 30);
            if (OK.equals(result)) {
                System.out.println("线程id:"+Thread.currentThread().getId() + "加锁成功!时间:"+LocalTime.now());
    
                //开启定时刷新过期时间
                isOpenExpirationRenewal = true;
                scheduleExpirationRenewal();
                break;
            }
            System.out.println("线程id:"+Thread.currentThread().getId() + "获取锁失败，休眠10秒!时间:"+LocalTime.now());
            //休眠10秒
            sleepBySencond(10);
        }
    }

解锁代码增加一行代码，将isOpenExpirationRenewal属性置为false，停止刷新过期时间的线程轮询。

public void unlock() {
        //...
        isOpenExpirationRenewal = false;
    }

版本5的完整代码：[Github地址][Github 3]

## 3.7 测试 ##

测试代码如下

public void testLockCase5() {
        //定义线程池
        ThreadPoolExecutor pool = new ThreadPoolExecutor(0, 10,
                                                        1, TimeUnit.SECONDS,
                                                        new SynchronousQueue<>());
    
        //添加10个线程获取锁
        for (int i = 0; i < 10; i++) {
            pool.submit(() -> {
                try {
                    Jedis jedis = new Jedis("localhost");
                    LockCase5 lock = new LockCase5(jedis, lockName);
                    lock.lock();
    
                    //模拟业务执行15秒
                    lock.sleepBySencond(15);
    
                    lock.unlock();
                } catch (Exception e){
                    e.printStackTrace();
                }
            });
        }
    
        //当线程池中的线程数为0时，退出
        while (pool.getPoolSize() != 0) {}
    }

测试结果

![1333208-20180814214930759-1232071596.gif][]

或许到这里基于单机Redis环境的分布式就介绍完了。但是使用java的同学有没有发现一个锁的重要特性

![1333208-20180814214942101-986589401.png][]

那就是锁的重入，那么分布式锁的重入该如何实现呢？这里就留一个坑了

# 4 集群Redis的分布式锁 #

在Redis的分布式环境中，Redis 的作者提供了RedLock 的算法来实现一个分布式锁。

## 4.1 加锁 ##

RedLock算法加锁步骤如下

1.  获取当前Unix时间，以毫秒为单位。
2.  依次尝试从N个实例，使用相同的key和随机值获取锁。在步骤2，当向Redis设置锁时,客户端应该设置一个网络连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为10秒，则超时时间应该在5-50毫秒之间。这样可以避免服务器端Redis已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试另外一个Redis实例。
3.  客户端使用当前时间减去开始获取锁时间（步骤1记录的时间）就得到获取锁使用的时间。当且仅当从大多数（这里是3个节点）的Redis节点都取到锁，并且使用的时间小于锁失效时间时，锁才算获取成功。
4.  如果取到了锁，key的真正有效时间等于有效时间减去获取锁所使用的时间（步骤3计算的结果）。
5.  如果因为某些原因，获取锁失败（*没有*在至少N/2+1个Redis实例取到锁或者取锁时间已经超过了有效时间），客户端应该在所有的Redis实例上进行解锁（即便某些Redis实例根本就没有加锁成功）。

## 4.2 解锁 ##

向所有的Redis实例发送释放锁命令即可，不用关心之前有没有从Redis实例成功获取到锁.

--------------------

关于RedLock算法，还有一个小插曲，就是Martin Kleppmann 和 RedLock 作者 antirez的对RedLock算法的互怼。 官网原话如下

> Martin Kleppmann [analyzed Redlock here][]. I disagree with the analysis and posted [my reply to his analysis here][].

更多关于RedLock算法这里就不在说明，有兴趣的可以到官网阅读相关文章。

# 5 总结 #

这篇文章讲述了一个基于Redis的分布式锁的编写过程及解决问题的思路，但是本篇文章实现的分布式锁并不适合用于生产环境。java环境有 [Redisson][] 可用于生产环境，但是分布式锁还是Zookeeper会比较好一些（可以看Martin Kleppmann 和 RedLock的分析）。

> Martin Kleppmann对RedLock的分析：[http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html][analyzed Redlock here]
> 
> RedLock 作者 antirez的回应：[http://antirez.com/news/101][my reply to his analysis here]

整个项目的地址存放在Github上，有需要的可以看看：[Github地址][Github 4]

[Link 1]: http://click.aliyun.com/m/1000012894/
[1333208-20180814214858400-1031986913.png]: /images/20220516/e96bbedf2c3d4ad4bad8f4577b14dc98.png
[1333208-20180814214909333-1017259889.png]: /images/20220516/e965b8c795b74841bebe902604fa4879.png
[Github]: https://github.com/rainbowda/learnWay/blob/master/learnRedis/distributed-locks/src/main/java/com/learnRedis/lock/case2/LockCase2.java
[Github 1]: https://github.com/rainbowda/learnWay/blob/master/learnRedis/distributed-locks/src/main/java/com/learnRedis/lock/case3/LockCase3.java
[2-]: https://yq.aliyun.com/articles/625308?utm_content=m_1000012894#
[Github 2]: https://github.com/rainbowda/learnWay/blob/master/learnRedis/distributed-locks/src/main/java/com/learnRedis/lock/case4/LockCase4.java
[Github 3]: https://github.com/rainbowda/learnWay/blob/master/learnRedis/distributed-locks/src/main/java/com/learnRedis/lock/case5/LockCase5.java
[1333208-20180814214930759-1232071596.gif]: /images/20220516/3864788997364a4eb7e9fa2e64168877.png
[1333208-20180814214942101-986589401.png]: /images/20220516/d5a80f42f62d42d492663ab396205b60.png
[analyzed Redlock here]: http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
[my reply to his analysis here]: http://antirez.com/news/101
[Redisson]: https://github.com/mrniko/redisson
[Github 4]: https://github.com/rainbowda/learnWay/tree/master/learnRedis/distributed-locks