分布式锁应该具备哪些条件：
1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；
2、高可用的获取锁与释放锁；
3、高性能的获取锁与释放锁；
4、具备可重入特性；
5、具备锁失效机制，防止死锁；
6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。
常见的分布式锁解决方案如下：
基于数据库实现分布式锁
基于ZooKeeper实现分布锁
基于缓存（Redis等）实现分布式锁
1）基于数据库实现排他锁
在数据库添加一张方法锁表，用于记录每个方法上锁记录
获取锁的SQL:
INSERT INTO method_lock (method_name, desc) VALUES ('methodName', 'methodName');释放锁的SQL：
DELETE FROM method_lock where method_name = methodName;缺点：
反复擦写数据库，效率低下
锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。
锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。
2）基于zookeeper实现
Zookeeper的数据存储结构就像一棵树，这棵树由节点组成，这种节点叫做Znode。 Zookeeper分布式锁利用了临时顺序节点。
获取锁 ：
首先，在Zookeeper当中创建一个持久节点ParentLock。当第一个客户端想要获得锁时，需要在ParentLock这个节点下面创建一个临时顺序节点 Lock1。
之后，Client1查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是第一个节点，则成功获得锁。
这时候，如果再有一个客户端 Client2 前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock2。
Client2查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock2是不是顺序最靠前的一个，结果发现节点Lock2并不是最小的。
于是，Client2向排序仅比它靠前的节点Lock1注册Watcher，用于监听Lock1节点是否存在。这意味着Client2抢锁失败，进入了等待状态。
释放锁
释放锁分为两种情况：
1）任务完成，客户端显示释放
当任务完成时，Client1会显示调用删除节点Lock1的指令。
2）任务执行过程中，客户端崩溃
获得锁的Client1在任务执行过程中，如果Duang的一声崩溃，则会断开与Zookeeper服务端的链接。根据临时节点的特性，相关联的节点Lock1会随之自动删除。
由于Client2一直监听着Lock1的存在状态，当Lock1节点被删除，Client2会立刻收到通知。这时候Client2会再次查询ParentLock下面的所有节点，确认自己创建的节点Lock2是不是目前最小的节点。如果是最小，则Client2顺理成章获得了锁。
3）Redis分布式锁
上面讲过，分布式锁的关键是多进程共享的内存标记，因此只要我们在Redis中放置一个这样的标记就可以了。
多进程可见：多进程可见，否则就无法实现分布式效果
避免死锁：死锁的情况有很多，我们要思考各种异常导致死锁的情况，保证锁可以被释放
排它：同一时刻，只能有一个进程获得锁
高可用：避免锁服务宕机或处理好宕机的补救措施
在Redis中我们可以用下面的方式来解决上述问题：
多进程可见：多进程可见，否则就无法实现分布式效果
redis本身就是多服务共享的，因此自然满足
排它：同一时刻，只能有一个进程获得锁
我们需要利用Redis的setnx命令来实现，setnx是set when not exits的意思。当多次执行setnx命令时，只有第一次执行的才会成功并返回1，其它情况返回0：
我们定义一个固定的key，多个进程都执行setnx，设置这个key的值，返回1的服务获取锁，0则没有获取
避免死锁：死锁的情况有很多，我们要思考各种异常导致死锁的情况
比如服务宕机后的锁释放问题，我们设置锁时最好设置锁的有效期，如果服务宕机，有效期到时自动删除锁。
高可用：避免锁服务宕机或处理好宕机的补救措施
利用Redis的主从、哨兵、集群，保证高可用
基本流程：
1、通过set命令设置锁
2、判断返回结果是否是OK
1）Nil，获取失败，结束或重试（自旋锁）
2）OK，获取锁成功
执行业务
释放锁，DEL 删除key即可
3、异常情况，服务宕机。超时时间EX结束，会自动释放锁
