Redis分布式锁的实现——RedLock

2019-09-21

文章配图是RedLock Python实现的作者optimuspaul的头像。

在分布式应用中经常会存在一些并发的问题,当多个请求想要处理同样的资源时,比如某个操作需要读取资源,根据读取结果进行修改,再写入,若这个步骤没有原子性,多个请求同时进行这样的操作,那就会变得非常混乱。通常来说可以依靠Redis来实现简单的分布式锁机制。

Redis分布式锁SETNX

基于之前的描述,当多个请求需要处理同样的内容时,我们为了确保只有其中一个请求被执行,那么可以借助Redis生成一把锁。并发请求向Redis申请锁,申请成功的人占用本次操作的执行权。因为Redis单线程的特性,一次只处理一个请求,因此后续申请锁的操作都可以被排除。具体代码如下:

set resource_name value ex 5 nx

意味着:

  • 插入一个名为resource_name的键,它的值为value
  • TTL 5秒
  • 只有这个键不存在的情况下才能插入成功

因为nx参数的存在,过期时间内执行相同的操作不会返回1,意味着插入不成功(没申请到锁)。

简易实现的问题

现在来看一下上面的设计有什么问题。

超时

假设现在clinet1拿到了锁,在执行一段时间后超过了设定的ttl,锁过期,client2向Redis执行语句申请锁,因为锁不存在所以client2成功申请到了锁。此时client1仍在继续执行未完成的操作,相当于存在client1和client2共同操作资源的行为。

对于这种问题,当前的锁机制是无法解决的,需要:

  • 避免在分布式中处理超长的任务
  • 适当延长TTL并在执行完后及时对锁DEL
  • 业务上进行处理
  • 取消TTL,改为由client控制锁的DEL

对于最后一种方案,因为client控制锁的归还(del),如果在执行del命令时发生异常,redis服务器没有接收到,或者client出错,没有执行del,将会造成死锁,因为锁会持续存在,其他client不能够正常获取到锁。

锁被其他线程释放

对于上面的设计,不安全的地方在于,若其他线程执行del resource_name操作,那么看起来可以立刻获取一把新锁,从而达到无视锁机制的效果。

为此,在锁的设计上,value需要设计成一个unique值,在del操作前,业务上需要确认del的键的值是否匹配,若不匹配,应该取消del操作。

因此,简单的分布式锁的使用应该修改为:

set resource_name unique_value px 5000 nx

Redis集群分布式锁RedLock

现在继续来考虑一些简易锁的异常问题:

  • client1申请到了锁,Redis记录了这把锁
  • Redis服务发生异常退出
  • Redis服务恢复,但是丢失数据(假设锁没有及时持久化)
  • client2尝试申请锁,因为Redis没有锁存在,因此申请成功
  • client1、client2一起操作资源

由于服务的不可靠,简易锁的实现在特殊情况下会失效。为此,Redis作者提供了一种基于Redis集群的分布式锁——RedLock

We propose an algorithm, called Redlock, which implements a DLM which we believe to be safer than the vanilla single instance approach. We hope that the community will analyze it, provide feedback, and use it as a starting point for the implementations or more complex or alternative designs.