分布式锁

一、
分布式锁，的原理，都是，找一个各个服务都能访问的中间层，然后，通过获得这个中间层的占有权达到锁的效果。

1.1、redis分布式锁
redis锁有一个工具包 redisson
里面包装好了，redis锁相关的各种操作,包括可重入锁、公平锁、联锁、红锁、 读写锁等等，这个待会再说。

1.1.1 如果我们设计，会怎么做。

redis锁的大概原理分析如下:

while(true){
if(redis.setnx(key)){
        // 加锁成功
      ,,,处理逻辑
    // 释放锁
      redis.delete(key);
      break;
} else{
    Thread.sleep(10);

}
}

缺点：这种方式，一旦加锁的服务挂了，setnx成功，redis.delete(key)永远得不到执行，那么这个锁永远存在，其他服务获取不到锁了。

解决方式：setnx加超时机制，但是因为setnx本身没有超时机制，所以需要分步加。

while(true){
    if(redis.setnx(key，value)){
        // 30秒过期
        redis.expire(key, 30秒);
        // 加锁成功
        ,,,处理逻辑
        // 释放锁
         redis.delete(key);
        break;
} else{
    Thread.sleep(10);
}
}

可是这样又有一个问题，如果setnx成功，还没来的急expire，服务就挂了，依然会有锁永远无法释放的问题。

那么假设，加上multi，使得setnx和expire一起执行，那么就不会存在setnx执行后，没有执行expire的问题。但是，multi并非是完全事务的，也就是说，setnx失败，expire还是会执行。所以，可能会造成，key一直被expire刷新过期时间。

而在redis 2.6.12版本之后，set，具有了和setnx一样的功能：
set key value NX PX 30000 ：nx是setnx的意思，px是过期时间的意思，30000毫秒过期。
这样，就能保证set和expire原子性了。

但是，这样又会有新的问题，因为有了过期时间，如果一个线程加锁后，执行业务逻辑时间太长，锁超过了30秒过期时间，锁已经过期了，并且已经被别的线程加锁了，然后这个旧线程delete了别人的锁。

解决方案：

1、可以在服务端，加一个延迟队列，比如ScheduledThreadPoolExecutor线程池，延迟10秒，expire刷新一下过期时间，这样，一旦服务挂了，这个延迟线程池也得不到执行了。

2、set key value的时候，value弄一个uuid，唯一标识符。然后delete的时候，进行对比，相同，则删除，不相同，则回滚，报错什么的。
但是，问题是，这种机制，get value和对比value，应该保证原子性，否则，get value之后，删除value之前，value过期了，并且，被别人加锁了，那么删除value还是会删除别人的锁。
解决方案：eval执行lua脚本，保证get和对比value的原子性。
redis提供了通过lua脚本自定义命令的功能，比如：

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

如此，基本上是能做到分布式的功能。但是，一旦redis挂了，或者如果是主从结构的redis，master节点挂了，锁还没有同步到从节点，然后从节点就哨兵选举成master节点，就会导致有之间锁的线程，错误。
我个人觉得：上面的redis 节点挂了，导致锁的失败影响是很小的。只会影响到一个锁线程，而且，如果value是uuid的话，那个锁线程如果执行完之后，delete节点的时候，发现uuid对不上，还会回滚。如果是延迟expire刷新过期时间的话，确实会造成，两个线程的delete别人的锁。

1.1.2 redis redlock
redis红锁，的大概思想是，在redis cluster环境下，轮流在多个master节点上建立锁，只要当建立的锁的数量大于master节点数量的一半以上，才算建立成功，这样，一旦一个节点挂了，其他线程，也不可能再在一半master节点以上建立锁成功。
建立的锁也是有失效期的，而且，建立锁时有超时机制，在对一个节点建立锁时间太长了，则超时失败，再另一个节点上建锁。
如果建立失败，则依此删除这个锁。

1.1.3 redission的lock
上面说的，redis锁，直接轮询争抢锁的话，会有一个什么问题呢？
如果很多线程并发轮询，而获取锁的线程，迟迟不释放，则会造成cpu负载过高。
redission的lock的实现机制是，eval lua脚本，然后通过redis的pub/sub发布订阅，加上jdk的locksupport.parkNanos()锁线程的方式，解决了轮旋的方式。

总结：redis 锁，很多人都不建议在生产环境使用，比如上面说的单点redis的问题，集群的red lock 也会有时钟漂移等各种问题。
但我个人觉得，使用redission基本上能够很好的搞定分布式锁。

二、zookeeper锁

zookeeper锁

zookeeper的监听回调结点的删除创建机制可以实现分布式锁的功能，大概原理就是加锁，则看是否锁节点存在，存在则说明别人已经获得锁了，则添加一个节点删除监听，然后，等锁释放后，回去回调这个监听，然后重新获得锁。
释放锁，则删除这个节点。

具体代码，这里写的很好：https://www.jianshu.com/p/5d12a01018e1

如果我们使用zookeeper锁，还是用工具类好，比如Curator，可以参考：
https://www.jianshu.com/p/31335efec309

三、zookeeper锁和redis锁对比
redis分布式锁，轮询获取锁，比较消耗性能，zk分布式锁，监听回调机制，性能开销较小

zookeeper不会存在，服务挂了，锁永远存在的线程，zookeeper可以创建临时节点，zookeeper感应到服务挂了，会自己删除锁节点。

三、数据库实现分布式锁
mysql的for update可以实现锁，但是吞吐量太低了，不考虑。