加入收藏 | 设为首页 | 会员中心 | 我要投稿 源码网 (https://www.900php.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长学院 > MySql教程 > 正文

Redis实现分布式锁的正确姿势

发布时间:2019-02-03 11:40:26 所属栏目:MySql教程 来源:编辑之路
导读:副标题#e# 一、前言 在我们日常工作中,除了Spring和Mybatis外,用到最多无外乎分布式缓存框架Redis。但是很多工作很多年的朋友对Redis还处于一个最基础的使用和认识。所以我就像把自己对分布式缓存的一些理解和应用整理一个系列,希望可以帮助到大家加深对

2. 当锁过期的时候,如果多个客户端同时执行jedis.getSet()方法,虽然最终只有一个客户端加锁,但是这个客户端的锁的过期时间可能被其他客户端覆盖。不具备加锁和解锁必须是同一个客户端的特性。解决上面这段代码的方式就是为每个客户端加锁添加一个唯一标示,已确保加锁和解锁操作是来自同一个客户端。

3.2 解锁错误姿势

分布式锁的实现无法就2个方法,一个加锁,一个就是解锁。下面我们来看下解锁的错误姿势。

错误姿势1.

  1. /** 
  2.      * 解锁错误姿势1 
  3.      * @param jedis 
  4.      * @param lockKey 
  5.      */ 
  6.     public static void wrongReleaseLock1(Jedis jedis, String lockKey) { 
  7.         jedis.del(lockKey); 
  8.     } 

上面实现是最简单直接的解锁方式,这种不先判断拥有者而直接解锁的方式,会导致任何客户端都可以随时解锁。即使这把锁不是它上锁的。

错误姿势2:

  1. /** 
  2.      * 解锁错误姿势2 
  3.      * @param jedis 
  4.      * @param lockKey 
  5.      * @param requestId 
  6.      */ 
  7.     public static void wrongReleaseLock2(Jedis jedis, String lockKey, String requestId) { 
  8.  
  9.         // 判断加锁与解锁是不是同一个客户端 
  10.         if (requestId.equals(jedis.get(lockKey))) { 
  11.             // 若在此时,这把锁突然不是这个客户端的,则会误解锁 
  12.             jedis.del(lockKey); 
  13.         } 

既然错误姿势1中没有判断锁的拥有者,那姿势2中判断了拥有者,那错误原因又在哪里呢?答案又是原子性上面。因为判断和删除不是一个原子性操作。在并发的时候很可能发生解除了别的客户端加的锁。具体场景有:客户端A加锁,一段时间之后客户端A进行解锁操作时,在执行jedis.del()之前,锁突然过期了,此时客户端B尝试加锁成功,然后客户端A再执行del方法,则客户端A将客户端B的锁给解除了。从而不也不满足加锁和解锁必须是同一个客户端特性。解决思路就是需要保证GET和DEL操作在一个事务中进行,保证其原子性。

四、Redis实现分布式锁的正确姿势

刚刚介绍完了错误的姿势后,从上面错误姿势中,我们可以知道,要使用Redis实现分布式锁。加锁操作的正确姿势为:

  1. 使用setnx命令保证互斥性
  2. 需要设置锁的过期时间,避免死锁
  3. setnx和设置过期时间需要保持原子性,避免在设置setnx成功之后在设置过期时间客户端崩溃导致死锁
  4. 加锁的Value 值为一个唯一标示。可以采用UUID作为唯一标示。加锁成功后需要把唯一标示返回给客户端来用来客户端进行解锁操作

解锁的正确姿势为:

1. 需要拿加锁成功的唯一标示要进行解锁,从而保证加锁和解锁的是同一个客户端

在此我向大家推荐一个架构学习交流圈:830478757  帮助突破瓶颈 提升思维能力

2. 解锁操作需要比较唯一标示是否相等,相等再执行删除操作。这2个操作可以采用Lua脚本方式使2个命令的原子性。

(编辑:源码网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读