Redis实现分布式锁的正确姿势
2. 当锁过期的时候,如果多个客户端同时执行jedis.getSet()方法,虽然最终只有一个客户端加锁,但是这个客户端的锁的过期时间可能被其他客户端覆盖。不具备加锁和解锁必须是同一个客户端的特性。解决上面这段代码的方式就是为每个客户端加锁添加一个唯一标示,已确保加锁和解锁操作是来自同一个客户端。 3.2 解锁错误姿势分布式锁的实现无法就2个方法,一个加锁,一个就是解锁。下面我们来看下解锁的错误姿势。 错误姿势1.
上面实现是最简单直接的解锁方式,这种不先判断拥有者而直接解锁的方式,会导致任何客户端都可以随时解锁。即使这把锁不是它上锁的。 错误姿势2:
既然错误姿势1中没有判断锁的拥有者,那姿势2中判断了拥有者,那错误原因又在哪里呢?答案又是原子性上面。因为判断和删除不是一个原子性操作。在并发的时候很可能发生解除了别的客户端加的锁。具体场景有:客户端A加锁,一段时间之后客户端A进行解锁操作时,在执行jedis.del()之前,锁突然过期了,此时客户端B尝试加锁成功,然后客户端A再执行del方法,则客户端A将客户端B的锁给解除了。从而不也不满足加锁和解锁必须是同一个客户端特性。解决思路就是需要保证GET和DEL操作在一个事务中进行,保证其原子性。 四、Redis实现分布式锁的正确姿势刚刚介绍完了错误的姿势后,从上面错误姿势中,我们可以知道,要使用Redis实现分布式锁。加锁操作的正确姿势为:
解锁的正确姿势为: 1. 需要拿加锁成功的唯一标示要进行解锁,从而保证加锁和解锁的是同一个客户端 在此我向大家推荐一个架构学习交流圈:830478757 帮助突破瓶颈 提升思维能力 2. 解锁操作需要比较唯一标示是否相等,相等再执行删除操作。这2个操作可以采用Lua脚本方式使2个命令的原子性。 (编辑:源码网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |