一.设计分布式锁的注意事项
1. 互斥
在同一时刻，只有一个线程可以获得锁，这是最基本也是最重要的一点。
2. 防止死锁
在分布式高并发的情况下，假设有一个线程获取了锁，但是因为系统故障或者其他的原因，使它无法去执行释放锁的命令。那么它就会一直持有这一把锁，其他线程就会一直等待，产生死锁。所以我们需要给它设置过期时间，即使发生了这样的情况也能在锁过期后自动释放锁。
3. 性能
- 锁的颗粒度要尽量小：比如要锁库存，那么锁的名称就可以是商品ID，而不是任意名称，这样只有在操作这件商品的时候才会加锁，锁的颗粒度小。
- 锁的范围要尽量小：比如说我们可以只锁二行代码，那么就不要锁十行。所以在用Redission实现分布式锁的时候，常规加锁要优于自定义注解加锁。因为自定义注解加锁只能加在方法上，锁的颗粒度较大。
4.可重入
就像ReentrantLock一样，Redission也可以实现这一点，有利于资源的高效利用。
二.Redission原理
image.png
- 线程一去获取锁，获取成功，执行lua脚本，保存数据到redis数据库。线程二去获取锁，获取失败， 一直通过while循环尝试获取锁。获取成功后，执行lua脚本，保存数据到redis数据库。
- Watch dog所起到的作用就是当锁的有效时间要到了当业务逻辑却还没有执行完成时，延长锁的有效时间。
注：正常这个看门狗线程是不启动的，还有就是这个看门狗启动后对整体性能也会有一定影响，所以不建议开启看门狗。 - 将复杂的业务逻辑封装在lua脚本中发送给redis，且redis是原子性的，这样就保证了这段逻辑的原子性。
- Redisson可以实现可重入加锁机制
image.png
线程二在已经持有锁的情况下再进去，就不需要改线程ID，只需改一下value值即可。这里有点像偏向锁的加锁过程：当检查锁标志位成功的时候，会通过CAS的操作，将Mark Word中的线程ID改为自己的线程ID，并将偏向锁位置为1。如果下一次还是线程二进入同步区，就不需要执行这一步。（不了解的同学可以看一下我的这篇文章 https://www.jianshu.com/p/e63863ee899c） - Redission的缺点
在Redis哨兵模式下，当线程一给master节点写入redission锁，会异步复制给slave节点。如果此时master节点发生故障宕机，就会发生主备切换，slave节点变成了master节点。此时线程二也可以给新的master节点写入redission锁。这样就会产生在同一时刻能有多个客户端对同一个分布式锁加锁，这样就可能会导致脏数据的产生。
