Redis分布式锁：保障微服务架构下的并发控制与数据一致性实战指南

目录

    

一、分布式锁简介   

二、Redis 实现的分布式锁

        2.1 单机 Redis 加锁流程

三、多 Redis 实例实现高可靠的分布式锁

        3.1 Redlock

        3.2 Redission​​​​​​​    

---

一、分布式锁简介   

        分布式锁是一种在分布式系统中实现锁机制的技术，用于控制多节点对共享资源的访问，确保在并发环境下能够正确地实现互斥访问。在传统的单机环境下，我们可以使用线程锁来解决并发控制问题，但在分布式环境下，由于多个节点间物理分离，无法直接使用线程锁，因此需要设计一套能够在分布式系统中工作的锁服务。

        分布式锁需要一个单独的分布式系统来实现，可以实现分布式锁的主要方式有：Redis、Zookeeper、基于数据库实现等。本文主要介绍基于 Redis 实现的分布式锁。

        分布式锁应该具有以下特性：

• 互斥性：确保同一时刻只有一个客户端持有锁
• 避免死锁：锁在客户端异常或网络中断后能自动释放
• 容错性：在部分节点失效的情况下，锁依然可以正常工作
• 可重入性：支持一个客户端再持有锁的情况下能再次获取锁
• 公平性：按申请顺序依次分配锁资源

二、Redis 实现的分布式锁

        对于在单机上运行的多线程程序来说，锁本身其实就是一个变量，比如用变量 0 表示没有现成获取锁，此时可以获取锁；变量值为 1 时，表示已经有线程持有了锁。

        和单机上多线程加锁的方式类似，Redis 分布式锁同样可以用一个变量来实现。但是，和线程在单机上操作锁不同的是，在分布式场景下，锁变量需要由一个共享存储系统来维护，只有这样，多个客户端才可以通过访问共享存储系统来访问锁变量。相应的，加锁和释放锁的操作就变成了读取、判断和设置共享存储系统中的锁变量值。

        这样一来，实现分布式的要求如下：

• 要求一：分布式锁的加锁和释放锁过程涉及多个步骤。读取、判断、设置这三个步骤要保证原子操作，不能被打断。
• 要求二：Redis 中保存了锁变量，如果 Redis 挂了，那么客户端无法操作分布式锁，这时要保证其可靠性。

        2.1 单机 Redis 加锁流程

        作为分布式锁实现过程中的共享存储系统，Redis 可以使用键值对来保存锁变量，再接收和处理不同客户端发送的加锁和释放锁的操作请求。

        客户端 A 和 C 同时请求加锁。因为 Redis 使用单线程处理请求，所以，即使客户端 A 和 C 同时把加锁请求发给了 Redis，Redis 也会串行处理它们的请求。假设 Redis 先处理客户端 A 的请求，读取 lock_key 的值，发现 lock_key 为 0，所以，Redis 就把 lock_key 的 value 置为 1，表示已经加锁了。紧接着，Redis 处理客户端 C 的请求，此时，Redis 会发现 lock_key 的值已经为 1 了，所以就返回加锁失败的信息。

        加锁的流程包含三个步骤，分别是：读取、判断、设置。Redis 中要想保证操作的原子性，有两种通用的方法，分别是使用 Redis 的单命令操作和使用 Lua 脚本。那么，在分布式加锁场景下，该怎么应用这两个方法呢？

        先来看下，Redis 可以用哪些单命令操作实现加锁操作。

        首先是 SETNX 命令，它用于设置键值对的值。具体来说，就是这个命令在执行时会判断键值对是否存在，如果不存在，就设置键值对的值，如果存在，就不做任何设置。

SETNX key value

        对于释放锁操作来说，我们可以在执行完业务逻辑后，使用 DEL 命令删除锁变量。不过，你不用担心锁变量被删除后，其他客户端无法请求加锁了。因为 SETNX 命令在执行时，如果要设置的键值对（也就是锁变量）不存在，SETNX 命令会先创建键值对，然后设置它的值。所以，释放锁之后，再有客户端请求加锁时，SETNX 命令会创建保存锁变量的键值对，并设置锁变量的值，完成加锁。

        不过，使用 SETNX 和 DEL 命令组合实现分布锁，存在两个潜在的风险。

1. 假如某个客户端在执行了 SETNX 命令、加锁之后，紧接着却在操作共享数据时发生了异常，结果一直没有执行最后的 DEL 命令释放锁。因此，锁就一直被这个客户端持有，其它客户端无法拿到锁，也无法访问共享数据和执行后续操作，这会给业务应用带来影响。针对这个问题，一个有效的解决方法是，给锁变量设置一个过期时间。这里留一道思考题：锁设定的时间多少才算合适呢？
2. 如果客户端 A 执行了 SETNX 命令加锁后，假设客户端 B 执行了 DEL 命令释放锁，此时，客户端 A 的锁就被误释放了。如果客户端 C 正好也在申请加锁，就可以成功获得锁，进而开始操作共享数据。这样一来，客户端 A 和 C 同时在对共享数据进行操作，数据就会被修改错误，这也是业务层不能接受的。针对这个问题，我们可以再设置 value 值时，设置上客户端的唯一标识，释放锁时，只能释放自己加的锁。

        为了能达到和 SETNX 命令一样的效果，Redis 给 SET 命令提供了类似的选项 NX，用来实现“不存在即设置”。如果使用了 NX 选项，SET 命令只有在键值对不存在时，才会进行设置，否则不做赋值操作。此外，SET 命令在执行时还可以带上 EX 或 PX 选项，用来设置键值对的过期时间。

        举个例子，执行下面的命令时，只有 key 不存在时，SET 才会创建 key，并对 key 进行赋值。另外，key 的存活时间由 seconds 或者 milliseconds 选项值来决定。

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

        有了 SET 命令的 NX 和 EX/PX 选项后，我们就可以用下面的命令来实现加锁操作了。

// 加锁, unique_value作为客户端唯一性的标识
SET lock_key unique_value NX PX 10000

        其中，unique_value 是客户端的唯一标识，可以用一个随机生成的字符串来表示，PX 10000 则表示 lock_key 会在 10s 后过期，以免客户端在这期间发生异常而无法释放锁。

        因为在加锁操作中，每个客户端都使用了一个唯一标识，所以在释放锁操作时，我们需要判断锁变量的值，是否等于执行释放锁操作的客户端的唯一标识，如下所示：

//释放锁 比较unique_value是否相等，避免误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

        在释放锁操作中，我们使用了 Lua 脚本，这是因为，释放锁操作的逻辑也包含了读取锁变量、判断值、删除锁变量的多个操作，而 Redis 在执行 Lua 脚本时，可以以原子性的方式执行，从而保证了锁释放操作的原子性。

三、多 Redis 实例实现高可靠的分布式锁

        当要实现高可靠的分布式锁时，就不能只依赖单个的命令操作了，需要按照一定的步骤和规则进行加解锁操作，否则，就可能会出现锁无法工作的情况。“一定的步骤和规则”是指啥呢？其实就是分布式锁的算法。

        为了避免 Redis 实例故障而导致的锁无法工作的问题，Redis 的开发者 Antirez 提出了分布式锁算法 Redlock。

        3.1 Redlock

        首先要明确，Redlock 并不是一个直接的具体软件库，而是一种理论上的分布式锁涉及策略。

        Redlock 算法的基本思路，是让客户端和多个独立的 Redis 实例依次请求加锁，如果客户端能够和半数以上的实例成功地完成加锁操作，那么就认为，客户端成功地获得分布式锁了，否则加锁失败。这样一来，即使有单个 Redis 实例发生故障，因为锁变量在其它实例上也有保存，所以，客户端仍然可以正常地进行锁操作，锁变量并不会丢失。

        我们来具体看下 Redlock 算法的执行步骤。Redlock 算法的实现需要有 N 个独立的 Redis 实例。接下来，我们可以分成 3 步来完成加锁操作。

1. 客户端获取当前时间。
2. 客户端按顺序依次向N个 Redis 实例执行加锁操作。这里的加锁操作和在单实例上执行的加锁操作一样，使用set命令，带上NX、EX/PX选项，以及带上客户端的唯一标识。如果客户端在和一个 Redis 实例请求加锁时，一直到超时都没有成功，那么此时，客户端会和下一个 Redis 实例继续请求加锁。加锁操作的超时时间需要远远地小于锁的有效时间，一般也就是设置为几十毫秒。
3. 一旦客户端完成了和所有 Redis 实例的加锁操作，客户端就要计算整个加锁过程总耗时。

        客户端只有在满足下面两个条件时，才能认为加锁成功：

• 客户端从超过半数的 Redis 实例上成功获取到锁；
• 客户端获取锁的总耗时没有超过锁的有效时间。

        在满足了这两个条件后，我们需要重新计算这把锁的有效时间，计算的结果是锁的最初有效时间减去客户端为获取锁的总耗时。如果锁的有效时间已经来不及完成共享数据的操作了，我们可以释放锁，以免出现还没完成数据操作，锁就过期了的情况。  

        当然，如果客户端在和所有实例执行完加锁操作后，没能同时满足这两个条件，那么，客户端向所有 Redis 节点发起释放锁的操作。   

        这种方案需要多个 Redis 集群，成本比较高。

        3.2 Redission

        Redission 是一个在 Java 中广泛使用的 Redis 客户端库，它是 Redlock 的具体实现。它不仅提供了一系列的分布式的java常用对象，还实现了可重入锁（Reentrant Lock）、公平锁（Fair Lock）、联锁（MultiLock）、红锁（RedLock）、读写锁（ReadWriteLock）等，还提供了许多分布式服务。

        Redisson支持单点模式、主从模式、哨兵模式、集群模式，这里以单点模式为例看下具体实现：

// 1.构造redisson实现分布式锁必要的Config
Config config = new Config();
config.useSingleServer().setAddress("redis://127.0.0.1:6379").setPassword("123456").setDatabase(0);
// 2.构造RedissonClient
RedissonClient redissonClient = Redisson.create(config);
// 3.获取锁对象实例（无法保证是按线程的顺序获取到）
RLock rLock = redissonClient.getLock(lockKey);
try {
    /**
     * 4.尝试获取锁
     * waitTimeout 尝试获取锁的最大等待时间，超过这个值，则认为获取锁失败
     * leaseTime   锁的持有时间,超过这个时间锁会自动失效（值应设置为大于业务处理的时间，确保在锁有效期内业务能处理完）
     */
    boolean res = rLock.tryLock((long)waitTimeout, (long)leaseTime, TimeUnit.SECONDS);
    // 设置锁的过期时间时可以设置自动续期，通过以下方式设置
    // boolean res = lock.lock(10, TimeUnit.SECONDS, 5, TimeUnit.SECONDS); // 第一个参数是锁的初始过期时间，第三个参数是自动续期间隔
    if (res) {
        //成功获得锁，在这里处理业务
    }
} catch (Exception e) {
    throw new RuntimeException("aquire lock fail");
}finally{
    //无论如何, 最后都要解锁
    rLock.unlock();
}

        在使用分布式锁时，锁设置多长时间，要经过严格的评估，如果业务流程还没执行完，锁就过期了，那肯定会影响正常的业务，一般情况下，设置的过期时间都要略长于代码执行的时间，不过 Redission 为我们提供了一种更友好的方式，在执行代码的过程中你可以对锁进行自动续期，以延长锁的持有时间。

        总之，在使用分布式锁的过程中要注意锁超时、死锁、误删等问题。使用分布式锁时要规避各种问题才能提高可靠性。

往期经典推荐

探析Drools规则引擎的工作机制-CSDN博客

Redis使用规范的最佳实践：打造高性能与稳定性的关键法则-CSDN博客

Spring循环依赖的成因与破局-CSDN博客

决胜微服务架构：OpenFeign轻量级REST客户端的魅力解析_openfeign rest-CSDN博客

Redis高性能的秘密原来在这，超越想象-CSDN博客