Redis/Zookeeper分布式锁

同时满足以下条件则必须上锁：1，有共享资源 ；2，多任务；3，共享资源在多任务下互斥

• 一般的锁：同一个jvm，不同的线程（以线程多任务），可以使用java自带的锁
• 分布式锁：对集群中 不同的jvm（以jvm进程多任务），jvm自带的锁锁不到另外的jvm

SetNX [set if not exists] ：
set的key，如果redis中不存在这个key，则set成功并返回true，如果redis中已存在这个key，则不做任何操作，返回false。

实现思路：将资源（请求参数如商品ID） 作为key使用 SetNX存到redis，返回值为true时可以继续执行业务代码（代表抢到锁），为false时代表当前资源被占用，需要在客户端自旋等待锁释放；执行完业务代码，删掉这个key（释放锁）。

• 没有释放锁

  应用已经异常宕机，但redis未感知，key一致存在，则后续任务阻塞。 expire 时设置过期时间。

• 不是原子操作

  setnx不支持设置超时参数，需要额外的指令expire(key, time)，而setnx和expire的非原子性。[ɪkˈspaɪər]

• 提前释放了锁

  expire设置的过期时间太短，而提前释放了锁，导致其他任务抢到锁，造成并发，加锁失败。（Redission 会自动续期。）

• 释放了别人的锁

  是上一个问题的延续问题。A线程持有锁，但是因为任务运行耗时较长，提前释放了锁。B线程获取到锁，B还没执行完，此时A又执行完了，执行锁被释放，而释放掉了B。

  – 解决办法： 将当前线程生成的UUID作为value 存到此key 中，在删除锁的时候， 判断是当前的UUID才删除。
  生成编码规则中使用 redission 的原理就是上述。

• …

利用临时顺序节点znode，创建节点的客户端与zookeeper断开连接后，临时节点会被删除（创建锁和释放锁）。和节点监听。

实现思路：

1. 获取锁

   首先，在Zookeeper当中创建一个持久节点ParentLock。
   当第一个客户端想要获得锁时，需要在ParentLock这个节点下面创建一个临时顺序节点 Lock。
   Client1查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是，则成功获得锁。

   如果再有一个客户端 Client2 前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock2，Client2查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock2是不是顺序最靠前的一个。如果不是，则向它前一个节点Lock1注册Watcher，监听Lock1节点是否存在。这意味着Client2抢锁失败，进入了等待状态。以此类推Lock3监听Lock2，形成了一个等待队列。

2. 释放锁

   Client1任务完成时，会调用删除节点Lock1的指令。或Client1宕机时则会断开与Zookeeper服务端的链接。根据临时节点的特性，相关联的节点Lock1会随之自动删除。

   当Lock1节点被删除，Client2会立刻收到通知。这时候Client2会再次查询ParentLock下面的所有节点，确认自己创建的节点Lock2是不是目前最小的节点。如果是最小，则Client2顺理成章获得了锁。

分布式锁	    优点	                            缺点
--------------------------------------------------------------------------------
Zookeeper	1.有封装好的框架，容易实现。        添加和删除节点性能较低
            2.有等待锁的队列，大大提升抢锁效率。
--------------------------------------------------------------------------------                                            
Redis	    Set和Del指令性能较高	            1.实现复杂，需要考虑超时，原子性，误删等情形。
                                            2.没有等待锁的队列，只能在客户端自旋，效率低下。