解决Redis分布式锁业务代码超时导致锁失效问题
解决主从架构的redis分布式锁主节点宕机锁丢失的问题

普通实现

说道Redis分布式锁大部分人都会想到:setnx+lua，或者知道set key value px milliseconds nx。后一种方式的核心实现命令如下:

• 获取锁(unique_value可以是UUID等)

SET resource_name unique_value NX PX 30000 

• 1

• 释放锁(lua脚本中，一定要比较value，防止误解锁)

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

• 1
• 2
• 3

这种实现方式有3大要点(也是面试概率非常高的地方):

1. set命令要用set key value px milliseconds nx;
2. value要具有唯一性;
3. 释放锁时要验证value值，不能误解锁;

事实上这类琐最大的缺点就是它加锁时只作用在一个Redis节点上，即使Redis通过sentinel保证高可用，如果这个master节点由于某些原因发生了主从切换，那么就会出现锁丢失的情况:

• 在Redis的master节点上拿到了锁;
• 但是这个加锁的key还没有同步到slave节点;
• master故障，发生故障转移，slave节点升级为master节点;
• 导致锁丢失。

不过这种不安全也仅仅是在主从发生 failover 的情况下才会产生，而且持续时间极短，业务系统多数情况下可以容忍。

如果你很在乎高可用性，希望挂了一台 redis 完全不受影响，可以考虑 redlock。

Redlock实现

Redlock 算法是由Antirez 发明的，它的流程比较复杂，不过已经有了很多开源的 library 做了良好的封装，用户可以拿来即用，比如 redlock-py。

import redlock

  addrs = [{
      "host": "localhost",
      "port": 6379,
      "db": 0
     }, {
      "host": "localhost",
      "port": 6479, 
      "db": 0 
      }, { 
       "host": "localhost",
       "port": 6579,
       "db": 0 
  }]

 dlm = redlock.Redlock(addrs)

 success = dlm.lock("user-lck-laoqian", 5000)

 if success:
     print 'lock success' 
     dlm.unlock('user-lck-laoqian') 

else:
     print 'lock failed' 

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26

RedLock算法的核心原理：

使用N个完全独立、没有主从关系的Redis master节点以保证他们大多数情况下都不会同时宕机，N一般为奇数。一个客户端需要做如下操作来获取锁：

1. 获取当前时间（单位是毫秒）。
2. 轮流用相同的key和随机值在N个节点上请求锁，在这一步里，客户端在每个master上请求锁时，会有一个和总的锁释放时间相比小的多的超时时间。比如如果锁自动释放时间是10秒钟，那每个节点锁请求的超时时间可能是5-50毫秒的范围，这个可以防止一个客户端在某个宕掉的master节点上阻塞过长时间，如果一个master节点不可用了，我们应该尽快尝试下一个master节点。
3. 客户端计算第二步中获取锁所花的时间，只有当客户端在大多数master节点上成功获取了锁（(N/2) +1），而且总共消耗的时间不超过锁释放时间，这个锁就认为是获取成功了。
4. 如果锁获取成功了，那现在锁自动释放时间就是最初的锁释放时间减去之前获取锁所消耗的时间。
5. 如果锁获取失败了，不管是因为获取成功的锁不超过一半（N/2+1)还是因为总消耗时间超过了锁释放时间，客户端都会到每个master节点上释放锁，即便是那些他认为没有获取成功的锁。

简单来说，就是利用多个的主节点，在超过半数以上的主节点获取锁成功，才算成功；否则算失败，回滚–删除之前在所有节点上获取的锁。