Redis分布式锁的正确实现

开篇

  在负责的项目新实现的一个模块中,要用到分布式锁,实现方案是Redis,结果发现网上大部门的博文都过于老旧或总有考虑不周的地方,这里就和大家分享一个生产可用的Redis分布式锁是什么样的,又有那些考虑和问题。

分布式锁

使用环境

  分布式锁的概念网上都是,这里就不再赘述。现在较广泛的实现方案有三种:

  1. 数据库实现
  2. zookeeper实现
  3. Redis实现

  在负责的模块中选用Redis实现方案的理由是因为,Redis实现的分布式锁速度较快,实现简单,并且使用的场景中不涉及数据的增删改且不是核心业务,能够接受分布式锁被超时释放和Redis数据脏读现象。

最low实现

  网上许多提供的代码都是使用Redis的setnx来实现的

> setnx redisLock true
OK
...业务逻辑执行...
> del redisLock

  上述方案最大的问题是在业务逻辑执行时可能出现不可预料的异常,如机器故障,工程抛出异常,网络波动等等。一旦出现问题,创建的锁就无法及时释放,间接导致死锁,整个业务阻塞瘫痪甚至发生雪崩现象。

最常见实现

  下面这种事最low方案的优化版为锁添加了超时时间

> setnx redisLock true
OK
> expire redisLock 5
... 业务逻辑执行 ...
> del redisLock

  可以看到上述方案在创建锁后,为锁添加了超时时间可以避免最low方案中死锁的问题,但是真的是这样么?仔细想想可以发现这种方案可以大大降低死锁的问题,但还是无法完全避免,因为expire 指令和 senx指令并不是原子操作,两个指令并不是一次执行的。如果在执行setnx和expire中间项目出现最low方案中遇到的问题机器故障等等,还是会导致expire没有执行,也会造成死锁。
  可喜可贺的是Redis中提供了setnx 和 expire 组合在一起的原子指令

> set redisLock true ex 10 nx
OK
... 业务逻辑执行 ...
> del redisLock

  这个指令实现了setnx 和 expire的一次执行,解决了可能导致死锁的最后一根稻草,但是这样的实现就可以安全无忧了么?

最终实现

  想到了最常见方案中会出现什么问题了么?这个问题就是超时问题,也是Redis分布式锁相较于zookeeper分布式锁先天劣势的一点,在zookeeper中一但服务器进程down掉或者心跳超时,zk中的临时序列会自动释放。但是Redis中没有这样的机制,导致只能用超时机制来弥补,但是带来的问题就是锁的不安全性。
  如果业务在加锁和释放锁之间的逻辑执行的太长,超出了锁的超时时间,锁就会自动超时释放,但是这时业务还没有执行完,其它业务会因为锁的释放而获取新的锁进入业务执行,导致同时有两个业务在持有锁,出现数据混乱。甚至在第一个业务执行结束后,释放了后进入业务的分布式锁,打乱了整个锁的持有和释放。所以建议Redis分布式锁不要用于较长时间的任务。
  较为安全方案是为set指令的value参数设置一个随机数,删锁时先确认随机数是否一致,然后再删除key。确认value和删除key不是一个原子操作,这就需要使用Lua脚本了,因为Lua脚本可以实现多个连续指令的原子性执行。

//创建锁
String random = Math.random() + "";
jedis.set("redisLock", random, "NX", "EX", 5);

//删除锁
 String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
jedis.eval(script,Collections.singletonList(lockKey), Collections.singletonList(requestId));

推荐阅读更多精彩内容