可重入锁总结
从实现原理以及源码的层面，真正剖析和了解到了redis分布式锁的企业级的实现，这个分布式锁实现的还是非常漂亮的，麻雀虽小，五脏俱全，分布式的可重入锁，总结一下流程
（1）加锁：在redis里设置hash数据结构，生存周期是30000毫秒
（2）维持加锁：代码里一直加锁，redis里的key会一直保持存活，后台每隔10秒的定时任务（watchdog）不断的检查，只要客户端还在加锁，就刷新key的生存周期为30000毫秒
（3）可重入锁：同一个线程可以多次加锁，就是在hash数据结构中将加锁次数累加1
（4）锁互斥：不同客户端，或者不同线程，尝试加锁陷入死循环等待
（5）手动释放锁：可重入锁自动递减加锁次数，全部释放锁之后删除锁key
（6）宕机自动释放锁：如果持有锁的客户端宕机了，那么此时后台的watchdog定时调度任务也没了，不会刷新锁key的生存周期，此时redis里的锁key会自动释放
（7）尝试加锁超时：在指定时间内没有成功加锁就自动退出死循环，标识本次尝试加锁失败
（8）超时锁自动释放：获取锁之后，在一定时间内没有手动释放锁，则redis里的key自动过期，自动释放锁
这8大机制，组合在一起，才是构成了一个企业级的基于redis的分布式锁的方案
redisson基于redis实现的分布式锁的核心原理给搞通透了，后续我们再看其他的锁，包括公平锁、读写锁、MultiLock、RedLock这一系列的源码的时候，就比较得心应手了。
redis加锁，本质，还是在redis集群中挑选一个master实例来加锁，master -> slave，实现了高可用的机制，如果master宕机，slave会自动切换为master
假设客户端刚刚在master写入一个锁，此时发生了master的宕机，但是master还没来得及将那个锁key异步同步到slave，slave就切换成了新的master。此时别的客户端在新的master上也尝试获取同一个锁，会成功获取锁
此时两个客户端，都会获取同一把分布式锁，可能有的时候就会导致一些数据的问题
redisson的分布式锁，隐患主要就是在这里
预告
下一章开始剖析公平锁是如何实现排队以及加锁逻辑的
