基于redis实现可靠的分布式锁

On 2016年11月18日2017年1月19日By yuer

什么是锁

今天要谈的是如何在分布式环境下实现一个全局锁，在开始之前先说说非分布式下的锁：

单机 – 单进程程序使用互斥锁mutex，解决多个线程之间的同步问题
单机 – 多进程程序使用信号量sem，解决多个进程之间的同步问题

这里同步的意思很简单：某个运行者，用某个工具，保障某段代码，独占的运行，直到释放。

分布式锁解决的是多台机器 – 多个进程之间的同步问题，因为不同的机器之间mutex/sem无法使用。不过要注意：即便如此，一个进程内多个线程之间仍旧建议使用mutex同步，尽量减少对分布式锁服务造成不必要的负担。

redis分布式锁

首先呢，基于redis的分布式锁并不是一个坊间方案，而是redis官网提供的解决思路并且有若干语言的实现版本直接使用。

今天要做的，首先是阅读官方的文档（中文点我，英文点我），有些地方讲的不怎么清晰，所以我接下来会分析PHP版本的代码，应该可以解答你的主要疑惑。

分析代码

首先打开代码：https://github.com/ronnylt/redlock-php/blob/master/src/RedLock.php，这是PHP的官方推荐实现版本，它基于composer安装（不懂composer可以点我）。

构造函数

    function __construct(array $servers, $retryDelay = 200, $retryCount = 3)
    {
        $this->servers = $servers;
        $this->retryDelay = $retryDelay;
        $this->retryCount = $retryCount;
        $this->quorum  = min(count($servers), (count($servers) / 2 + 1));
    }

function __construct(array $servers, $retryDelay = 200, $retryCount = 3)

{

$this->servers = $servers;

$this->retryDelay = $retryDelay;

$this->retryCount = $retryCount;

$this->quorum = min(count($servers), (count($servers) / 2 + 1));

}

需要传入的是redis的若干master节点地址，并且这些master是纯内存模式且无slave的。
retryDelay是设置每一轮lock失败或者异常，多久之后重新尝试下一轮lock。
retryCount是指最多几轮lock失败后彻底放弃。
quorum体现了分布式里一个有名的”鸽巢原理”，也就是如果大于半数的节点操作成功则认为整个集群是操作成功的；在这里的意思是，如果超过1/2的(>=N/2+1)redis master调用锁成功，则认为获得了整个redis集群的锁，假设A用户获得了集群的锁，那么接下来的B用户只能获得<=1/2的redis master的锁，相当于无法获得集群的锁。

初始化redis连接

private function initInstances()
    {
        if (empty($this->instances)) {
            foreach ($this->servers as $server) {
                list($host, $port, $timeout) = $server;
                $redis = new \Redis();
                $redis->connect($host, $port, $timeout);
                $this->instances[] = $redis;
            }
        }
    }

private function initInstances()

{

if (empty($this->instances)) {

foreach ($this->servers as $server) {

list($host, $port, $timeout) = $server;

$redis = new \Redis();

$redis->connect($host, $port, $timeout);

$this->instances[] = $redis;

}

遍历每个redis master，建立到它们的连接并保存起来；
因为需要用到”鸽巢原理”，也就是redis数量足够产生”大多数”这个目的：因此redis master数量最好>=3台，因为2台的话大多数是2台(2/2+1)，这样任何1台故障就无法产生”大多数”，那么整个分布式锁就不可用了。

请求1个redis上锁

   private function lockInstance($instance, $resource, $token, $ttl)
    {
        return $instance->set($resource, $token, ['NX', 'PX' => $ttl]);
    }

private function lockInstance($instance, $resource, $token, $ttl)

{

return $instance->set($resource, $token, ['NX', 'PX' => $ttl]);

}

请求某一台redis，如果key=resource不存在就设置value=token（算法生成，全局唯一），并且redis会在ttl时间后自动删除这个key

请求1个redis放锁

    private function unlockInstance($instance, $resource, $token)
    {
        $script = '
            if redis.call("GET", KEYS[1]) == ARGV[1] then
                return redis.call("DEL", KEYS[1])
            else
                return 0
            end
        ';
        return $instance->eval($script, [$resource, $token], 1);
    }

private function unlockInstance($instance, $resource, $token)

{

$script = '

if redis.call("GET", KEYS[1]) == ARGV[1] then

return redis.call("DEL", KEYS[1])

else

return 0

end

return $instance->eval($script, [$resource, $token], 1);

}

请求某一台redis，给它发送一段lua脚本，如果resource的value不等于lock时设置的token则说明锁已被它人占用无需释放，否则说明是自己上的锁可以DEL删除。
lua脚本在redis里原子执行，在这里即保障GET和DEL的原子性。

请求集群锁

    public function lock($resource, $ttl)
    {
        $this->initInstances();
        $token = uniqid();
        $retry = $this->retryCount;
        do {
            $n = 0;
            $startTime = microtime(true) * 1000;
            foreach ($this->instances as $instance) {
                if ($this->lockInstance($instance, $resource, $token, $ttl)) {
                    $n++;
                }
            }
            # Add 2 milliseconds to the drift to account for Redis expires
            # precision, which is 1 millisecond, plus 1 millisecond min drift
            # for small TTLs.
            $drift = ($ttl * $this->clockDriftFactor) + 2;
            $validityTime = $ttl - (microtime(true) * 1000 - $startTime) - $drift;
            if ($n >= $this->quorum && $validityTime > 0) {
                return [
                    'validity' => $validityTime,
                    'resource' => $resource,
                    'token'    => $token,
                ];
            } else {
                foreach ($this->instances as $instance) {
                    $this->unlockInstance($instance, $resource, $token);
                }
            }
            // Wait a random delay before to retry
            $delay = mt_rand(floor($this->retryDelay / 2), $this->retryDelay);
            usleep($delay * 1000);
            $retry--;
        } while ($retry > 0);
        return false;
    }

public function lock($resource, $ttl)

{

$this->initInstances();

$token = uniqid();

$retry = $this->retryCount;

do {

$n = 0;

$startTime = microtime(true) * 1000;

foreach ($this->instances as $instance) {

if ($this->lockInstance($instance, $resource, $token, $ttl)) {

$n++;

}

# Add 2 milliseconds to the drift to account for Redis expires

# precision, which is 1 millisecond, plus 1 millisecond min drift

# for small TTLs.

$drift = ($ttl * $this->clockDriftFactor) + 2;

$validityTime = $ttl - (microtime(true) * 1000 - $startTime) - $drift;

if ($n >= $this->quorum && $validityTime > 0) {

return [

'validity' => $validityTime,

'resource' => $resource,

'token' => $token,

];

} else {

foreach ($this->instances as $instance) {

$this->unlockInstance($instance, $resource, $token);

}

// Wait a random delay before to retry

$delay = mt_rand(floor($this->retryDelay / 2), $this->retryDelay);

usleep($delay * 1000);

$retry--;

} while ($retry > 0);

return false;

}

首先整个lock过程最多会重试retry次，因此外层有do while。
为了获取”大多数”的锁，因此遍历每个redis master去lock，统计成功的次数。
因为遍历redis master进行逐个上锁需要花费一定的时间，因此在第1个redis上锁前记录时间T1，结束最后一个redis上锁动作的时间点T2，此时第1个redis的TTL已经消逝了T2-T1这么长的时间。
为了保障在锁内计算期间锁不会失效，我们剩余可以占用锁的时间实际上是TTL – (T2 – T1)，因为越靠前上锁的redis其剩余时间越少，最少的就是第1个redis了。
drift值用于补偿不同机器时钟的精度差异，怎么理解呢：
- 在我们的程序看来时间过去了(T2-T1)，剩余的锁时间认为是TTL-(T2-T1)，在接下来的剩余时间内进行计算应该不会超过锁的有效期。
- 但是第1台redis机器的机器时钟也许跑的比较快（比如时钟多前进了1毫秒），那么数据会提前1毫秒淘汰，然而我们认为TTL-(T2-T1)秒内锁有效，而redis相当于TTL-(T2-T1)-1秒内锁有效，这可能导致我们在锁外计算。（drift+1）
- 另外，我们计算(T2-T1)之后到返回给lock的调用者之间还有一段代码在运行，这段代码的花费也将占用一些时间，所以drift应该也考虑这个。（drift+1）
- 最后，ttl * 0.01的意思是ttl越长，那么时钟可能差异越大，所以这里做了一个动态计算的补偿，比如ttl=100ms，那么就补偿1ms的时钟误差，尽量避免遇到锁已过期而我们仍旧在计算的情况发生。
如果锁redis成功的次数>1/2，并且整个遍历redis+锁定的过程的耗时没有超过锁的有效期，那么lock成功，将剩余的锁时间（TTL减去上锁花费的时间）+ 锁的标识token 返回给用户。
如果上锁中途失败（返回key已存在）或者异常（不知道操作结果），那么都认为上锁失败；如果上锁失败的数量超过1/2，那么本次上锁失败，需要遍历所有redis进行回滚（回滚失败也没有办法，其他人只能等待我们的key过期，并不会有什么错误）。

释放集群锁

    public function unlock(array $lock)
    {
        $this->initInstances();
        $resource = $lock['resource'];
        $token    = $lock['token'];
        foreach ($this->instances as $instance) {
            $this->unlockInstance($instance, $resource, $token);
        }
    }

public function unlock(array $lock)

{

$this->initInstances();

$resource = $lock['resource'];

$token = $lock['token'];

foreach ($this->instances as $instance) {

$this->unlockInstance($instance, $resource, $token);

}

遍历所有redis，利用lua脚本原子的安全的释放自己建立的锁。

故障处理

这里所有redis都是master，不开启持久化，也不需要slave。

如果某台redis宕机，那么不要立即重启它，因为宕机后redis没有任何数据，如果你此时重启它，那么其他进程就可以可以锁住一个本应还没有过期的key，这可能导致2个调用者同时在锁内进行计算，举个例子吧：

3个redis，两个用户A和B，有这么1个典型流程来说明上述情况：

A发起lock，锁住了2个redis(r1+r2)，超过3/2+1（大多数），开始执行锁内操作。
- r0() r1(A) r2(A）
r1宕机，立即重启，数据全部丢失；A仍旧在进行锁内计算，并不知情。
- r0() r1() r2(A)
B发起lock，锁住了2个redis(r0+r1)，超过3/2+1（大多数），开始执行锁内操作。
- r0(B) r1(B) r2(A)

悲剧的事情发生了，因为r1宕机立即重启导致B可以成功锁住”大多数”redis，导致A和B并发操作。

红色字体就是解决这个问题的：不要立即重启，保持r1无法联通，这样的话B只能锁住r0，没有达到”大多数”从而上锁失败。那么何时重启r1呢？根据业务最大的TTL判断，当过了TTL秒后redis中所有key都会过期，遵守规则的A用户的计算也应早已结束，此时B获得锁也可以保证独占。

当然，无论宕机几台原理都是一样的，不要立即重启，等待最大TTL过期后再启动redis，你可以自己分析上述例子，假设r0和r1一起宕机看看又会发生什么。

分布式锁用途

我也没有经验，不过猜想一个场景：

库存服务通常需要高并发的update一行记录以更新商品的剩余数量，而我们知道mysql的update是行锁的，如果并发过高造成mysql的工作线程都在等待行锁，将会影响mysql处理其他请求。

如果可以把行锁用redis锁取代，那么到达mysql层的并发将永远都是1，问题将得到解决，不过要注意上述redis锁的实现有一个问题就是高并发场景下，可能导致谁都无法获取”大多数”的锁，不过好在redis一般足够稳定并且上述实现在lock失败重试时有一个随机的间隔值，从而让某个Lock调用者有机会获得”大多数”。

如果文章帮助您解决了工作难题，您可以帮我点击屏幕上的任意广告，或者赞助少量费用来支持我的持续创作，谢谢~

4 thoughts on “基于redis实现可靠的分布式锁”

太阳当空照，花儿对我说说道：

2016年11月18日下午10:02

不错，很有想法，有个疑问想请教博主：现在大多分布式系统，一致性会借助zk来实现，你这种更适合什么场景？

回复
1. yuer说道：
  
  2016年11月18日下午10:24
  
  可以从下面几个方面考虑：
  
  redis:
  1）非公平锁，简单说就是大家都去抢夺N个redis的坑，谁运气好拿到>=N/2+1个坑就拿到锁，运气不好可能永远锁不上。
  2）锁ttl难以把控，简单说就是lock之后在ttl过期之前必须停止业务计算，这个需要业务自己保证，因此可靠性不敢完全保障。
  3）性能优势，毕竟Redis内存操作性能高。
  4）适合短链接。
  
  zookeeper:
  1）基于递增临时节点实现的锁，本身是公平排队的，先到先得。
  2）锁没有ttl限制，锁住了就是锁住了，直到主动delete或者session过期，其他节点才能获得锁。
  3）更高的一致性，锁状态容易追溯，查询一下就可以一目了然。
  4）适合常驻服务，因为要监听zk事件从而进行锁逻辑处理。
  
  回复
  1. yuer说道：
    
    2016年11月18日下午10:34
    
    zk锁用法可以参考我的github(c++实现)：https://github.com/owenliang/zkclient
    
    回复
  2. voyager1说道：
    
    2017年5月18日上午9:27
    
    👍
    
    回复

什么是锁

redis分布式锁

分析代码

构造函数

初始化redis连接

请求1个redis上锁

请求1个redis放锁

请求集群锁

释放集群锁

故障处理

分布式锁用途

4 thoughts on “基于redis实现可靠的分布式锁”

回复 yuer 取消回复