redis分布式锁的应用场景和一些处理细节

场景

举个最简单的例子，比如说库存系统，你有10件商品，但是有20台服务器，那现在同时有20个用户下单，走的都是如下一段代码。
public void xiaDan(){
// 剩余商品数量
int restProductNum = getNumService();
//如果有存货，就出售
if(restProductNum >0){
doOrderService();
restProductNum --；
}
}
20台服务器 同时走到获取剩余商品数量 代码上，都获取到了10，那是不是就会需要20件商品，不然你就是欺骗消费者。那么单机锁 就没用了，此时就是分布式锁的使用场景了。
其实不用多高端的词汇， 分布式锁， 就是单机管不了，找一个第三方来管，每次减库存的时候，你问我这个第三方来拿一下 剩余商品数量，一次只允许一台服务器访问，访问完了 你得把锁 还给我，我再给下一个服务器访问。
所以主要是实现，怎么实现呢。

实现

理论上来讲，我甚至可以用数据库来做这个第三方，比如建一张表
table LockStatus(
id,
//剩余数量
restNum,
//锁定状态
status
)
比如每一台服务器请求的时候，先查询锁定状态

当然，我没有用过数据库做分布式锁，所以百度了一下，看一下数据库做分布式锁有哪些隐患。
1、在图中 释放锁的时候，服务器宕机，就意味着，锁永远不会过期，那就问题大了，所有人都下不了单了。
2、图中画的是乐观锁，比如现在有100个请求分发到100台服务器，同时查询锁状态，都获取为0，未锁定状态，那么100个请求都以为自己可以获取锁，这个时候我们可以在表中加入一个version版本号的字段，每次获取锁的时候，看一下版本号一不一致，就是在修改状态的时候给版本号+1，这样就会解决大部分冲突。
3、当然在某些特殊场景的时候，比如秒杀，对同一商品的请求，会导致数据库大量的写，版本号不停更新，也就是请求不停的打到数据库上，所以性能是个问题。所以，这个可能是现在分布式锁不用数据库的主要原因吧（数据库表示，我已经很难了o(╥﹏╥)o），纯属个人YY。而且乐观锁也不适合这种场景。
当然，你也可以选择悲观锁，比如查询的状态的时候来一个for update，那么其他线程也就获取不了锁了。问题呢，也是一些常见问题，线程1锁住了，线程2来请求，如果线程1处理时间过长，线程2就会报错，大家都不想自己写的代码在生产上报错吧，所以不太适合在高并发的场景下用数据库的悲观锁。

Redis

那么下面来说一说redis, redis做分布式锁，我们可以利用它的setNx特性，也就是线程1加的锁，那么其他线程就加不了锁了。
SET lock_key threadId NX PX 5000 然后设置一个过期时间防止死锁，解决了上述数据库分布式锁 死锁的问题。
那么然后说一下解锁，以往我们单机解锁，无非是sync方法自动释放，或者lock.unlock()；
当然我们在代码里释放锁，也要放在finally块中，为的是解决即使程序执行错误，也可以释放锁，不影响程序的正常执行。但是这也意味着，不同服务器的finally块都会被执行，都会去释放锁，线程1加锁， 还没执行完，线程2看 锁上了，也不用执行了 直接finally，因为不像单机锁一样，redis释放锁，是执行了如下一段脚本，

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

这边为啥要用这个脚本呢，可以自行百度，保证其原子性，并且保证是当前线程持有锁，才能解锁。
所以我们在解锁前，需要查询一下是否是当前线程持有了锁，所以我们在setNX时候，可以把threadId 给设置进去，或者设置一个UUID，即在解锁的时候保证释放的是当前线程持有的锁。

问题

其实带来新的技术，肯定会让系统变的复杂，比如redis在保证高可用的情况肯定是集群模式，最少三台吧，但是你设置一个key到一台redis的时候，需要同步给剩余两台吧，但是如果同步没完成时，你的master挂掉了，slave升级成了master，也就造成了服务器A加锁成功了，如果服务器B继续过来申请锁也能申请成功，是不是就不对了。然后呢又出来一堆解决方法，巴拉巴拉，什么redLock。
解释一下这个redLock，其实就是比如我有五台redis Master，如果我去三台上申请成功了，我就申请锁成功。当然如果我获取锁的时间超过了超时时间，那锁也就获取不成功。
那redLock就一定没问题了吗？
进程1 获取ABC 三把锁， 还没执行完，锁失效，C先失效了， 进程2又获取了CDE三把锁，那是不是进程1和进程2就获取了同一把锁，就不能完全保证其正确性。
所以如果系统只是要求高性能，redis单点分布式锁其实够用，要求准确性的话，redLock也不行。

那到底什么行呢？听说zk可以。