分布式锁Redisson

一、SpringBoot整合Redisson

1.1 引入pom

 

1.2 配置类

1.3 测试类

二、模拟redis断电

启动两台实例，有一台获取锁后准备释放锁的时候，关闭服务，模拟断电，看会不会发送死锁

访问10000，加上锁后，关闭服务，模拟断电，此时，10000服务还未解锁。

访问10001，正常获取到锁

并且，TTL时间在不断变化，自动续期

三、看门狗原理

3.1 指定锁释放时间

3.2 未指定锁释放时间

 分布式锁

锁续命

lock.lock()

阻塞式等待，默认加的锁都是30s时间，有自动续期功能

锁的自动续期，如果业务超长，运行期间自动给锁续上新的30s。不用担心业务时间长，锁自动过期被删掉。

如果我们未指定锁的超时时间，就使用30s[lockWarchdogTimeout看门狗的默认时间]

只要占锁成功，就会启动一个定时任务[重新给锁设置过期时间，新的过期时间就是看门狗的默认时间30s]，每隔10s都会自动再次续期，续成30s，

internalLockLeaseTime【看门狗时间】/3，10s

加锁的业务只要运行完成，就不会给当前锁续期，即使不手动解锁，锁默认在30s以后自动删除       

无锁续命

lock.lock(10，TimeUnit.SECONDS)

10秒自动解锁，自动解锁时间一定要大于业务的执行时间，lock加了时间以后，不会再走锁续命逻辑

问题：lock.lock(10,TimeUnit.SECONDS)；在锁时间到了以后，不会自动续期

如果我们传递了锁的超时时间，就发送给redis执行脚本，进行占锁，默认超时就是我们指定的时间

即使加时间没有锁续命逻辑，在实战中任然尽量加时间。

lock.lock(30, TimeUnit.SECONDS)，省掉了整个续期操作，手动解锁。

四、读写锁

保证一定能读到最新的数据，修改期间，写锁是一个排他锁(互斥锁)。读锁是一个共享锁

写锁没释放，读就必须等待  

读 + 读：相当于无锁，并发读，只会在redis中记录好，所有当前的读锁。他们都会同时加锁成功

写 + 读：等待写锁释放

写 + 写：阻塞方式

读 + 写：有读锁，写也需要等待。

只要有写的存在，都必须等待

4.1 写延迟30s

4.2 读也延迟30s

五、闭锁(CountDownLatch)

比如，学校放假锁门，1班没人，2班没人了，等等，只有当5个班全部走完了，我们才可以锁大门。

六、信号量(Semaphore)

车库停车，假如有三个车位，来一辆车，就占用一个车位，走了一个释放一个车位，

可以做分布式的限流操作，限制流量，比如，我们当前系统最多能承受每秒1万的并发请求，如果，所有请求，都来我这个服务，可能会压爆，所以，可以这样做。

只要所有请求一上来，它先获取一个信号量，比如这个总量就是1万，它能获取到这个信号量，就说明就有空余的线程给它处理，它要获取不了，那就等别人给它释放了，再来处理，所以可以用来做限流操作。

视频教程