【redis】redis红锁Redlock算法和底层源码分析
文章目录
- 【redis】redis红锁Redlock算法和底层源码分析
- 前言
- 一、当前代码为8.0版，接上一步
- 分布式锁的主要考点
- lock加锁关键逻辑
- unlock解锁关键逻辑
- 二、redis分布式锁-Redlock红锁
- 主页说明:
- 目前所写的分布式锁还有什么问题？
- Redlock算法设计理念
- 1、官网备注
- 2、设计理念
- 3、解决方案 2x+1台 x为可以容错台数
- 三、使用Redisson进行编码改进 V9.0和V9.1
- RedisConfig
- InventoryController
- BUG uuid+当前线程不正确
- 解决 V9.1版本
- 四、Redisson源码解析
- 分析步骤
- 1、守护线程“续命” redisson使用了“看门狗”定期检查
- 2、获取锁之后，给锁加一个“看门狗” 它会自动执行定时任务，在锁还没有被释放且快要过期的时候会续期
- 3、源码分析1-- 通过redisson新建的锁key，默认过期时间是30s
- 4、源码分析2-- 加锁过程
- 5、源码分析3-- 加锁逻辑
- 6、源码分析4-- “看门狗”程序
- “看门狗”自动延期机制
- 自动续期的lua脚本
- 7、解锁
- 五、多机案例 是因为单机状态下遇到单点故障是致命的
- 理论总结：
- 代码参考：
- 已弃用
- 新的多重锁
- 案例
- CacheConfiguration 容器配置
- controller
- 测试
- 结论
前言
一、当前代码为8.0版，接上一步
分布式锁的主要考点
lock加锁关键逻辑
unlock解锁关键逻辑
二、redis分布式锁-Redlock红锁
主页说明:
目前所写的分布式锁还有什么问题？
一台redis组成的分布式锁有一个致命的缺陷，一旦这台redis宕机，就无法操作分布式锁
Redlock算法设计理念
1、官网备注
2、设计理念
3、解决方案 2x+1台 x为可以容错台数
三、使用Redisson进行编码改进 V9.0和V9.1
RedisConfig
InventoryController
BUG uuid+当前线程不正确
解决 V9.1版本
只有正在锁定状态，且锁还是自己这个uuid+线程id才能解锁
四、Redisson源码解析
分析步骤
1、守护线程“续命” redisson使用了“看门狗”定期检查
2、获取锁之后，给锁加一个“看门狗” 它会自动执行定时任务，在锁还没有被释放且快要过期的时候会续期
3、源码分析1-- 通过redisson新建的锁key，默认过期时间是30s
4、源码分析2-- 加锁过程
5、源码分析3-- 加锁逻辑
流程分析
6、源码分析4-- “看门狗”程序
“看门狗”自动延期机制
自动续期的lua脚本
7、解锁
五、多机案例 是因为单机状态下遇到单点故障是致命的
理论总结：
代码参考：
已弃用
新的多重锁
案例
CacheConfiguration 容器配置
controller
测试
在其中一台宕机了，其他也还会继续工作，说明多重锁在高可用方面是优于单机分布式锁的
注：阳哥说平时单机性能就够用了
结论
底层是hash类型 后边是可重入次数 也是需要解锁的次数
