redis分布式锁深度解析（用最通俗易懂的语言）
溪云阁：专注编程教学，架构，JAVA，Python，微服务，机器学习等领域，欢迎关注，一起学习。
前言一直很想做一篇redission的文章来，面试中经常会被问到的问题，左等右等今天有时间来处理这个事，这章分3部分，原理介绍，源码深入，项目实战。原先写过一篇《Springboot实现高性能分布式锁-Redission》，觉得有些地方没有详细描述，打算再做一篇新的。
Redission特性1、互斥锁的能力在同一时刻有且只有一个线程可以获取锁，访问资源的能力。
2、防止死锁高并发的时候，资源被多个线程同时访问或者更改，无论是系统故障还是其他原因导致某一个线程的锁一直无法释放，造成其他线程一直在等待出现死锁问题，Redission加入了超时机制，在一定时间内如果不释放会主动释放这个锁，从而避免了死锁问题。
3、性能强大类似重量级锁，这种类型的锁非常笨重，锁的颗粒度也非常大，导致所消耗的资源也非常大，因此我们在进行加锁的时候需要从锁的颗粒度及范围两点来考虑，Redission是接口级别的锁，可以根据需要进行加锁，性能及灵活性上大大提高
4、重入锁的能力Redission具备ReentrantLock的能力，实现可重入锁，重入锁的特性可以参考《面试不用怕，用最通俗易懂的语言，3分钟记住JAVA的16种锁》。
Redission原理解析
不同线程获取锁，获取成功的话，就执行lua脚本并把数据保存到redis中；如果获取不到，就不断循环获取锁，直到成功。
2：看门狗机制看门狗叫做watch dog，这个理解起来比较拗口，我用业务的形式来解释：线程A拿到锁，需要处理20秒，但是锁的超时时间只有10秒，也就是说锁超时的时候，业务还没处理完，这时候线程B就进来了，又拿到锁，导致加锁跟解锁的时候并不是同一线程。
// 设置看门狗时间，默认是30秒，我们设置为3秒
config.setLockWatchdogTimeout(3000L);
// 如果使用看门狗，一定要使用tryLock
看门狗的作用就是当遇到这种情况的时候，看门狗会定时去查看一下这个线程A是否还在执行任务，如果还在执行则给他继续延长时间。
注意：看门狗存在一定的性能影响，我建议做法是加大超时时间或者针对这些长的业务进行拆分。
Redission并非银弹目前Redission有个问题，在哨兵模式下会出现脏数据
Redis的哨兵模式是MS结构，Master节点跟Slave节点采用异步方式来进行同步，当线程A在Master节点上写入了Redission的值后，此时Master挂了，Slave变成了Master。好巧不巧，线程B也来加锁，这时候在新的Master也能加锁了，多个线程对同一个分布式锁进行了加锁，脏数据来了。
目前针对哨兵模式下的情况，如果有好的解决办法，麻烦评论区指导。
--END--
作者：@溪云阁
原创作品，抄袭必究
如需要源码，请转发，关注后私信我
部分图片或代码来源网络，如侵权请联系删除，谢谢！
,免责声明：本文仅代表文章作者的个人观点，与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺，请读者仅作参考，并自行核实相关内容。文章投诉邮箱：anhduc.ph@yahoo.com
