参考：

• 29 无锁的原子操作：Redis 如何应对并发访问？| 极客时间 (opens new window)
• 30 如何使用 Redis 实现分布式锁？| 极客时间 (opens new window)

并发访问控制：是指对多个客户端访问操作同一份数据的过程进行控制，以保证任何一个客户端发送的操作在Redis实例上执行时具有互斥性。例如，客户端A的访问操作在执行时，客户端B的操作不能执行，需要等到A的操作结束后，才能执行。

业务系统不可避免会遇到并发访问的问题，为保证并发访问的正确性，Redis 提供了两种方法：加锁和原子操作。

1. 无锁的原子操作

原子操作是一种提供并发访问控制的方法，是指执行过程保持原子性的操作，而且原子操作执行时并不需要再加锁，实现了无锁操作。这样一来，既能保证并发控制，还能减少对系统并发性能的影响。

1.1 并发访问中需要对什么进行控制？

并发访问控制对应的操作主要是数据修改操作。当客户端需要修改数据时，基本流程分成两步：

1. 客户端先把数据读取到本地，在本地进行修改；
2. 客户端修改完数据后，再写回 Redis。

这个流程被称为 Read-Modify-Write（RMW）操作。当有多个客户端对同一份数据执行RMW操作的话，我们就需要让RMW操作涉及的代码以原子性方式执行。访问同一份数据的RMW操作代码，就叫做临界区代码。

不过，当有多个客户端并发执行临界区代码时，就会存在一些潜在问题，接下来，我用一个多客户端更新商品库存的例子来解释一下。

我们先看下临界区代码。假设客户端要对商品库存执行扣减1的操作，伪代码如下所示：

current = GET(id)
current--
SET(id, current)

如果我们对临界区代码的执行没有控制机制，就可能出现数据更新错误。如下图是两个客户端同时执行临界区代码而导致的错误：

上图相比于正确的处理逻辑，库存值明显更新错了。出现这个现象的原因是：多个客户端的 RMW 操作在执行时不具有互斥性，两个客户端基于相同的初始值进行修改，而不是基于前一个客户端修改后的值再修改。

为了保证数据并发修改的正确性，我们可以使用锁来控制临界区代码的执行情况，如下所示：

LOCK()
current = GET(id)
current--
SET(id, current)
UNLOCK()

虽然加锁保证了互斥性，但是加锁会降低并发性能。

和加锁类似，原子操作也能实现并发控制，但是原子操作对系统并发性能的影响较小，接下来，我们就来了解下 Redis 中的原子操作。

1.2 Redis 的两种原子操作方法

为了实现并发控制要求的临界区代码互斥执行，Redis的原子操作采用了两种方法：

1. 把多个操作在 Redis 中实现成一个操作，也就是单命令操作；
2. 把多个操作写到一个 Lua 脚本中，以原子性方式执行单个 Lua 脚本。

1.2.1 Redis 本身的单命令操作

Redis 是使用单线程来串行处理客户端的请求操作命令的，所以，当 Redis 执行某个命令操作时，其他命令是无法执行的，这相当于命令操作是互斥执行的。当然，Redis 的快照生成、AOF 重写这些操作，可以使用后台线程或者是子进程执行，也就是和主线程的操作并行执行。不过，这些操作只是读取数据，不会修改数据，所以，我们并不需要对它们做并发控制。

另外，Redis 还提供了 INCR/DECR 命令对数据进行增值/减值操作。，这个命令将 RMW 三个操作变为一个原子操作了。

比如说，在刚才的库存扣减例子中，客户端可以使用下面的代码，直接完成对商品id的库存值减1操作。即使有多个客户端执行下面的代码，也不用担心出现库存值扣减错误的问题：

DECR id

但当我们想要将更复杂的操作变成原子操作时，就需要使用 Lua 脚本了。

1.2.2 Lua 脚本

Redis 会把整个 Lua 脚本作为一个整体使用 EVAL 命令来执行，在执行的过程中不会被其他命令打断，从而保证了 Lua 脚本中操作的原子性。

下面举个例子来解释 Lua 的使用。当一个业务应用的访问用户增加时，我们有时需要限制某个客户端在一定时间范围内的访问次数，比如爆款商品的购买限流、社交网络中的每分钟点赞次数限制等。

那该怎么限制呢？我们可以把客户端IP作为key，把客户端的访问次数作为value，保存到Redis中。客户端每访问一次后，我们就用INCR增加访问次数。不过，在这种场景下，客户端限流其实同时包含了对访问次数和时间范围的限制，例如每分钟的访问次数不能超过20。所以，我们可以在客户端第一次访问时，给对应键值对设置过期时间，例如设置为60s后过期。同时，在客户端每次访问时，我们读取客户端当前的访问次数，如果次数超过阈值，就报错，限制客户端再次访问。你可以看下下面的这段代码，它实现了对客户端每分钟访问次数不超过20次的限制。伪代码如下：

//获取ip对应的访问次数
current = GET(ip)
//如果超过访问次数超过20次，则报错
IF current != NULL AND current > 20 THEN
    ERROR "exceed 20 accesses per second"
ELSE
    //如果访问次数不足20次，增加一次访问计数
    value = INCR(ip)
    //如果是第一次访问，将键值对的过期时间设置为60s后
    IF value == 1 THEN
        EXPIRE(ip,60)
    END
    //执行其他操作
    DO THINGS
END

尽管例子使用了 INCR 来原子性地增加计数，但客户端限流的逻辑不只有计数，还包括访问次数判断和过期时间设置。对于这些操作，我们同样需要保证它们的原子性。否则，如果客户端使用多线程访问，访问次数初始值为0，第一个线程执行了INCR(ip)操作后，第二个线程紧接着也执行了INCR(ip)，此时，ip对应的访问次数就被增加到了2，我们就无法再对这个ip设置过期时间了。这样就会导致，这个ip对应的客户端访问次数达到20次之后，就无法再进行访问了。即使过了60s，也不能再继续访问，显然不符合业务要求。

由于这种复杂的逻辑无法使用单个命令来解决，此时就需要使用 Lua 脚本来保证并发控制。我们可以把访问次数加1、判断访问次数是否为1，以及设置过期时间这三个操作写入一个Lua脚本，如下所示：

local current
current = redis.call("incr",KEYS[1])
if tonumber(current) == 1 then
    redis.call("expire",KEYS[1],60)
end

假设我们编写的脚本名称为 lua.script，我们接着就可以使用 Redis 客户端，带上 eval 选项，来执行该脚本。脚本所需的参数将通过以下命令中的 keys 和 args 进行传递：

redis-cli  --eval lua.script  keys , args

这样一来，访问次数加1、判断访问次数是否为1，以及设置过期时间这三个操作就可以原子性地执行了。即使客户端有多个线程同时执行这个脚本，Redis也会依次串行执行脚本代码，避免了并发操作带来的数据错误。

注意，如果把很多操作都放在Lua脚本中原子执行，会导致Redis执行脚本的时间增加，同样也会降低Redis的并发性能。所以建议：在编写Lua脚本时，你要避免把不需要做并发控制的操作写入脚本中。

2. 如何使用 Redis 实现分布式锁？

前面提到，加锁也能实现临界区代码的互斥执行，但 Redis 属于分布式系统，当有多个客户端需要争抢锁的时候，这把锁就不能是某个客户端本地的锁，而是每个客户端都能访问到的锁。

在分布式系统中，当有多个客户端需要获取锁的时候，我们就需要一个分布式锁，它保存在一个共享存储系统中，可以被多个客户端共享访问和获取。

而 Redis 本身就是一个共享存储系统，可以用来保存分布式锁，而且可以应对高并发的锁操作场景。这一节将讨论如何基于 Redis 实现分布式锁。

2.1 单机上的锁和分布式锁的联系与区别

---

先看一下单机上的锁的实现。对于在单机上运行的多线程程序来说，锁本身可以用一个变量表示：

• 变量为 0：表示没有线程获取锁
• 变量为 1：表示已经有线程获取到锁了

而线程的加锁/释放锁就是检查这个变量并修改的操作。用一段代码来展示加锁和释放锁的操作：

acquire_lock() {
  if lock == 0
     lock = 1
     return 1
  else
     return 0
}

release_lock() {
  lock = 0
  return 1
}

而在分布式场景下，分布式锁的变量由一个共享存储系统来维护，这样多个客户端就可以访问分布式锁了，由此，加锁和释放锁的操作就变成了读取、判断和设置共享存储系统中的锁变量值。

这样，我们就可以得出实现分布式锁的两个要求：

• 要求一：分布式锁的加锁和释放锁的过程，涉及多个操作。所以，在实现分布式锁时，我们需要保证这些锁操作的原子性；
• 要求二：共享存储系统保存了锁变量，如果共享存储系统发生故障或宕机，那么客户端也就无法进行锁操作了。在实现分布式锁时，我们需要考虑保证共享存储系统的可靠性，进而保证锁的可靠性。

下面看一下如何实现分布式锁。我们既可以基于单个Redis节点来实现，也可以使用多个Redis节点实现。在这两种情况下，锁的可靠性是不一样的。

2.2 基于单个 Redis 节点实现分布式锁

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

我们要赋予锁变量一个变量名，把这个变量名作为键值对的键，而锁变量的值，则是键值对的值，这样一来，Redis 就能保存锁变量了，客户端也就可以通过Redis的命令操作来实现锁操作。

加锁过程：

释放锁：

因为加锁包含了三个操作（读取锁变量、判断锁变量值以及把锁变量值设置为 1），为了保证这三个操作的原子性，在 Redis 中可以使用单指令操作或使用 Lua 脚本。

我们看下 Redis 可以用哪些单命令操作实现加锁操作。

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

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

总结来说，我们就可以用 SETNX 和 DEL 命令组合来实现加锁和释放锁操作。下面的伪代码示例显示了锁操作的过程：

// 加锁
SETNX lock_key 1
// 业务逻辑
DO THINGS
// 释放锁
DEL lock_key

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

• 风险一：假如某个客户端在执行了SETNX命令、加锁之后，紧接着却在操作共享数据时发生了异常，结果一直没有执行最后的DEL命令释放锁。因此，锁就一直被这个客户端持有，其它客户端无法拿到锁，也无法访问共享数据和执行后续操作，这会给业务应用带来影响。
  • 解决方法：给锁变量设置一个过期时间
• 风险二：如果客户端A执行了SETNX命令加锁后，假设客户端B执行了DEL命令释放锁，此时，客户端A的锁就被误释放了。如果客户端C正好也在申请加锁，就可以成功获得锁，进而开始操作共享数据。这样一来，客户端A和C同时在对共享数据进行操作，数据就会被修改错误，这也是业务层不能接受的。
  • 解决方法：SETNX 加锁时将 value 设置为某客户端的 ID 值，并在释放时判断该 ID 是否与自己的相等。

知道了解决方法，下面看一下在 Redis 具体如何实现。

为了能达到和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脚本（unlock.script）实现的释放锁操作的伪代码，其中，KEYS[1]表示lock_key，ARGV[1]是当前客户端的唯一标识，这两个值都是我们在执行Lua脚本时作为参数传入的。

最后，我们执行下面的命令，就可以完成锁释放操作了：

redis-cli  --eval  unlock.script lock_key , unique_value

通过 Lua 脚本保证了 Redis 在进行读取锁变量、判断值、删除锁变量的多个操作能够原子性地执行。

到此，我们实现了使用 Redis 实例来实现分布式锁。但是为了避免单点故障，我们还要基于多个 Redis 节点来实现分布式锁。

2.3 基于多个 Redis 节点实现高可靠的分布式锁

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

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

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

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

第一步：客户端获取当前时间。

第二步：客户端按顺序依次向 N 个 Redis 实例执行加锁操作。

这里的加锁操作和在单实例上执行的加锁操作一样，使用SET命令，带上NX，EX/PX选项，以及带上客户端的唯一标识。当然，如果某个Redis实例发生故障了，为了保证在这种情况下，Redlock算法能够继续运行，我们需要给加锁操作设置一个超时时间。

如果客户端在和一个Redis实例请求加锁时，一直到超时都没有成功，那么此时，客户端会和下一个Redis实例继续请求加锁。加锁操作的超时时间需要远远地小于锁的有效时间，一般也就是设置为几十毫秒。

第三步：一旦客户端完成了和所有 Redis 实例的加锁操作，客户端就要计算整个加锁过程的总耗时。

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

• 条件一：客户端从超过半数（大于等于 N/2+1）的 Redis 实例上成功获取到了锁；
• 条件二：客户端获取锁的总耗时没有超过锁的有效时间。

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

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

在Redlock算法中，释放锁的操作和在单实例上释放锁的操作一样，只要执行释放锁的Lua脚本就可以了。这样一来，只要N个Redis实例中的半数以上实例能正常工作，就能保证分布式锁的正常工作了。

所以，在实际的业务应用中，如果你想要提升分布式锁的可靠性，就可以通过 Redlock 算法来实现。

2.4 小结

分布式锁是由共享存储系统维护的变量，多个客户端可以向共享存储系统发送命令进行加锁或释放锁操作。Redis 作为一个共享存储系统，可以用来实现分布式锁。

在基于单个Redis实例实现分布式锁时，对于加锁操作，我们需要满足三个条件。

1. 加锁包括了读取锁变量、检查锁变量值和设置锁变量值三个操作，但需要以原子操作的方式完成，所以，我们使用SET命令带上NX选项来实现加锁；
2. 锁变量需要设置过期时间，以免客户端拿到锁后发生异常，导致锁一直无法释放，所以，我们在SET命令执行时加上EX/PX选项，设置其过期时间；
3. 锁变量的值需要能区分来自不同客户端的加锁操作，以免在释放锁时，出现误释放操作，所以，我们使用SET命令设置锁变量值时，每个客户端设置的值是一个唯一值，用于标识客户端。

和加锁类似，释放锁也包含了读取锁变量值、判断锁变量值和删除锁变量三个操作，不过，我们无法使用单个命令来实现，所以，我们可以采用Lua脚本执行释放锁操作，通过Redis原子性地执行Lua脚本，来保证释放锁操作的原子性。

不过，基于单个 Redis 实例实现分布式锁时，会面临实例异常或崩溃的情况，这会导致实例无法提供锁操作，正因为此，Redis 也提供了 Redlock 算法，用来实现基于多个实例的分布式锁。这样一来，锁变量由多个实例维护，即使有实例发生了故障，锁变量仍然是存在的，客户端还是可以完成锁操作。Redlock 算法是实现高可靠分布式锁的一种有效解决方案，你可以在实际应用中把它用起来。