一 redission分布式锁
1.设计原理
在分布式高并发的条件下，我们需要保证同一时刻只能有一个线程获得锁
2.防止死锁
在分布式高并发的条件下，比如有个线程获得锁的同时，没来得及去释放锁，因为系统故障或者其他原因无法执行释放锁的命令，导致其它线程都无法获得锁，造成死锁
所以分布式有必要设置锁的有效时间,确保系统系统故障后，在一定时间能主动去释放锁，避免造成死锁的情况
但是，有种情况是，设计的实效时间小于业务操作时间，这样加锁和解锁就不是同一个线程了，解锁时会抛异常
3.性能
1.锁的颗粒度要尽量小
2.锁的范围尽量要小
（解决设置失效时长小于业务时间）
4.重入
ReentrantLock是可重入锁：同一线程可以重复拿到同一资源的锁
Hash类型
<key<key1,value>>
key
key1 :guid+线程ID
value:锁的次数
如果线程一还没释放锁，线程一再进来，会增加这个锁的时间 次数+1
加锁机制：
线程去获取锁，获取成功：执行lua脚本，保存数据到redis数据库
线程去获取锁，获取失败：一直通过while循环尝试获取锁，获取成功后，执行lua脚本，保存数据到redis数据库
4.1看门狗：
为了避免业务执行时间大于锁的失效时间，那么业务线程1就会启动看门狗的后台线程，不断的延长锁key的生存时间
默认 watchdog是不启动的，另外看门狗启动后对整体性能也有一定影响，所以不建议开启看门狗
5.为什么启用Lua脚本
如果你的业务逻辑复杂，通过封装在lua脚本中发送给redis，而且redis是单线程的，这样就保证这段复杂业务逻辑的执行的原子性
6.分布式锁的缺陷
在哨兵模式下，当线程一在master节点加锁后，再同步slave节点出错，主备切换，slave变成master节点，这时候在线程二再次加锁的时候，也是能加锁成功的
这样就会产生脏数据
