jedisLock—redis分布式锁实现,java基础教程第三版

本文详细介绍了如何使用Redis的SETNX、GETSET命令实现分布式锁,并讨论了解决死锁的方法,以及提供了Java代码实现。文章还提到了避免并发竞争条件的策略,并提醒在解锁前要再次检查锁的状态。
摘要由CSDN通过智能技术生成

SETNX key value

将 key 的值设为 value ,当且仅当 key 不存在。

若给定的 key 已经存在,则 SETNX 不做任何动作。

SETNX 是『SET if Not eXists』(如果不存在,则 SET)的简写

返回值:

设置成功,返回  1 。

设置失败,返回  0 。

例子:

复制代码

redis> EXISTS job # job 不存在

(integer) 0

redis> SETNX job “programmer” # job 设置成功

(integer) 1

redis> SETNX job “code-farmer” # 尝试覆盖 job ,失败

(integer) 0

redis> GET job # 没有被覆盖

“programmer”

复制代码

所以我们使用执行下面的命令

SETNX lock.foo <current Unix time + lock timeout + 1>

  • 如返回1,则该客户端获得锁,把lock.foo的键值设置为时间值表示该键已被锁定,该客户端最后可以通过DEL lock.foo来释放该锁。

  • 如返回0,表明该锁已被其他客户端取得,这时我们可以先返回或进行重试等对方完成或等待锁超时。

2)getSET

语法:

GETSET key value

将给定 key 的值设为 value ,并返回 key 的旧值(old value)。

当 key 存在但不是字符串类型时,返回一个错误。

返回值:

返回给定  key 的旧值。

当  key 没有旧值时,也即是,  key 不存在时,返回  nil 。

3)get

语法:

GET key

返回值:

当  key 不存在时,返回  nil ,否则,返回  key 的值。

如果  key 不是字符串类型,那么返回一个错误

四、解决死锁

上面的锁定逻辑有一个问题:如果一个持有锁的客户端失败或崩溃了不能释放锁,该怎么解决

我们可以通过锁的键对应的时间戳来判断这种情况是否发生了,如果当前的时间已经大于lock.foo的值,说明该锁已失效,可以被重新使用。

发生这种情况时,可不能简单的通过DEL来删除锁,然后再SETNX一次(讲道理,删除锁的操作应该是锁拥有这执行的,这里只需要等它超时即可),当多个客户端检测到锁超时后都会尝试去释放它,这里就可能出现一个竞态条件,让我们模拟一下这个场景:

[复制代码](https://blog.csdn.net/linzhiqiang0316/article/details/80672072

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值