redisson 分布式锁源码 09:redlock 红锁的故事 - 编程思维

前言

RedLock 红锁,是分布式锁中必须要了解的一个概念。

所以本文会先介绍什么是 RedLock,当大家对 RedLock 有一个基本的了解。然后再看 Redisson 中是如何实现 RedLock 的。

在文章开头先说明 Redisson RedLock 建议不要使用!!!
在文章开头先说明 Redisson RedLock 建议不要使用!!!
在文章开头先说明 Redisson RedLock 建议不要使用!!!

重要的事情重复三遍!

什么是 RedLock?

RedLock,这块可以从网上搜到很多资料,本文也简单介绍下,当做扫盲。

单实例加锁

SET resource_name my_random_value NX PX 30000

对于单实例 Redis 只需要使用这个命令即可。

  • NX:仅在不存在 key 的时候才能被执行成功;
  • PX:失效时间,传入 30000,就是 30s 后自动释放锁;
  • my_random_value:就是随机值,可以是线程号之类的。主要是为了更安全的释放锁,释放锁的时候使用脚本告诉 Redis: 只有 key 存在并且存储的值和我指定的值一样才能删除成功

可以通过以下 Lua 脚本实现锁释放:

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

为什么要设置随机值?

主要是为了防止锁被其他客户端删除。有这么一种情况:

  1. 客户端 A 获得了锁,还没有执行结束,但是锁超时自动释放了;
  2. 客户端 B 此时过来,是可以获得锁的,加锁成功;
  3. 此时,客户端 A 执行结束了,要去释放锁,如果不对比随机值,就会把客户端 B 的锁给释放了。

当然前面看过 Redisson 的处理,这个 my_random_value 存放的是 UUID:ThreadId 组合成的一个类似 931573de-903e-42fd-baa7-428ebb7eda80:1 的字符串。

当锁遇到故障转移

单实例肯定不是很可靠吧?加锁成功之后,结果 Redis 服务宕机了,这不就凉凉~

这时候会提出来将 Redis 主从部署。即使是主从,也是存在巧合的!

主从结构中存在明显的竞态:

  1. 客户端 A 从 master 获取到锁
  2. 在 master 将锁同步到 slave 之前,master 宕掉了。
  3. slave 节点被晋级为 master 节点
  4. 客户端 B 取得了同一个资源被客户端 A 已经获取到的另外一个锁。安全失效!

有时候程序就是这么巧,比如说正好一个节点挂掉的时候,多个客户端同时取到了锁。如果你可以接受这种小概率错误,那用这个基于复制的方案就完全没有问题。

那我使用集群呢?

如果还记得前面的内容,应该是知道对集群进行加锁的时候,其实是通过 CRC16 的 hash 函数来对 key 进行取模,将结果路由到预先分配过 slot 的相应节点上。

发现其实还是发到单个节点上的

RedLock 概念

这时候 Redis 作者提出了 RedLock 的概念

总结一下就是对集群的每个节点进行加锁,如果大多数(N/2+1)加锁成功了,则认为获取锁成功。

RedLock 的问题

看着 RedLock 好像是解决问题了:

  1. 客户端 A 锁住了集群的大多数(一半以上);
  2. 客户端 B 也要锁住大多数;
  3. 这里肯定会冲突,所以 客户端 B 加锁失败。

那实际解决问题了么?

推荐大家阅读两篇文章:

最终,两方各持己见,没有得出结论。

鉴于本文主要是分析 Redisson 的 RedLock,就不做额外赘述,感兴趣的小伙伴可以自己阅读。

Redisson 中 RedLock 源码

这里会简要分析一下 Redisson 中 RedLock 的源码,然后会介绍为什么文章开头不建议大家使用 Redisson 的 RedLock。

使用方式

乍一看,感觉和联锁 MultiLock 的使用方式很像啊!

实际上就是很像,RedissonRedLock 完全是 RedissonMultiLock 的子类嘛!

只不过是重写 failedLocksLimit 方法。

在 MultiLock 中,要所有的锁都锁成功才可以。

在 RedLock 中,要一半以上的锁成功。

剩余部分源码都和 MultiLock 一样,就不在重复描述了。

Redisson 中 RedLock 的问题

1、加锁 key 的问题

阅读源码之前,有一个很大的疑问,我加锁 lock1、lock2、lock3,但是 RedissonRedLock 是如何保证这三个 key 是在归属于 Redis 集群中不同的 master 呢?

因为按照 RedLock 的理论,是需要在半数以上的 master 节点加锁成功

阅读完源码之后,发现 RedissonRedLock 完全是 RedissonMultiLock 的子类,只是重写了 failedLocksLimit 方法,保证半数以上加锁成功即可。

所以这三个 key,是需要用户来保证分散在不同的节点上的。

https://github.com/redisson/r...

在 Redisson 的 issues 也有同样的小伙伴提出这个问题,相关开发者给出的回复是用户来保证 key 分散在不同的 master 上。

https://github.com/redisson/r...

更有小伙伴提出使用 5 个客户端。

那我使用 5 个单节点的客户端,然后再使用红锁,听着好像是可以的,并且 RedissonRedLock 可以这样使用。

但是那和 Redis 集群还有啥关系啊!

所以依然没有解决我的问题,还是需要用户自己来“手工定位锁”。

手工定位锁,这个…… 我考虑了下,还是不用 RedLock 吧!

当然 DarrenJiang1990 同学应该是怀着打破砂锅问到底的心情,又来了一篇 issue。

https://github.com/redisson/r...

意思就是:不要关闭我的 issues,在 #2436 中说可以“手工定位锁”,但是我要怎么手工定位锁。

后来这个 issue 在 10 月才回复。

2、RedissonRedLock 被弃用

是的,没有看错,现在 RedissonRedLock 已经被启用了。

如果是看的英文文档,就会发现:

而中文文档,应该是没有及时更新。

来看看更新记录:

再找一找 issue:

https://github.com/redisson/r...

Redisson 的开发者认为 Redis 的红锁也存在争议(前文介绍的那个争议),但是为了保证可用性,RLock 对象执行的每个 Redis 命令执行都通过 Redis 3.0 中引入的 WAIT 命令进行同步。

WAIT 命令会阻塞当前客户端,直到所有以前的写命令都成功的传输并被指定数量的副本确认。如果达到以毫秒为单位指定的超时,则即使尚未达到指定数量的副本,该命令也会返回。
WAIT 命令同步复制也并不能保证强一致性,不过在主节点宕机之后,只不过会尽可能的选择最佳的副本(slaves)

源码在这一部分。

看源码,同时发送了一个 WAIT 1 1000 到 Redis。

结论

Redisson RedLock 是基于联锁 MultiLock 实现的,但是使用过程中需要自己判断 key 落在哪个节点上,对使用者不是很友好。

Redisson RedLock 已经被弃用,直接使用普通的加锁即可,会基于 wait 机制将锁同步到从节点,但是也并不能保证一致性。仅仅是最大限度的保证一致性。

相关推荐

版权声明:本文版权归作者所有,遵循 CC 4.0 BY-SA 许可协议, 转载请注明原文链接
https://segmentfault.com/a/1190000040335370

学习了java能干什么?薪资怎么样? - 编程思维

学习了java能干什么?工作好找吗?Java的应用领域非常广泛,java能够做网站开发、安卓开发、软件开发、游戏开发、大数据等等。1.web开发,学了Java之后我们可以做网站,以前很多的企业都是用jsp来开发的,一般都是JSP+Servlet+JavaBean,但是现在jsp已经淘汰了,现在都是前后端分离,java的

免费分享spring boot开发的优秀图书 - 编程思维

Spring Boot是由Pivotal团队提供的全新框架,其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置,从而使开发人员不再需要定义样板化的配置。通过这种方式,Spring Boot致力于在蓬勃发展的快速应用开发领域(rapid application developm

试试 intellij idea 自带的高能神器! - 编程思维

本文作者:凯京技术团队 原文链接:https://my.oschina.net/keking...目录从postman到IDEA REST ClientIDEA REST Client控制台历史请求记录构建HTTP请求脚本环境区分结果断言结果值暂存结语前言接口调试是每个软件开发从业者必不可少的一项技能,一个项目的的完成

毕业四年,我当初是如何走上编程这条路的! - 编程思维

题记感慨万千,毕业已达4年之久。想起在大学时期学习编程的事情,感觉很有意义,在此记录回顾一下。希望自己初心未变,勇往向前现状与过去20210706 目前的我是在天津一家公司做软件开发,主要做C#桌面端开发,有时还写点Android,但主技还是C#、ASP.NET。从毕业实习到现在一直在这家公司,是不是很吃惊。毕竟在我同

「万字图文」史上最姨母级java继承详解 - 编程思维

摘要:继承是面向对象软件技术中的一个概念。它使得复用以前的代码非常容易,能够大大缩短开发周期,降低开发费用。本文分享自华为云社区《「万字图文」史上最姨母级Java继承详解丨【奔跑吧!JAVA】》,原文作者: bigsai 。课程导学在Java课堂中,所有老师不得不提到面向对象(Object Oriented),而在谈到

jetbrains 又出了一款新神器,一套代码适应多端! - 编程思维

看到一款基于多端的 UI 调试工具,一套代码适应多端,真的是太棒了,下面分享给大家。1、前言该工具是大名鼎鼎的 JetBrains 公司新推出的,名曰:“Jetpack Compose for Web”,官方介绍称此项目基于 Google 现代 UI 工具包 Jetpack Compose,支持使用 Kotlin 编写

redisson 分布式锁源码 10:读写锁 - 编程思维

前言Redisson 还支持可重入读写锁,允许在分布式场景下,同时有多个读锁和一个写锁处于加锁状态。使用读写锁Redisson 读写锁实现了 JUC 下的 ReadWriteLock,使用方式基本相同。源码加锁源码基本和之前的可重入锁加锁无区别,唯一的差异就是在 Lua 脚本这里。所以下面着重分析 Lua 脚本。读锁源

从源码角度详解java的callable接口 - 编程思维

摘要:本文从源码角度深入解析Callable接口。本文分享自华为云社区《深入解析Callable接口》,作者: 冰 河 。本文纯干货,从源码角度深入解析Callable接口,希望大家踏下心来,打开你的IDE,跟着文章看源码,相信你一定收获不小。1.Callable接口介绍Callable接口是JDK1.5新增的泛型接口

redisson 分布式锁源码 02:看门狗 - 编程思维

前言说起 Redisson,比较耳熟能详的就是这个看门狗(Watchdog)机制。本文就一起看看加锁成功之后的看门狗(Watchdog)是如何实现的?加锁成功在前一篇文章中介绍了可重入锁加锁的逻辑,其中 RedissonLock#tryAcquireAsync 方法是进行异步加锁的逻辑。回顾一下这个方法的入参:wait

redisson 分布式锁源码 01:可重入锁加锁 - 编程思维

前言相信小伙伴都是使用分布式服务,那一定绕不开分布式服务中数据并发更新问题!单系统很容易想到 Java 的各种锁,像 synchronize、ReentrantLock 等等等,那分布式系统如何处理?当然是使用分布式锁。如果小伙伴不知道什么是分布式锁,那推荐看看石杉老师的突击课或者在网上搜一搜相关资料。当使用 Redi

java.util.deque - 编程思维

1、接口定义支持在头尾两端插入和移除元素的线性集合(双端队列:Double Ended Queue,Deque,读音:英[dek]|美[dɛk] )。大多数 Deque 实现对于它们可能包含的元素数量没有固定的限制,不过这个接口对容量设限以及没有固定容量限制的那些 Deque 实现都支持。该接口定义了访问 Deque