基于redis集群的分布式锁redlock

Redis 作者为了解决因为主备切换、脑裂导致 Redis 单集群分布式锁不安全的问题,提出了 redlock 算法,下面是针对 文章 的翻译和一些自我理解。

一、安全性和可用性保证


用三个属性来建模我们的设计方案,在我看来,这是有效使用分布式锁的最小保证:

  1. 安全性:互斥性。在任意时刻,只有一个客户端可以持有锁;
  2. 可用性1:无死锁。即时获取锁的客户端崩溃或者发生网络分区,最终也是可以获取锁资源的;
  3. 可用性2:容错性。只要大多数 redis 节点在运行,客户端就能获取和释放锁。

二、基于故障转移的实现还不够


为了理解我们想要提升什么,先来分析一下大多数基于 redis 的分布式锁库的现状。

使用 redis 锁住资源最简单的方式是创建一个 key,key 创建通常带有 TTL 时间,因为它最终会被释放(我们列表中可用性1)。当客户端需要主动释放资源时,删除这个 key 即可。

表面上工作很好,但是有个问题:这是我们架构中的一个单点故障。redis master 崩溃会发生什么?ok,加一个副本,master 不可用时使用它。这是不可行的,这不能实现互斥锁的安全性,因为 redis 的复制是异步的。

这个模型存在的竞争条件:

  • 客户端 A 获取 master 的这个锁;
  • master 在把这个 key 发送给副本前崩溃了;
  • 副本被提升为了 master;
  • 客户端 B 获取了 A 已经锁住的 相同资源的锁。违反了安全性。

有的时候会执行的很好,在特殊的场景下,例如在故障转移期间,多个客户端可以同时锁住相同的资源。在这个 case 中,你可以使用基于复制的方案(如果对业务影响不大),否则我们建议使用本文档中的方案。

三、单个实例的正确实现


在克服上面描述的单个实例的问题之前,让我们检查下在这个简单的例子中 如何正确的运行,对于一些应用来说,有时的竞态条件是可以接受,那这就是可行的方案。因为在单个实例中加锁,是我们描述分布式算法的基础。

为了获取锁,方法如下:

SET resource_name my_random_value NX PX 30000

如果 key 不存在的话(NX 选项),这个命令将设置 key,有 30000 毫秒的过期时间(PX 选项)。key 的值设置为 “my_random_value”,值必须是所有客户端和所有请求中唯一的。

这个随机值是为了以安全的方式来释放 key,通过脚本来告诉 redis:仅当 key 存在并且 key 的存储值是我们希望的。是通过下面的 lua 脚本来实现:

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

最重要的是避免移除了其他客户端创建的 key。例如,一个客户端获取了锁,然后执行一些阻塞操作,比锁的有效期长很久(在这时间内,key 会过期),然后客户端删除锁,此时锁已经被其他客户端获取了。仅仅使用 DEL 命令是不安全的,因为一个客户端可能会删除其他客户端的锁。在上面的脚本中,每个锁都有随机字符串进行”签名“,因此只有客户端移除它自己设置的锁时,才会移除该锁。

随机字符串应该是什么样子?我们假定是 20 字节来自于 /dev/urandom,你也可以找到更简单的方法来使它独一无二(适合你的任务)。例如,安全的选择是使用 /dev/urandom 作为 RC4 的种子,并生成一个伪随机流。一个更简单的方案是,使用 UNIX 的毫秒时间戳,并使用客户端id 连接时间戳。虽然没有那么安全,但对于大多数环境足够了。

“lock validity time” 是我们设置 key 的 TTL 时间。这也是自动释放的时间,也是客户端在另一个客户端获取锁之前的 执行操作时间,窗口时间从获取锁的那一个时刻开始计算。

现在我们有了一个很好的方法来获取和释放锁。有了这个系统,可以推理出由单个、总是可用的实例组成的非分布式的系统是安全的。下面扩展这个概念到分布式系统中,那里没有这样的保证。

四、Redlock 算法


在算法的分布式版本中,我们假定有 N 个 redis master 节点,这些节点是完全独立的,因此我们不需要任何副本和隐式的协作系统。在示例中,我们设置 N = 5,这是一个合理的值,我们需要运行 5个 redis master 在不同的物理机或者虚拟机上,确保他们之间是独立的。

为了获取锁,客户端执行下面的操作:

  1. 获取当前的毫秒时间戳;
  2. 按照顺序,尝试在 N 个实例上获取锁,使用相同的 key 和 随机值 在所有的实例中。在步骤2中,在每个实例中设置锁时,客户端请求的超时时间 相比 key 的自动过期时间,应该要小很多;
    • 例如,key 的自动过期时间是 10s,请求超时时间可以是 5~50 ms。避免客户端和挂掉的 redis 节点通信花费过长的时间,如果一个实例不可用了,应该尽快和下一个实例通信。
  3. 客户端计算获取锁使用了多长时间,需要使用当前时间 减去 第一步获取的时间。只有客户端获取了大多数实例(至少3个)的锁,并且获取锁花费的时间小于 key 的过期时间,才认为成功获取到锁了;
  4. 如果获取到锁了,锁的有效时间是初始有效时间 减去 第三步计算的消耗时间;
  5. 如果客户端因为某些原因,获取锁失败了(比如没有获取到 N/2+1 个实例的锁,或者锁的有效时间是负数),客户端要尝试解锁 所有的实例(包括客户端认为没有上锁成功的实例)。
1、算法是异步的吗

算法有一个依赖:所有的进程中没有时钟同步,每个进程以大致相同的速率更新本地时间,即使有误差,相比 key 的自动明过期时间也是很小的误差。这个依赖设定和现实中的计算机非常像:每个电脑都有本地时钟,我们可以依赖不同的计算机,虽然有很小的时钟漂移。

这上面这一点上,我们需要更好的指定我们的互斥规则:必须保证,客户端在 key 的有效时间(上面第三步计算的),减去一些时间(不同进程之间时钟漂移时间,只有几ms),在这个时间段内完成客户端自己的工作。

本文包含了关于 时钟漂移 的更多信息:https://dl.acm.org/doi/10.1145/74851.74870。

2、失败重试

当客户端没有获取锁时,应该在一个随机延迟后重试,避免多个客户端对同一资源,在同一时刻获取锁(这可能导致脑裂,最终没有客户端成功获取锁,因为每个客户端都锁住了部分节点,没有一个客户端锁住大多数节点)。客户端获取到大多数节点锁的频率越快,集群脑裂的时间窗口就越短。理想情况下,客户端应该在同一时间,使用多路复用技术,同时给 N 个实例发送 set 命令(避免客户端只锁住部分节点)。

需要强调一下,客户端没有在大多数节点上获取锁成功时,需要尽快的释放已经获取的锁,以便不用等这个锁自动过期后 才能继续获取锁(如果网络分区发生,客户端无法和 redis 实例通信,在 key 自动过期前,需要损失系统的可用性)。

3、释放锁

释放锁比较简单,无论客户端是否成功在实例上加锁,都可以执行释放锁的逻辑(在分布式系统中,即使获取锁失败,因为网络问题 可能实例已经加锁成功)。

4、安全论证

这个算法是安全的吗?让我们来检查下不同场景会发生什么。

假定客户端已经在大多数实例上获取到了锁。所有实例中包含的这个 key 有相同的过期时间,然后这个 key 是在不同的时间设置的,因此这个 key 将会在不同的时间过期(多个实例,客户端不可能同时 set key)。在最坏的情况下,在 T1 时间(我们和第一个实例通信之前)设置第一个 key,最后一个 key 在 T2 时间设置(我们从最后一个服务器获取响应的时间)。我们可以确保第一个 key 在过期前,至少存在 MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT 的时间。所有其他 key 都会在这之后过期,我们可以确保在这个时间点前,这些 key 是同时存在于实例中的。

CLOCK_DRIFT 时钟漂移

为什么系统时钟会存在漂移呢?linux提供了两个系统时间:clock realtime和clock monotonic。

  • clock realtime 是可以被用户改变的,或者被NTP改变,gettimeofday 取的就是这个时间,redis的过期计算用的也是这个时间;

  • clock monotonic 是单调时间,不会被用户改变,但是会被NTP改变。

最理想的情况时,所有系统的时钟都和 NTP 服务器保持同步,但这显然是不可能的。导致系统时钟漂移的原因:系统的时钟和 NTP 服务器不同步。

redis 的过期时间是依赖系统时钟的,如果时钟漂移过大时会影响到过期时间的计算。上面 MIN_VALIDITY 的计算还减去了 CLOCK_DRIFT 时间,我的理解是,如果第一个 key 的实例发生了时钟漂移,会导致 key 提前过期,因此 MIN_VALIDITY 时间需要减去这个值。

在大多数 key 存在的时间内,其他客户端是无法获取到锁的,因为 N/2+1 个 key 已经存在了,所以 N/2+1 个 SET NX 操作不会成功。因此一旦获取到了锁,在同一时间不可能再次获取锁。

我们还需要保证多个客户端同时获取锁时不会成功。

如果客户端获取大部分实例锁的时间,接近或者大于 key 的自动过期时间(我们 SET 使用的 TTL 时间),需要考虑这个锁是无效的,并且在所有实例上解锁。所以,我们只需要考虑获取大多数实例锁的时间,远小于锁的有效时间的情况。在这种情况下,上面已经讨论过,在 MIN_VALIDITY 时间内,没有客户端能再次获取锁。所以多个客户端同时锁住 N/2+1 个示例,只有在 获取锁的时间大于 TTL 的情况下出现,这种情况下锁也是无效的。

4、可用性论证

系统可用性基于下面三个特性:

  • 自动释放锁(key 过期后):最终 key 可以再次加锁;
  • 事实上,客户端没有获取到锁时,或者获取到锁并且工作完成时,客户端会协作移除这些 key,这使得我们不用等 key 自动过期,就可以再次获取锁;
  • 事实上,当客户端重试获取锁时,它会等待一段时间,比获取大多数实例锁的时间 会长一些,为了避免在资源竞争期间产生脑裂问题。

然而,在网络分区发生的时候,我们需要付出 TTL 的不可用时间,如果网络分区持续发生,系统会一直不可用。如果客户端获取了锁,但还没有移除锁时发生了网络分区,这种情况就会出现。

基本上,如果系统持续的发生网络分区,系统也会持续的不可用。

5、性能、崩溃恢复和 fsync

需要用户使用 redis 作为分布式锁服务,是为了在获取锁、释放锁都是低延迟,以及每秒高性能的执行获取锁、释放锁。为了满足这个要求,可以通过多路复用和 N 个 redis 服务通信,达到低延迟的目的(socket 设置为非阻塞,发送所有的命令,然后读取所有的命令结果,假定客户端和每个实例之间的 RTT 是近似的)。

为了实现崩溃恢复的系统模型,我们需要考虑持久化的问题。

看下这个问题,假定所有的 redis 没有开启持久化。一个客户端获取了 5 个实例中的 3 个实例的锁,其中一个实例在客户端获取锁后重启,此刻,又有 3 个实例可以锁住相同的资源,其他客户端可以再次锁住资源,违反了互斥锁的安全性。

如果我们打开 AOF 持久化,情况会有很大改善。例如我们发送命令 SHUTDOWN 来升级并重启服务,因为 redis expire 是语义实现的,服务关闭的情况下时间也会流逝,我们所有的需求此时都满足。但是如果断电呢?redis 的 fsync 配置默认是一秒一次,在重启之后我们的 key 是可能丢失的。理论上,面对任何类型的重启我们想要保证上锁安全的话,我们需要开启 fsync=always 这个持久化配置项。由于额外的同步开销,这将影响性能。

事情不像第一眼看上去这么糟糕。只要实例崩溃重启后,不再参与任何 当前活跃 的锁,算法的安全性就可以保证。这意味着,当服务重启后活跃的锁都是通过锁住实例获得的,而不是新加入系统的锁。

为了保证这一点,在服务崩溃后,不可用的时间至少要比最大的 TTL 大一点,这个时间让实例中所有存在锁 key 失效,并自动释放。

使用 延迟重启 基本可以实现安全性,即使没有任何的持久化策略,然而需要注意,这可能导致可用性缺失。例如,大多数实例崩溃了,系统将会在 TTL 时间内全局不可用(全局不可用意味着,在这个时间内 没有资源可以被锁住)。

6、让算法更可靠:延长锁

如果客户端执行的工作有包含一些小步骤,可以使用较小的 TTL 的锁。针对客户端,如果在计算过程中,锁的有效期即将结束,可以延长锁,通过发送一个 lua 脚本到所有的实例上,来延长 key 的 TTL 时间(如果 key 存在,并且 value 值是客户端获取锁时分配的随机值)。

客户端只有在锁的有效期内,发送延长锁命令在大多数实例都成功时,才是重新获取了锁(算法耗时和获取锁时的耗时接近)。

你可能感兴趣的:(redis,redis,分布式,算法)