Redis实现分布式锁

Redis实现分布式锁的7种方案

日常开发中，秒杀下单、抢红包等等业务场景，都需要用到分布式锁。而Redis非常适合作为分布式锁使用。本文将分七个方案展开，跟大家探讨Redis分布式锁的正确使用方式。如果有不正确的地方，欢迎大家指出哈，一起学习一起进步。

• 什么是分布式锁
• 方案一：SETNX + EXPIRE
• 方案二：SETNX + value值是（系统时间+过期时间）
• 方案三：使用Lua脚本(包含SETNX + EXPIRE两条指令)
• 方案四：SET的扩展命令（SET EX PX NX）
• 方案五：SET EX PX NX + 校验唯一随机值,再释放锁
• 方案六: 开源框架~Redisson
• 方案七：多机实现的分布式锁Redlock

什么是分布式锁

❝

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

❞

我们先来看下，一把靠谱的分布式锁应该有哪些特征：

• 「互斥性」: 任意时刻，只有一个客户端能持有锁。
• 「锁超时释放」：持有锁超时，可以释放，防止不必要的资源浪费，也可以防止死锁。
• 「可重入性」:一个线程如果获取了锁之后,可以再次对其请求加锁。
• 「高性能和高可用」：加锁和解锁需要开销尽可能低，同时也要保证高可用，避免分布式锁失效。
• 「安全性」：锁只能被持有的客户端删除，不能被其他客户端删除

Redis分布式锁方案一：SETNX + EXPIRE

提到Redis的分布式锁，很多小伙伴马上就会想到setnx+ expire命令。即先用setnx来抢锁，如果抢到之后，再用expire给锁设置一个过期时间，防止锁忘记了释放。

❝

SETNX 是SET IF NOT EXISTS的简写.日常命令格式是SETNX key value，如果 key不存在，则SETNX成功返回1，如果这个key已经存在了，则返回0。

❞

假设某电商网站的某商品做秒杀活动，key可以设置为key_resource_id,value设置任意值，伪代码如下：

if（jedis.setnx(key_resource_id,lock_value) == 1）{ //加锁
    expire（key_resource_id，100）; //设置过期时间
    try {
        do something  //业务请求
    }catch(){
  }
  finally {
       jedis.del(key_resource_id); //释放锁
    }
}

但是这个方案中，setnx和expire两个命令分开了，「不是原子操作」。如果执行完setnx加锁，正要执行expire设置过期时间时，进程crash或者要重启维护了，那么这个锁就“长生不老”了，「别的线程永远获取不到锁啦」。

Redis分布式锁方案二：SETNX + value值是(系统时间+过期时间)

为了解决方案一，「发生异常锁得不到释放的场景」，有小伙伴认为，可以把过期时间放到setnx的value值里面。如果加锁失败，再拿出value值校验一下即可。加锁代码如下：

long expires = System.currentTimeMillis() + expireTime; //系统时间+设置的过期时间
String expiresStr = String.valueOf(expires);

// 如果当前锁不存在，返回加锁成功
if (jedis.setnx(key_resource_id, expiresStr) == 1) {
        return true;
} 
// 如果锁已经存在，获取锁的过期时间
String currentValueStr = jedis.get(key_resource_id);

// 如果获取到的过期时间，小于系统当前时间，表示已经过期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {

     // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间（不了解redis的getSet命令的小伙伴，可以去官网看下哈）
    String oldValueStr = jedis.getSet(key_resource_id, expiresStr);

    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
         // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才可以加锁
         return true;
    }
}

//其他情况，均返回加锁失败
return false;
}

这个方案的优点是，巧妙移除expire单独设置过期时间的操作，把「过期时间放到setnx的value值」里面来。解决了方案一发生异常，锁得不到释放的问题。但是这个方案还有别的缺点：

❝

• 过期时间是客户端自己生成的（System.currentTimeMillis()是当前系统的时间），必须要求分布式环境下，每个客户端的时间必须同步。
• 如果锁过期的时候，并发多个客户端同时请求过来，都执行jedis.getSet()，最终只能有一个客户端加锁成功，但是该客户端锁的过期时间，可能被别的客户端覆盖
• 该锁没有保存持有者的唯一标识，可能被别的客户端释放/解锁。

❞

Redis分布式锁方案三：使用Lua脚本(包含SETNX + EXPIRE两条指令)

实际上，我们还可以使用Lua脚本来保证原子性（包含setnx和expire两条指令），lua脚本如下：

if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then
   redis.call('expire',KEYS[1],ARGV[2])
else
   return 0
end;

加锁代码如下：

 String lua_scripts = "if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then" +
            " redis.call('expire',KEYS[1],ARGV[2]) return 1 else return 0 end";   
Object result = jedis.eval(lua_scripts, Collections.singletonList(key_resource_id), Collections.singletonList(values));
//判断是否成功
return result.equals(1L);

这个方案，跟方案二对比，你觉得哪个更好呢？

Redis分布式锁方案方案四：SET的扩展命令（SET EX PX NX）

除了使用，使用Lua脚本，保证SETNX + EXPIRE两条指令的原子性，我们还可以巧用Redis的SET指令扩展参数！（SET key value[EX seconds][PX milliseconds][NX|XX]），它也是原子性的！

❝

SET key value[EX seconds][PX milliseconds][NX|XX]

• NX :表示key不存在的时候，才能set成功，也即保证只有第一个客户端请求才能获得锁，而其他客户端请求只能等其释放锁，才能获取。
• EX seconds :设定key的过期时间，时间单位是秒。
• PX milliseconds: 设定key的过期时间，单位为毫秒
• XX: 仅当key存在时设置值

❞

伪代码demo如下：

if（jedis.set(key_resource_id, lock_value, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
  }
  finally {
       jedis.del(key_resource_id); //释放锁
    }
}

但是呢，这个方案还是可能存在问题：

• 问题一：「锁过期释放了，业务还没执行完」。假设线程a获取锁成功，一直在执行临界区的代码。但是100s过去后，它还没执行完。但是，这时候锁已经过期了，此时线程b又请求过来。显然线程b就可以获得锁成功，也开始执行临界区的代码。那么问题就来了，临界区的业务代码都不是严格串行执行的啦。
• 问题二：「锁被别的线程误删」。假设线程a执行完后，去释放锁。但是它不知道当前的锁可能是线程b持有的（线程a去释放锁时，有可能过期时间已经到了，此时线程b进来占有了锁）。那线程a就把线程b的锁释放掉了，但是线程b临界区业务代码可能都还没执行完呢。

方案五：SET EX PX NX + 校验唯一随机值,再删除

既然锁可能被别的线程误删，那我们给value值设置一个标记当前线程唯一的随机数，在删除的时候，校验一下，不就OK了嘛。伪代码如下：

if（jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
  }
  finally {
       //判断是不是当前线程加的锁,是才释放
       if (uni_request_id.equals(jedis.get(key_resource_id))) {
        jedis.del(lockKey); //释放锁
        }
    }
}

在这里，「判断是不是当前线程加的锁」和「释放锁」不是一个原子操作。如果调用jedis.del()释放锁的时候，可能这把锁已经不属于当前客户端，会解除他人加的锁。

为了更严谨，一般也是用lua脚本代替。lua脚本如下：

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

Redis分布式锁方案六：Redisson框架

方案五还是可能存在「锁过期释放，业务没执行完」的问题。有些小伙伴认为，稍微把锁过期时间设置长一些就可以啦。其实我们设想一下，是否可以给获得锁的线程，开启一个定时守护线程，每隔一段时间检查锁是否还存在，存在则对锁的过期时间延长，防止锁过期提前释放。

当前开源框架Redisson解决了这个问题。我们一起来看下Redisson底层原理图吧：

只要线程一加锁成功，就会启动一个watch dog看门狗，它是一个后台线程，会每隔10秒检查一下，如果线程1还持有锁，那么就会不断的延长锁key的生存时间。因此，Redisson就是使用Redisson解决了「锁过期释放，业务没执行完」问题。

Redis分布式锁方案七：多机实现的分布式锁Redlock+Redisson

前面六种方案都只是基于单机版的讨论，还不是很完美。其实Redis一般都是集群部署的：

如果线程一在Redis的master节点上拿到了锁，但是加锁的key还没同步到slave节点。恰好这时，master节点发生故障，一个slave节点就会升级为master节点。线程二就可以获取同个key的锁啦，但线程一也已经拿到锁了，锁的安全性就没了。

为了解决这个问题，Redis作者 antirez提出一种高级的分布式锁算法：Redlock。Redlock核心思想是这样的：

❝

搞多个Redis master部署，以保证它们不会同时宕掉。并且这些master节点是完全相互独立的，相互之间不存在数据同步。同时，需要确保在这多个master实例上，是与在Redis单实例，使用相同方法来获取和释放锁。

❞

我们假设当前有5个Redis master节点，在5台服务器上面运行这些Redis实例。

RedLock的实现步骤:如下

❝

• 1.获取当前时间，以毫秒为单位。
• 2.按顺序向5个master节点请求加锁。客户端设置网络连接和响应超时时间，并且超时时间要小于锁的失效时间。（假设锁自动失效时间为10秒，则超时时间一般在5-50毫秒之间,我们就假设超时时间是50ms吧）。如果超时，跳过该master节点，尽快去尝试下一个master节点。
• 3.客户端使用当前时间减去开始获取锁时间（即步骤1记录的时间），得到获取锁使用的时间。当且仅当超过一半（N/2+1，这里是5/2+1=3个节点）的Redis master节点都获得锁，并且使用的时间小于锁失效时间时，锁才算获取成功。（如上图，10s> 30ms+40ms+50ms+4m0s+50ms）
• 如果取到了锁，key的真正有效时间就变啦，需要减去获取锁所使用的时间。
• 如果获取锁失败（没有在至少N/2+1个master实例取到锁，有或者获取锁时间已经超过了有效时间），客户端要在所有的master节点上解锁（即便有些master节点根本就没有加锁成功，也需要解锁，以防止有些漏网之鱼）。

❞

简化下步骤就是：

• 按顺序向5个master节点请求加锁
• 根据设置的超时时间来判断，是不是要跳过该master节点。
• 如果大于等于3个节点加锁成功，并且使用的时间小于锁的有效期，即可认定加锁成功啦。
• 如果获取锁失败，解锁！

Redisson实现了redLock版本的锁，有兴趣的小伙伴，可以去了解一下哈~

参考与感谢

• redis系列：分布式锁[1]
• 浅析 Redis 分布式锁解决方案[2]
• 细说Redis分布式锁?[3]
• Redlock：Redis分布式锁最牛逼的实现

Reference

[1]

redis系列：分布式锁:https://juejin.cn/post/6844903656911798285

[2]

浅析 Redis 分布式锁解决方案:https://www.infoq.cn/article/dvaaj71f4fbqsxmgvdce

[3]

细说Redis分布式锁?:https://juejin.cn/post/6844904082860146695#heading-3

一、概述

在这个技术不断更新迭代的情况下，分布式这个概念，在企业中的权重越来越高！谈及分布式，不可避免一定会提到分布式锁，现阶段分布式锁的实现方式主流的有三种实现方式Zookeeper、DB、Redis,我们本篇文章以Redis为例！

从我们的角度来看，这三个属性是有效使用分布式锁所需的最低保证。

安全特性：互斥。在任何给定时刻，只有一个客户端可以持有锁。
活力属性：无死锁。最终，即使锁定资源的客户端崩溃或分区，也始终可以获得锁。
活动性：容错能力。只要大多数Redis节点都处于运行状态，客户端就可以获取和释放锁。

二、redis多节点实现分布式锁带来的挑战

我们使用Redis锁定资源的最简单方法是：

在实例中创建锁。
锁通常使用Redis过期功能在有限时间存在，因此最终将被释放，最终超过给定期限会被删除。
当客户端需要释放资源时，它将删除锁。

乍一看，似乎并没有什么问题。但是不妨我们深究一下，这种实现方案在redis单机环境下似乎并没有什么问题！但是如果节点坏了呢？好吧，那么让我们添加一个slave节点！如果主服务器宕机了，就使用这个节点！但是我们不妨来看看她真的能保证可用吗？

在谈论这个的致命缺陷时，我们需要了解一个知识点，Redis复制是异步的。

1. 客户端A获取主服务器中的锁。
2. 在将锁复制传输到从机之前，主机崩溃。
3. slave晋升为master。
4. 客户端B获取锁，因为从机并没有该锁的对象，获取成功！

显然，这样是不对的，主节点因为没来得及同步数据就宕机了，所以从节点没有该数据，从而造成分布式锁的失效，那么作者antirez的观点是如何解决这个呢？

三、Redlock算法

作者认为，我们应该使用多个Redis,这些节点是完全独立的，不需要使用复制或者任何协调数据的系统，多个redis系统获取锁的过程就变成了如下步骤：

1. 以毫秒为单位获取当前的服务器时间
2. 尝试使用相同的key和随机值来获取锁，对每一个机器获取锁时都应该有一个超时时间，比如锁的过期时间为10s那么获取单个节点锁的超时时间就应该为5到50毫秒左右，他这样做的目的是为了保证客户端与故障的机器连接，耗费多余的时间！超时间时间内未获取数据就放弃该节点，从而去下一个节点获取，直至将所有节点全部获取一遍！
3. 获取完成后，获取当前时间减去步骤一获取的时间，当且仅当客户端半数以上获取成功且获取锁的时间小于锁额超时时间，则证明该锁生效！
4. 获取锁之后，锁的超时时间等于设置的有效时间-获取锁花费的时间
5. 如果 获取锁的机器不满足半数以上，或者锁的超时时间计算完毕后为负数 等异常操作，则系统会尝试解锁所有实例，即使有些实例没有获取锁成功，依旧会被尝试解锁！
6. 释放锁，只需在所有实例中释放锁，无论客户端是否认为它能够成功锁定给定的实例。

四、但是Redlock真能够解决问题吗？

Martin Kleppmann发表文章任务，Redlock并不能保证该锁的安全性！

他认为锁的用途无非两种

提升效率，用锁来保证一个任务没有必要被执行两次。比如（很昂贵的计算） 保证正确，使用锁来保证任务按照正常的步骤执行，防止两个节点同时操作一份数据，造成文件冲突，数据丢失。

对于第一种原因，我们对锁是有一定宽容度的，就算发生了两个节点同时工作，对系统的影响也仅仅是多付出了一些计算的成本，没什么额外的影响。这个时候 使用单点的 Redis 就能很好的解决问题，没有必要使用RedLock，维护那么多的Redis实例，提升系统的维护成本。

五.分布式锁的超时性，所带来的缺点

但是对于第二种场景来说，就比较慎重了，因为很可能涉及到一些金钱交易，如果锁定失败，并且两个节点同时处理同一数据，则结果将导致文件损坏，数据丢失，永久性不一致，或者金钱方面的损失！

我们假设一种场景，我们有两个客户端，每一个客户端必须拿到锁之后才能去保存数据到数据库，我们使用RedLock算法实现会出现什么问题呢？RedLock中，为了防止死锁，锁是具有过期时间的，但是Martin认为这是不安全的！该流程图类似于这样！

客户端1获取到锁成功后，开始执行，执行到一半系统发生Full GC ,系统服务被挂起，过段时间锁超时了。

客户端2等待客户端1的锁超时后，成功的获取到锁，开始执行入库操作，完成后，客户端1完成了Full GC,又做了一次入库操作！这是不安全的！如何解决呢？

Martin提出来一种类似乐观锁的实现机制，示例图如下：

客户端1长时间被挂起后，客户端2获取到锁，开始写库操作，同时携带令牌 34,写库完成后，客户端1苏醒，开始进行入库操作，但是因为携带的令牌为33 小于最新令牌，该次提交就被拒绝！

这个想法听起来似乎是很完备的思路，这样即使系统因为某些原因被挂起，数据也能够被正确的处理。但是仔细想一下：

• 如果仅当您的令牌大于所有过去的令牌时，数据存储区才能始终接受写入，则它是可线性化的存储区，相当于使用数据库来实现一个 分布式锁系统，那么RedLock的作用就变得微乎其微！甚至不再需要使用redis保证分布式锁！

六.RedLock对于系统时钟强依赖

回想一下Redlock算法获取锁的几个步骤，你会发现锁的有效性是与当前的系统时钟相依赖，我们假设：

我们有，A B C D E 五个redis节点：

1. 客户端1获取节点A，B，C的锁定。由于网络问题，无法访问D和E。
2. 节点C上的时钟向前跳，导致锁过期。
3. 客户端2获取节点C，D，E的锁定。由于网络问题，无法访问A和B。
4. 现在，客户1和2都认为他们持有该锁。

如果C在将锁持久保存到磁盘之前崩溃并立即重新启动，则可能会发生类似的问题。

Martin认为系统时间的阶跃主要来自两个方面（以及作者给出的解决方案）：

1. 人为修改。 对于人为修改，能说啥呢？人要搞破坏没办法避免。
2. 从NTP服务收到了一个跳跃时时钟更新。 NTP受到一个阶跃时钟更新，对于这个问题，需要通过运维来保证。需要将阶跃的时间更新到服务器的时候，应当采取小步快跑的方式。多次修改，每次更新时间尽量小。

七.基于程序语言弥补分布式锁的超时性所带来的缺点

我们回顾 1 观点，深究抽象出现这个缺陷的根本原因，就是为了解决由于系统宕机带来的锁失效而给锁强加了一个失效时间，异常情况下，程序（业务）执行的时间大于锁失效时间从而造成的一系列的问题，我们能否从这方面去考虑，从而用程序来解决这个样一个死局 呢？

既然是因为锁的失效时间小于业务时间，那么我们想办法保证业务程序执行时间绝对小于锁超时时间不久解决了？

java语言中redisson实现了一种保证锁失效时间绝对大于业务程序执行时间的机制。官方叫做看门狗机制（Watchdog），他的主要原理是，在程序成功获取锁之后，会fork一条子线程去不断的给该锁续期，直至该锁释放为止！他的原理图大概如下所示：

redisson使用守护线程来进行锁的续期，（守护线程的作用：当主线程销毁，会和主线程一起销毁。）防止程序宕机后，线程依旧不断续命，造成死锁！

另外，Redisson还实现并且优化了 RedLock算法、公平锁、可重入锁、连锁等操作，使Redis分布式锁的实现方式更加简便高效！

FULL-GC 期间

full gc发生时，守护线程依然无法运行。redis分布式锁对于这种集群模式的加锁无解。