实战篇-17.分布式锁-Redisson功能介绍_哔哩哔哩_bilibili

1.还存在的问题

直接实现很麻烦，借鉴已有的框架。

2.Redisson用法

3.Redisson可重入原理

        在获取锁的时候，看看申请的线程和拿锁的线程是否一致，然后计算该线程获取锁的次数。一个方法完成计数减一，计数为0才能解锁。

        利用hash结构进行计数，但是hash不能像string一样一条set同时设置互斥锁和过期时间，所以必须分开设置。

        为了避免宕机导致的死锁问题，必须用lua脚本去保证获取锁和释放锁几个步骤的原子性。

实战篇-20.分布式锁-Redisson的锁重试和WatchDog机制_哔哩哔哩_bilibili

4.Redisson重试机制原理

利用redis的发布订阅，在释放锁的时候发布消息。

而尝试获取锁失败之后会订阅消息，那么别人释放锁就知道。

等待时间最大等待时间减去获取锁消耗的时间，如果时间到了还没有消息，就不等了。

有消息就重复尝试获取锁。

实战篇-20.分布式锁-Redisson的锁重试和WatchDog机制_哔哩哔哩_bilibili

5.锁时间的超时刷新（看门狗）

ExpirationEntry里存放着一个线程的id以及它对应的递归锁刷新函数renewExpiration()

renewExpiration()每隔10s会自动把时间重新初始化到30s保证锁永不过期，然后递归调用自己继续续期。

加过期时间是为了保证服务宕机的时候锁有自动过期的能力，此时java代码（服务）不会继续续期；而服务没有宕机的时候，能够不断刷新过期时间，保证不会因为业务时间过长而导致锁过期。

总之，一切都为了保证锁是业务执行完成之后事务释放的，而不是锁过期释放的。

一直到unlock函数调用的时候，锁释放，不再续期
 

6.redisson可重入，重试，超时续约 的流程总结

实战篇-21.分布式锁-Redisson的multiLock原理_哔哩哔哩_bilibili

7.multilock连锁保证主从一致性

只有所有主节点获取锁成功才算锁成功，所以不怕一个节点宕机导致其他线程乘虚而入

8思路流程

实战篇-22.秒杀优化-异步秒杀思路_哔哩哔哩_bilibili