使用复述,实现分布式锁及其优化

目前实现分布式锁的方式主要有数据库,复述和管理员三种,本文主要阐述利用复述的相关命令来实现分布式锁。

相关复述,命令

SETNX

如果当前中没有值,则将其设置为并返回1,否则返回0。

到期

将设置为秒后自动过期。

GETSET

将的值设置为,并返回其原来的旧值。如果原来没有旧值,则返回零。

EVALEVALSHA

复述,2.6之后支持的功能,可以将一段lua脚本发送到复述,服务器运行。

起,分布式锁初探

利用SETNX命令的原子性,我们可以简单的实现一个初步的分布式锁(这里原理就不详述了,直接上伪代码):

布尔tryLock(字符串键,int lockSeconds){
如果(SETNX键“1”= = 1){
关键lockSeconds到期
还真
其他} {
返回假
}
}
布尔解锁(String键){
DEL键
}

tryLock是一个非阻塞的分布式锁方法,在获得锁失败后会立即返回。如果需要一个阻塞式的锁方法,可以将tryLock方法包装为轮询(以一定的时间间隔来轮询,这很重要,否则复述,会吃不消!)。

此种方法看似没有什么问题,但其实则有一个漏洞:在加锁的过程中,客户端顺序的向复述,服务器发送了SETNX和到期命令,那么假设在SETNX命令执行完成之后,在到期命令发出去之前客户端发生崩溃(或客户端与复述,服务器的网络连接突然断掉),导致过期命令没有得到执行,其他客户端将会发生永久死锁!

承——分布式锁的改进

2017-11-01更新: 此方法解锁存在漏洞,具体见本后最后的追加内容。

为解决上面提出的问题,可以在加锁时在关键中存储这个锁过期的时间(当前客户端时间戳+锁时间),然后在获取锁失败时,取出价值与当前客户端时间进行比较,如果确定是已经过期的锁,则可以确认发生了上面描述的错误情况,此时可以使用▽清掉这个键,然后再重新尝试去获得这个锁。可以吗?当然不可以!如果没办法保证DEL操作和下次SETNX操作之间的原子性,则还是会产生一个竞态条件,比如这样:

C1 DEL键C1 SETNX关键< expireTime >C2 DEL键C2 SETNX关键< expireTime >

当复述,服务器收到这样的指令序列时,C1和C2的SETNX都同时返回了1,此时C1和C2都认为自己拿到了锁,这种情况明显是不符合预期的。

为解决这个问题,复述的GETSET命令就派上用场了。客户端可以使用GETSET命令去设置自己的过期时间,然后得到的返回值与之前买到的返回值进行比较,如果不同,则表示这个过期的锁被其他客户端抢占了(此时GETSET命令其实已经生效,也就是关键中说的过期时间已经被修改,不过此误差很小,可以忽略不计)。

根据上面的分析思路,可以得出一个改进后的分布式锁,这里直接给出Java的实现代码:

公共 类 RedisLock {
私人 静态 最后日志记录器= LoggerFactory.getLogger(RedisLock.class);
私人 最后StringRedisTemplate StringRedisTemplate;
私人 最后 字节[]lockKey;
公共 RedisLock(StringRedisTemplate StringRedisTemplate,字符串lockKey) {
这。 stringRedisTemplate = stringRedisTemplate;
这。 lockKey = lockKey.getBytes();
}
私人 布尔 tryLock(RedisConnection康涅狄格州,intlockSeconds) 抛出异常{
长nowTime = System.currentTimeMillis();
长expireTime = nowTime + lockSeconds *1000年+1000年;/ /容忍不同服务器时间有1秒内的误差
如果(conn.setNX(lockKey longToBytes(expireTime))){
conn.expire(lockKey lockSeconds);
返回 真正的;
}其他的{
字节[]oldValue = conn.get(lockKey);
如果(oldValue ! =零& & bytesToLong(oldValue)< nowTime){
/ /这个锁已经过期了,可以获得它
/ / PS:如果setNX和到期之间客户端发生崩溃,可能会出现这样的情况
字节[]oldValue2 = conn.getSet(lockKey longToBytes(expireTime));
如果(数组。 =(oldValue oldValue2)){
/ /获得了锁
conn.expire(lockKey lockSeconds);
返回 真正的;
}其他的{
/ /被别人抢占了锁(此时已经修改了lockKey中的值,不过误差很小可以忽略)
返回 假;
}
}
}
返回 假;
}
/ * *
*尝试获得锁,成功返回真,如果失败或异常立即返回错误的
*
*@paramlockSeconds加锁的时间(秒),超过这个时间后锁会自动释放
* /
公共 布尔 tryLock(最后 intlockSeconds) {
返回stringRedisTemplate.execute(新RedisCallback <布尔>(){
@Override
公共布尔doInRedis(RedisConnection康涅狄格州) 抛出DataAccessException{
试一试{
返回tryLock(康涅狄格州,lockSeconds);
}抓(异常e){
logger.error(“tryLock错误”,e);
返回 假;
}
}
});
}
/ * *
*轮询的方式去获得锁,成功返回真,超过轮询次数或异常返回错误的
*
*@paramlockSeconds加锁的时间(秒),超过这个时间后锁会自动释放
*@paramtryIntervalMillis轮询的时间间隔(毫秒)
*@parammaxTryCount最大的轮询次数
* /
公共 布尔 tryLock(最后 intlockSeconds,最后 长tryIntervalMillis,最后 intmaxTryCount) {
返回stringRedisTemplate.execute(新RedisCallback <布尔>(){
@Override
公共布尔doInRedis(RedisConnection康涅狄格州) 抛出DataAccessException{
inttryCount =0;
而(真正的){
如果(+ + tryCount > = maxTryCount){
/ /获取锁超时
返回 假;
}
试一试{
如果(tryLock(康涅狄格州,lockSeconds)){
返回 真正的;
}
}抓(异常e){
logger.error(“tryLock错误”,e);
返回 假;
}
试一试{
thread . sleep(tryIntervalMillis);
}抓(InterruptedException e){
logger.error(“tryLock打断了”,e);
返回 假;
}
}
}
});
}
/ * *
*如果加锁后的操作比较耗时,调用方其实可以在解锁前根据时间判断下锁是否已经过期
*如果已经过期可以不用调用,减少一次请求
* /
公共 无效 解锁() {
stringRedisTemplate.delete(新字符串(lockKey));
}
公共 字节[]longToBytes(长值){
ByteBuffer缓冲= ByteBuffer.allocate(长。 尺寸/ Byte.SIZE);
buffer.putLong(价值);
返回buffer.array();
}
公共 长 bytesToLong(字节[]字节) {
如果(字节。 长度! =长。 尺寸/ Byte.SIZE){
扔 新IllegalArgumentException(“错误的字节长度!”);
}
返回ByteBuffer.wrap(字节).getLong();
}
}

转——分布式锁的优化

2017-11-01更新: 此方法解锁存在漏洞,具体见本后最后的追加内容。

以上的分布式锁实现逻辑已经较为复杂,涉及到了较多的复述,命令,并使得每一次尝试加锁的过程都会有至少2次的复述,命令执行,这也就意味着至少两次与复述,服务器的网络通信。而添加后面复杂逻辑的原因只是因为SETNX与到期这两条命令执行的原子性无法得到保证。(有些同学会提到复述的管道特性,此处明显不适用,因为第二条指令的执行以来与第一条执行的结果,管道无法实现)

另外,上面的分布式锁还有一个问题,那就是服务器之间时间同步的问题。在分布式场景中,多台服务器之间的时间做到同步是非常困难的,所以在代码中我加了1秒的时间容错,但依赖服务器时间的同步还是可能会不靠谱的。

从复述,2.6开始,客户端可以直接向复述,服务器提交Lua脚本,也就是说可以直接在复述,服务器来执行一些较复杂的逻辑,而此脚本的提交对于客户端来说是相对原子性的。这恰好解决了我们的问题!

我们可以用一个这样的lua脚本来描述加锁的逻辑(关于脚本的提交命令和复述的相关规则可以看这里):

如果(redis.call(“setnx”、钥匙(1],ARGV[1)= =1)然后
redis.call(“过期”、钥匙(1),当时(ARGV[2)))
返回 真正的
其他的
返回 假
结束

注意:此脚本中命令的执行并不是严格意义上的原子性,如果其中第二条指令到期执行失败,整个脚本执行会返回错误,但是第一条指令SETNX仍然是已经生效的!不过此种情况基本可以认为是复述,服务器已经崩溃(除非是开发阶段就可以排除的参数错误之类的问题),那么锁的安全性就已经不是这里可以关注的点了。这里认为对客户端来说是相对原子性的就足够了。

这个简单的脚本在复述,服务器得到执行,并返回是否得到锁。因为脚本的提交执行只有一条复述,命令,就避免了上面所说的客户端异常问题。

使用脚本优化了锁的逻辑和性能,这里给出最终的Java实现代码:

公共 类 RedisLock {
私人 静态 最后日志记录器= LoggerFactory.getLogger(RedisLock.class);
私人 最后StringRedisTemplate StringRedisTemplate;
私人 最后字符串lockKey;
私人 最后<字符串>键列表;
/ * *
*使用脚本在复述,服务器执行这个逻辑可以在一定程度上保证此操作的原子性
*(即不会发生客户端在执行setNX和到期命令之间,发生崩溃或失去与服务器的连接导致过期没有得到执行,发生永久死锁)
* < p >
*除非脚本在复述,服务器执行时复述,服务器发生崩溃,不过此种情况锁也会失效
* /
私人 静态 最后RedisScript <布尔> SETNX_AND_EXPIRE_SCRIPT;
静态{
StringBuilder某人=新StringBuilder();
sb.append(“如果(复述。 调用(setnx,键[1],ARGV[1])= = 1),那么\ n ");
sb.append(“\ tredis。 调用(“过期”,键[1],当时(ARGV[2]))\ n”);
sb.append(“\ treturn真的\ n”);
sb.append(“\ n”);
sb.append(“\ treturn假\ n”);
sb.append(“结束”);
SETNX_AND_EXPIRE_SCRIPT =新RedisScriptImpl <布尔>(sb.toString(),Boolean.class);
}
公共 RedisLock(StringRedisTemplate StringRedisTemplate,字符串lockKey) {
这。 stringRedisTemplate = stringRedisTemplate;
这。 lockKey = lockKey;
这。 键= Collections.singletonList(lockKey);
}
私人 布尔 doTryLock(intlockSeconds) 抛出异常{
返回stringRedisTemplate。 execute(SETNX_AND_EXPIRE_SCRIPT、钥匙、“1”String.valueOf(lockSeconds));
}
/ * *
*尝试获得锁,成功返回真,如果失败立即返回错误的
*
*@paramlockSeconds加锁的时间(秒),超过这个时间后锁会自动释放
* /
公共 布尔 tryLock(intlockSeconds) {
试一试{
返回doTryLock(lockSeconds);
}抓(异常e){
logger.error(“tryLock错误”,e);
返回 假;
}
}
/ * *
*轮询的方式去获得锁,成功返回真,超过轮询次数或异常返回错误的
*
*@paramlockSeconds加锁的时间(秒),超过这个时间后锁会自动释放
*@paramtryIntervalMillis轮询的时间间隔(毫秒)
*@parammaxTryCount最大的轮询次数
* /
公共 布尔 tryLock(最后 intlockSeconds,最后 长tryIntervalMillis,最后 intmaxTryCount) {
inttryCount =0;
而(真正的){
如果(+ + tryCount > = maxTryCount){
/ /获取锁超时
返回 假;
}
试一试{
如果(doTryLock(lockSeconds)){
返回 真正的;
}
}抓(异常e){
logger.error(“tryLock错误”,e);
返回 假;
}
试一试{
thread . sleep(tryIntervalMillis);
}抓(InterruptedException e){
logger.error(“tryLock打断了”,e);
返回 假;
}
}
}
/ * *
*如果加锁后的操作比较耗时,调用方其实可以在解锁前根据时间判断下锁是否已经过期
*如果已经过期可以不用调用,减少一次请求
* /
公共 无效 解锁() {
stringRedisTemplate.delete(lockKey);
}
私人 静态 类 RedisScriptImpl<T>实现了 RedisScript<T>{
私人 最后字符串脚本;
私人 最后字符串sha1;
私人 最后类< T > resultType;
公共 RedisScriptImpl(字符串脚本,类< T > resultType) {
这。 脚本=脚本;
这。 sha1 = DigestUtils.sha1DigestAsHex(脚本);
这。 resultType = resultType;
}
@Override
公共字符串getSha1() {
返回sha1;
}
@Override
公共类< T >getResultType() {
返回resultType;
}
@Override
公共字符串getScriptAsString() {
返回脚本;
}
}
}

合——小节

最后,此文内容只是笔者自己学习折腾出来的结果,如果还有什么笔者没有考虑到的缺陷存在,还请不吝指出,大家一起学习进步~

追——解锁漏洞(2017-11-01更新)

经过慎重考虑,发现以上实现的分布式锁有一个较为严重的解锁漏洞:因为解锁操作只是做了简单的DEL KEY,如果某客户端在获得锁后执行业务的时间超过了锁的过期时间,则最后的解锁操作会误解掉其他客户端的操作。

为解决此问题,我们在创建RedisLock对象时用本机时间戳和UUID来创建一个绝对唯一的lockValue,然后在加锁时存入此值,并在解锁前用GET取出值进行比较,如果匹配才做DEL。这里依然需要用LUA脚本保证整个解锁过程的原子性。

这里给出修复此漏洞并做了一些小优化之后的代码:

进口java.util.Collections;
进口java.util.UUID;
进口org.slf4j.Logger;
进口org.slf4j.LoggerFactory;
进口org.springframework.data.redis.core.StringRedisTemplate;
进口org.springframework.data.redis.core.script.DigestUtils;
进口org.springframework.data.redis.core.script.RedisScript;
/ * *
*创建在2017年10/24
*复述,实现的分布式锁(不可重入)
*此对象非线程安全,使用时务必注意
* /
公共 类 RedisLock {
私人 静态 最后日志记录器= LoggerFactory.getLogger(RedisLock.class);
私人 最后StringRedisTemplate StringRedisTemplate;
私人 最后字符串lockKey;
私人 最后字符串lockValue;
私人 布尔锁=假;
/ * *
*使用脚本在复述,服务器执行这个逻辑可以在一定程度上保证此操作的原子性
*(即不会发生客户端在执行setNX和到期命令之间,发生崩溃或失去与服务器的连接导致过期没有得到执行,发生永久死锁)
* < p >
*除非脚本在复述,服务器执行时复述,服务器发生崩溃,不过此种情况锁也会失效
* /
私人 静态 最后RedisScript <布尔> SETNX_AND_EXPIRE_SCRIPT;
静态{
StringBuilder某人=新StringBuilder();
sb.append(“如果(复述。 调用(setnx,键[1],ARGV[1])= = 1),那么\ n ");
sb.append(“\ tredis。 调用(“过期”,键[1],当时(ARGV[2]))\ n”);
sb.append(“\ treturn真的\ n”);
sb.append(“\ n”);
sb.append(“\ treturn假\ n”);
sb.append(“结束”);
SETNX_AND_EXPIRE_SCRIPT =新RedisScriptImpl <布尔>(sb.toString(),Boolean.class);
}
私人 静态 最后RedisScript <布尔> DEL_IF_GET_EQUALS;
静态{
StringBuilder某人=新StringBuilder();
sb.append(“如果(复述。 调用(“得到”,键[1])= = ARGV[1])然后\ n”);
sb.append(“\ tredis。 调用(“▽”键[1])\ n”);
sb.append(“\ treturn真的\ n”);
sb.append(“\ n”);
sb.append(“\ treturn假\ n”);
sb.append(“结束”);
DEL_IF_GET_EQUALS =新RedisScriptImpl <布尔>(sb.toString(),Boolean.class);
}
公共 RedisLock(StringRedisTemplate StringRedisTemplate,字符串lockKey) {
这。 stringRedisTemplate = stringRedisTemplate;
这。 lockKey = lockKey;
这。 .toString lockValue = UUID.randomUUID()()+“。”+ System.currentTimeMillis();
}
私人 布尔 doTryLock(intlockSeconds) 抛出异常{
如果(锁){
扔 新IllegalStateException(“已经锁定!”);
}
锁= stringRedisTemplate。 执行(SETNX_AND_EXPIRE_SCRIPT Collections.singletonList(lockKey)lockValue,
String.valueOf(lockSeconds));
返回锁定;
}
/ * *
*尝试获得锁,成功返回真,如果失败立即返回错误的
*
*@paramlockSeconds加锁的时间(秒),超过这个时间后锁会自动释放
* /
公共 布尔 tryLock(intlockSeconds) {
试一试{
返回doTryLock(lockSeconds);
}抓(异常e){
logger.error(“tryLock错误”,e);
返回 假;
}
}
/ * *
*轮询的方式去获得锁,成功返回真,超过轮询次数或异常返回错误的
*
*@paramlockSeconds加锁的时间(秒),超过这个时间后锁会自动释放
*@paramtryIntervalMillis轮询的时间间隔(毫秒)
*@parammaxTryCount最大的轮询次数
* /
公共 布尔 tryLock(最后 intlockSeconds,最后 长tryIntervalMillis,最后 intmaxTryCount) {
inttryCount =0;
而(真正的){
如果(+ + tryCount > = maxTryCount){
/ /获取锁超时
返回 假;
}
试一试{
如果(doTryLock(lockSeconds)){
返回 真正的;
}
}抓(异常e){
logger.error(“tryLock错误”,e);
返回 假;
}
试一试{
thread . sleep(tryIntervalMillis);
}抓(InterruptedException e){
logger.error(“tryLock打断了”,e);
返回 假;
}
}
}
/ * *
*解锁操作
* /
公共 无效 解锁() {
如果(锁){
扔 新IllegalStateException(“没有锁!”);
}
锁=假;
/ /忽略结果
stringRedisTemplate。 执行(DEL_IF_GET_EQUALS Collections.singletonList(lockKey)lockValue);
}
私人 静态 类 RedisScriptImpl<T>实现了 RedisScript<T>{
私人 最后字符串脚本;
私人 最后字符串sha1;
私人 最后类< T > resultType;
公共 RedisScriptImpl(字符串脚本,类< T > resultType) {
这。 脚本=脚本;
这。 sha1 = DigestUtils.sha1DigestAsHex(脚本);
这。 resultType = resultType;
}
@Override
公共字符串getSha1() {
返回sha1;
}
@Override
公共类< T >getResultType() {
返回resultType;
}
@Override
公共字符串getScriptAsString() {
返回脚本;
}
}
}

原文发布于微信公众号 - JAVA高级架构(gaojijiagou)

原文发表时间:2017-11-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏FD的专栏

Brainfuck JIT Compiler in Rust

我们都知道,对于解释型的语言实现来说,性能是大家关注的焦点。比如,这位 Tondbal ik Ni 曾经还说过:

17330
来自专栏技术翻译

将Elasticsearch直接连接到Java EE应用程序

时髦的大数据来自3 V:音量,种类和速度。卷是指数据的大小,品种是指不同类型的数据,而速度是指数据处理的速度。为了处理持久性大数据,NoSQL数据库可以更快地写...

17130
来自专栏iOS技术

YYCache 源码剖析:一览亮点

YYCache 作为当下 iOS 圈最流行的缓存框架,有着优越的性能和绝佳的设计。笔者花了些时间对其“解剖”了一番,发现了很多有意思的东西,所以写下本文分享一下...

51850
来自专栏代码世界

AJAX

先了解JSON 什么是JSON? JSON 指的是JavaScript对象表示法(JavaScript Object Notation) JSON 是轻量级的文...

46570
来自专栏数说工作室

【SAS Says】基础篇:读取数据(下)

特别说明:本节【SAS Says】基础篇:读取数据(下),用的是数说君学习《The little SAS book》时的中文笔记,我们认为这是打基础的最好选择。...

50860
来自专栏向治洪

Hibernate入门

Hibernate是什么     Hibernate是一个轻量级的ORMapping框架     ORMapping原理(Object Relational M...

21760
来自专栏逆向技术

16位汇编第三讲 分段存储管理思想

      内存分段 一丶分段(汇编指令分段) 1.为什么分段?   因为分段是为了更好的管理数据和代码,就好比C语言为什么会有内存4区一样,否则汇编代码都写...

22760
来自专栏信安之路

PE 病毒与 msf 奇遇记

通俗的讲,PE 病毒就是感染 PE 文件的病毒,通过修改可执行文件的代码中程序入口地址,变为恶意代码的的入口,导致程序运行时执行恶意代码。

11900
来自专栏ChaMd5安全团队

Real World CTF国际大赛 部分WP

题目描述里写平台很安全,请不要攻击。 所以尝试抓包,往Cookie的uid进行sqli

16310
来自专栏软件测试经验与教训

LR windows计数器

28640

扫码关注云+社区

领取腾讯云代金券