溪云阁：专注编程教学，架构，JAVA，Python，微服务，机器学习等领域，欢迎关注，一起学习。

前言

一直很想做一篇Redission的文章来，面试中经常会被问到的问题，左等右等今天有时间来处理这个事，这章分3部分，原理介绍，源码深入，项目实战。原先写过一篇《Springboot实现高性能分布式锁-Redission》，觉得有些地方没有详细描述，打算再做一篇新的。

Redission特性

1、互斥锁的能力

在同一时刻有且只有一个线程可以获取锁，访问资源的能力。

2、防止死锁

高并发的时候，资源被多个线程同时访问或者更改，无论是系统故障还是其他原因导致某一个线程的锁一直无法释放，造成其他线程一直在等待出现死锁问题，Redission加入了超时机制，在一定时间内如果不释放会主动释放这个锁，从而避免了死锁问题。

3、性能强大

类似重量级锁，这种类型的锁非常笨重，锁的颗粒度也非常大，导致所消耗的资源也非常大，因此我们在进行加锁的时候需要从锁的颗粒度及范围两点来考虑，Redission是接口级别的锁，可以根据需要进行加锁，性能及灵活性上大大提高

4、重入锁的能力

Redission具备ReentrantLock的能力，实现可重入锁，重入锁的特性可以参考《面试不用怕，用最通俗易懂的语言，3分钟记住JAVA的16种锁》。

Redission原理解析

1：获取锁

不同线程获取锁，获取成功的话，就执行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--

作者：@溪云阁

原创作品，抄袭必究

如需要源码，请转发，关注后私信我

部分图片或代码来源网络，如侵权请联系删除，谢谢！