开篇
在负责的项目新实现的一个模块中，要用到分布式锁，实现方案是Redis，结果发现网上大部门的博文都过于老旧或总有考虑不周的地方，这里就和大家分享一个生产可用的Redis分布式锁是什么样的，又有那些考虑和问题。
分布式锁
使用环境
分布式锁的概念网上都是，这里就不再赘述。现在较广泛的实现方案有三种:
- 数据库实现
- zookeeper实现
- 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));
