一、分布式锁要实现的问题
互斥：在分布式高并发的条件下，我们最需要保证，同一时刻只能有一个线程获得锁，这是最基本的一点。
防止死锁：在分布式高并发的条件下，比如有个线程获得锁的同时，还没有来得及去释放锁，就因为系统故障或者其它原因使它无法执行释放锁的命令,导致其它线程都无法获得锁，造成死锁。所以分布式非常有必要设置锁的有效时间，确保系统出现故障后，在一定时间内能够主动去释放锁，避免造成死锁的情况。
性能：对于访问量大的共享资源，需要考虑减少锁等待的时间，避免导致大量线程阻塞。
- 1、
锁的颗粒度要尽量小。比如你要通过锁来减库存，那这个锁的名称你可以设置成是商品的ID,而不是任取名称。这样这个锁只对当前商品有效,锁的颗粒度小。 - 2、
锁的范围尽量要小。比如只要锁2行代码就可以解决问题的，那就不要去锁10行代码了。
重入：同一个线程可以重复拿到同一个资源的锁。重入锁非常有利于资源的高效利用。
二、Redisson原理
Redisson使用lua脚本语言将多条redis 指令封装成一个脚本语句提交给redis服务器，从而保保证其原子性。
看门狗的意义：为了避免程序突然宕机而锁无法释放问题，我们一般会给锁加一个过期时间。但是如果我们的业务执行时间大于锁的过期时间，怎么处理呢，看门狗的作用就是对执行中的业务锁进行续签。
Redisson如何实现重入：hset 命令插入一个 hset myLock 8743c9c0-0795-4907-87fd-6c71a6b4586:1 1；重入 incrby myLock 8743c9c0-0795-4907-87fd-6c71a6b4586:1 1
- myLock： 是redis的key
- 8743c9c0-0795-4907-87fd-6c71a6b4586：是客户端生成的一个唯一ID
- 1：是线程ID
- 最后一个1：当前线程的获取锁的次数，就是每次重入加1 ；
锁互斥机制
- 客户端2来尝试加锁，执行了同样的一段lua脚本，
- 第一个if判断会执行“exists myLock”，发现myLock这个锁key已经存在了。
- 接着第二个if判断，判断一下，myLock锁key的hash数据结构中，是否包含客户端2的ID，但是明显不是的，因为那里包含的是客户端1的ID。
- 所以，客户端2会获取到pttl myLock返回的一个数字，这个数字代表了myLock这个锁key的剩余生存时间。比如还剩15000毫秒的生存时间。
- 此时客户端2会进入一个while循环，不停的尝试加锁。
三、redis AP问题
我们使用redis‘实现分布式锁，要保证锁的高可用，就必须保证redis的高可用，如果我们使用redis的哨兵+主从模式，由于数据同步的延迟问题，必然会存在某个时刻数据不一致的问题。显然这中分布式锁是不严谨的。
如图所示：线程1对master加锁，突然master宕机，slave被选为主节点，但是slave并没有完全同步master的数据。此时线程2来竞争锁，显然这种场景下一定可以获得锁。但这不是我们期望的结果。
解决方案一：过半成功
如图：我们搭建N台redis服务器，他们之间是彼此独立的，只有加锁成功超过半数我们才认为加锁成功。显然线程2在加锁第三台服务器时是无法成功的。如此可以满足我们的需求。
缺点：浪费资源；效率较低；由于延迟的存在他们的过期时间会不一致
解决方案二：使用zookeeper 实现分布式锁