一、为什么要使用分布式锁
在多实例，负载均衡的情景下，需要使用分布式锁来保证业务不会重复处理
二、分布式锁应该具备哪些条件
1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；
2、高可用的获取锁与释放锁；
3、高性能的获取锁与释放锁；
4、具备可重入特性；
5、具备锁失效机制，防止死锁；
6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。
三、常见的分布式锁的三种实现方式
1.基于数据库实现排他锁
- 基于数据库表做乐观锁，用于分布式锁。（version）
- 基于数据库表做悲观锁（InnoDB，for update）
- 基于数据库表数据记录做唯一约束（表中记录方法名称）
缺点：
1、这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。
2、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。
3、这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。
4、这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。
2.基于zookeeper实现
每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。
缺点：
性能上可能并没有缓存服务那么高。因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。ZK中创建和删除节点只能通过Leader服务器来执行，然后将数据同不到所有的Follower机器上
3.基于redis实现
使用命令SET lockKey lock_value NX PX 30000
原子化命令，加锁和设置失效时间。
缺点：
在这种场景（主从结构）中存在明显的竞态:
客户端A从master获取到锁，
在master将锁同步到slave之前，master宕掉了。
slave节点被晋级为master节点，
客户端B取得了同一个资源被客户端A已经获取到的另外一个锁。安全失效！
