redis实现分布式锁

最新推荐文章于 2022-04-29 15:28:40 发布
最新推荐文章于 2022-04-29 15:28:40 发布
阅读量399 收藏
点赞数
分类专栏： 分布式 文章标签： 分布式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_39625353/article/details/107117643
版权

一、分布式锁简介

锁 是一种用来解决多个执行线程 访问共享资源 错误或数据不一致问题的工具。

如果 把一台服务器比作一个房子，那么 线程就好比里面的住户，当他们想要共同访问一个共享资源，例如厕所的时候，如果厕所门上没有锁...更甚者厕所没装门...这是会出原则性的问题的..

装上了锁，大家用起来就安心多了，本质也就是 同一时间只允许一个住户使用。

而随着互联网世界的发展，单体应用已经越来越无法满足复杂互联网的高并发需求，转而慢慢朝着分布式方向发展，慢慢进化成了 更大一些的住户。所以同样，我们需要引入分布式锁来解决分布式应用之间访问共享资源的并发问题。

为何需要分布式锁

一般情况下，我们使用分布式锁主要有两个场景：

  1. 避免不同节点重复相同的工作：比如用户执行了某个操作有可能不同节点会发送多封邮件；
  2. 避免破坏数据的正确性：如果两个节点在同一条数据上同时进行操作，可能会造成数据错误或不一致的情况出现；

Java 中实现的常见方式

上面我们用简单的比喻说明了锁的本质：同一时间只允许一个用户操作。所以理论上，能够满足这个需求的工具我们都能够使用 (就是其他应用能帮我们加锁的)：

  1. 基于 MySQL 中的锁：MySQL 本身有自带的悲观锁 for update 关键字，也可以自己实现悲观/乐观锁来达到目的；
  2. 基于 Zookeeper 有序节点：Zookeeper 允许临时创建有序的子节点，这样客户端获取节点列表时，就能够当前子节点列表中的序号判断是否能够获得锁；
  3. 基于 Redis 的单线程：由于 Redis 是单线程，所以命令会以串行的方式执行，并且本身提供了像 SETNX(set if not exists) 这样的指令，本身具有互斥性；

每个方案都有各自的优缺点，例如 MySQL 虽然直观理解容易，但是实现起来却需要额外考虑 锁超时、加事务 等，并且性能局限于数据库，诸如此类我们在此不作讨论，重点关注 Redis。

Redis 分布式锁的问题

1）锁超时

假设现在我们有两台平行的服务 A B，其中 A 服务在 获取锁之后 由于未知神秘力量突然 挂了，那么 B 服务就永远无法获取到锁了：

所以我们需要额外设置一个超时时间，来保证服务的可用性。

但是另一个问题随即而来：如果在加锁和释放锁之间的逻辑执行得太长，以至于超出了锁的超时限制，也会出现问题。因为这时候第一个线程持有锁过期了，而临界区的逻辑还没有执行完，与此同时第二个线程就提前拥有了这把锁，导致临界区的代码不能得到严格的串行执行。

为了避免这个问题，Redis 分布式锁不要用于较长时间的任务。如果真的偶尔出现了问题，造成的数据小错乱可能就需要人工的干预。

有一个稍微安全一点的方案是 将锁的 value 值设置为一个随机数，释放锁时先匹配随机数是否一致，然后再删除 key，这是为了 确保当前线程占有的锁不会被其他线程释放，除非这个锁是因为过期了而被服务器自动释放的。

但是匹配 value 和删除 key 在 Redis 中并不是一个原子性的操作，也没有类似保证原子性的指令，所以可能需要使用像 Lua 这样的脚本来处理了，因为 Lua 脚本可以 保证多个指令的原子性执行。

延伸的讨论：GC 可能引发的安全问题

Martin Kleppmann 曾与 Redis 之父 Antirez 就 Redis 实现分布式锁的安全性问题进行过深入的讨论，其中有一个问题就涉及到 GC。

熟悉 Java 的同学肯定对 GC 不陌生，在 GC 的时候会发生 STW(Stop-The-World)，这本身是为了保障垃圾回收器的正常执行，但可能会引发如下的问题：

服务 A 获取了锁并设置了超时时间，但是服务 A 出现了 STW 且时间较长，导致了分布式锁进行了超时释放，在这个期间服务 B 获取到了锁，待服务 A STW 结束之后又恢复了锁，这就导致了 服务 A 和服务 B 同时获取到了锁，这个时候分布式锁就不安全了。

不仅仅局限于 Redis，Zookeeper 和 MySQL 有同样的问题。

想吃更多瓜的童鞋，可以访问下列网站看看 Redis 之父 Antirez 怎么说：http://antirez.com/news/101

2）单点/多点问题

如果 Redis 采用单机部署模式，那就意味着当 Redis 故障了，就会导致整个服务不可用。

而如果采用主从模式部署，我们想象一个这样的场景：服务 A 申请到一把锁之后，如果作为主机的 Redis 宕机了，那么 服务 B 在申请锁的时候就会从从机那里获取到这把锁，为了解决这个问题，Redis 作者提出了一种 RedLock 红锁 的算法 (Redission 同 Jedis)：

// 三个 Redis 集群
RLock lock1 = redissionInstance1.getLock("lock1");
RLock lock2 = redissionInstance2.getLock("lock2");
RLock lock3 = redissionInstance3.getLock("lock3");

RedissionRedLock lock = new RedissionLock(lock1, lock2, lock2);
lock.lock();
// do something....
lock.unlock();

二、Redis 分布式锁的实现

分布式锁类似于 "占坑"，而 SETNX(SET if Not eXists) 指令就是这样的一个操作，只允许被一个客户端占有，我们来看看 源码(t_string.c/setGenericCommand) 吧：

// SET/ SETEX/ SETTEX/ SETNX 最底层实现
void setGenericCommand(client *c, int flags, robj *key, robj *val, robj *expire, int unit, robj *ok_reply, robj *abort_reply) {
    long long milliseconds = 0; /* initialized to avoid any harmness warning */

    // 如果定义了 key 的过期时间则保存到上面定义的变量中
    // 如果过期时间设置错误则返回错误信息
    if (expire) {
        if (getLongLongFromObjectOrReply(c, expire, &milliseconds, NULL) != C_OK)
            return;
        if (milliseconds <= 0) {
            addReplyErrorFormat(c,"invalid expire time in %s",c->cmd->name);
            return;
        }
        if (unit == UNIT_SECONDS) milliseconds *= 1000;
    }

    // lookupKeyWrite 函数是为执行写操作而取出 key 的值对象
    // 这里的判断条件是：
    // 1.如果设置了 NX(不存在)，并且在数据库中找到了 key 值
    // 2.或者设置了 XX(存在)，并且在数据库中没有找到该 key
    // => 那么回复 abort_reply 给客户端
    if ((flags & OBJ_SET_NX && lookupKeyWrite(c->db,key) != NULL) ||
        (flags & OBJ_SET_XX && lookupKeyWrite(c->db,key) == NULL))
    {
        addReply(c, abort_reply ? abort_reply : shared.null[c->resp]);
        return;
    }
    
    // 在当前的数据库中设置键为 key 值为 value 的数据
    genericSetKey(c->db,key,val,flags & OBJ_SET_KEEPTTL);
    // 服务器每修改一个 key 后都会修改 dirty 值
    server.dirty++;
    if (expire) setExpire(c,c->db,key,mstime()+milliseconds);
    notifyKeyspaceEvent(NOTIFY_STRING,"set",key,c->db->id);
    if (expire) notifyKeyspaceEvent(NOTIFY_GENERIC,
        "expire",key,c->db->id);
    addReply(c, ok_reply ? ok_reply : shared.ok);
}

就像上面介绍的那样，其实在之前版本的 Redis 中，由于 SETNX 和 EXPIRE 并不是 原子指令，所以在一起执行会出现问题。

也许你会想到使用 Redis 事务来解决，但在这里不行，因为 EXPIRE 命令依赖于 SETNX 的执行结果，而事务中没有 if-else 的分支逻辑，如果 SETNX 没有抢到锁，EXPIRE 就不应该执行。

为了解决这个疑难问题，Redis 开源社区涌现了许多分布式锁的 library，为了治理这个乱象，后来在 Redis 2.8 的版本中，加入了 SET指令的扩展参数，使得 SETNX 可以和 EXPIRE 指令一起执行了：

> SET lock:test true ex 5 nx
OK
... do something critical ...
> del lock:test

你只需要符合 SET key value [EX seconds | PX milliseconds] [NX | XX] [KEEPTTL] 这样的格式就好了，你也在下方右拐参照官方的文档：

另外，官方文档也在 SETNX 文档中提到了这样一种思路：把 SETNX 对应 key 的 value 设置为 <current Unix time + lock timeout + 1>，这样在其他客户端访问时就能够自己判断是否能够获取下一个 value 为上述格式的锁了。

代码实现方案一

下面用 Jedis 来模拟实现以下，关键代码如下：

private static final String LOCK_SUCCESS = "OK";
private static final Long RELEASE_SUCCESS = 1L;
private static final String SET_IF_NOT_EXIST = "NX";
private static final String SET_WITH_EXPIRE_TIME = "PX";

@Override
public String acquire() {
    try {
        // 获取锁的超时时间，超过这个时间则放弃获取锁
        long end = System.currentTimeMillis() + acquireTimeout;
        // 随机生成一个 value
        String requireToken = UUID.randomUUID().toString();
        while (System.currentTimeMillis() < end) {
            String result = jedis
                .set(lockKey, requireToken, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
            if (LOCK_SUCCESS.equals(result)) {
                return requireToken;
            }
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
    } catch (Exception e) {
        log.error("acquire lock due to error", e);
    }

    return null;
}

@Override
public boolean release(String identify) {
    if (identify == null) {
        return false;
    }
    //使用 Lua 解释器执行脚本,保证操作的原子性
    String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
    Object result = new Object();
    try {
        result = jedis.eval(script, Collections.singletonList(lockKey),
            Collections.singletonList(identify));
        if (RELEASE_SUCCESS.equals(result)) {
            log.info("release lock success, requestToken:{}", identify);
            return true;
        }
    } catch (Exception e) {
        log.error("release lock due to error", e);
    } finally {
        if (jedis != null) {
            jedis.close();
        }
    }

    log.info("release lock failed, requestToken:{}, result:{}", identify, result);
    return false;
}

 代码实现方案二

环境：springboot 自动配置redis

package com.huobao.utils;

import com.huobao.common.util.StringUtils;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.ValueOperations;
import org.springframework.stereotype.Component;

import java.io.Serializable;
import java.util.Set;
import java.util.concurrent.TimeUnit;

/**
 * Created by lemon on 2020-07-04.
 */
@Slf4j
@Component
public class RedisUtils {

    private final long timeOut = 2000;

    @Autowired
    private RedisTemplate redisTemplate;

    /**
     * 向 redis里面  放入值
     * @param key
     * @param value
     * @return
     */
    public Boolean  setStrData(String key, Object value) {
         return  setStrData(key, value, null);
    }

    /**
     * 向 redis里面设置  数据（可以指定  过期 时间）
     * @param key
     * @param value
     * @param seconds
     * @return
     */
    public Boolean setStrData(String key, Object value, Integer seconds) {
        try {
            ValueOperations<Serializable, Object> valueOperations = redisTemplate.opsForValue();
            if (null != seconds) {
                valueOperations.set(key, value,seconds, TimeUnit.MILLISECONDS);
            }else{
                valueOperations.set(key,value);
            }
        } catch (Exception e) {
            e.printStackTrace();
            log.error("向redis添加数据异常",e);
            return false;
        }
        return true;
    }


    /**
     * 获取 数据
     * @param key
     * @return
     */
    public Object getData(String key) {
        try {
            ValueOperations<Serializable, Object> valueOperations = redisTemplate.opsForValue();
            return valueOperations.get(key);
        } catch (Exception e) {
            e.printStackTrace();
            log.error("redis获取数据异常",e);
            return null;
        }
    }


    /**
     * 加锁
     * @param key 被加锁的值
     * @param value 当前线程操作时的
     * @return
     */
    public boolean lock(String key, String value) {
        try{
            //如果key值不存在，则返回 true，且设置 value
            if (redisTemplate.opsForValue().setIfAbsent(key, value)) {
                return true;
            }
            // 获取锁的超时时间，超过这个时间则放弃获取锁
            long end = System.currentTimeMillis() + timeOut;
            while (System.currentTimeMillis() < end) {
                //获取key的值，判断是是否超时
                String curVal = (String) redisTemplate.opsForValue().get(key);
                if (StringUtils.isNotEmpty(curVal) && Long.parseLong(curVal) < System.currentTimeMillis()) {
                    //设新值还旧值并与刚进入方法获取的旧值比较，因为如果该行代码出现并发，都可以getAndSet成功，但是只能第一个线程执行的获取锁
                    String oldVal = (String)redisTemplate.opsForValue().getAndSet(key, value);
                    if(StringUtils.isNotEmpty(oldVal) && oldVal.equals(curVal)) {
                        return true;
                    }
                }
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        }catch (Exception e){
            log.info("获取锁异常",e);
        }
        return false;
    }
    /**
     * 解锁
     * @param key 被加锁的值
     * @param value
     */
    public void unlock(String key, String value) {
        try {
            //解锁时，传入值与目前锁的值比较，避免解了他人的锁，比如获取锁执行逻辑时因为异常原因时间过长，导致锁过期失效，期间别的线程获取了锁
            String curVal = (String)redisTemplate.opsForValue().get(key);
            if (StringUtils.isNotEmpty(curVal) && curVal.equals(value)) {
                redisTemplate.opsForValue().getOperations().delete(key);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

}

使用锁的代码演示


    
    public Boolean saveAccountWithdraw(@RequestBody AccountWithdrawDto accountWithdrawDto) {
        Long time = System.currentTimeMillis() + 2000;
        boolean lockFlag = false;
        try {
            //获取锁
            lockFlag = redisUtils.lock("WITHDRAW2C_"+accountWithdrawDto.getUserId(), time.toString());
            if(lockFlag){
                // 执行逻辑
                return true;
            }
        }catch (Exception e){
            log.error("申请提现异常：",e);
        }finally {
            if(lockFlag) {
                redisUtils.unlock("WITHDRAW2C_"+accountWithdrawDto.getUserId(), time.toString());
            }
        }
        return false;
    }

 

卧虫呀
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
redis加锁工具RedisLockUtils
MrBxiong的博客
03-04 3605
redis分布式锁 RedisLockUtils 有很多大佬介绍分布式锁实现方式的文章，在这主要记录一个线程的redis加锁工具 https://www.cnblogs.com/0201zcr/p/5942748.html import java.util.ArrayList; import java.util.List; import org.apache.commons.lang.Strin...
RedisLockUtils.java
12-11
RedisLockUtils.java
redis分布式锁
rrz634171的专栏
10-27 175
public final class RedisLockUtil { private static final int defaultExpire = 60; /** * 加锁 * @param key redis key * @param expire 过期时间，单位秒 * @return true:加锁成功，false，加锁失败 */ public static boolean lock2(String key, int ex...
Java基于redis实现分布式锁代码实例
08-19
Java基于Redis实现分布式锁代码实例 分布式锁的必要性 在多线程环境中，资源竞争是一个常见的问题。例如，在一个简单的用户操作中，一个线程修改用户状态，首先在内存中读取用户状态，然后在内存中进行修改，然后...
redis实现分布式锁,自旋式加锁,lua原子性解锁
07-16
本文将深入探讨如何使用Redis实现分布式锁，以及如何利用自旋式加锁和Lua脚本实现原子性解锁。 首先，我们来理解分布式锁的基本概念。分布式锁是在多节点之间共享资源时，用于协调各个节点的访问控制机制。在分布式...
Redis实现分布式锁(附源码+讲义)
07-01
分布式锁有很多种解决方案，今天我们要讲的是怎么使用缓存数据库Redis来实现分布式锁。 课程目标:  理解redis分布式锁的应用场景  掌握redis分布式锁的实现原理  掌握redis分布式锁在微服务项目中的应用  掌握...
SpringBoot使用Redis实现分布式锁
08-19
SpringBoot 使用 Redis 实现分布式锁 分布式锁是指在分布式系统中，多个节点或机器之间对共享资源的访问进行控制和协调，以避免冲突和竞争的机制。SpringBoot 使用 Redis 实现分布式锁是指使用 SpringBoot 框架和 ...
redisTemplate封装成redisUtils和分布式锁实现
06-18
redisTemplate封装成redisUtils和分布式锁实现,亲测可用
基于Redis方式实现分布式锁
09-24
基于Redis方式实现分布式锁
使用Redis实现分布式锁.zip
06-06
本文将深入探讨如何利用Redis实现分布式锁，并对比其与信号量的区别。 一、Redis分布式锁 1. **基本原理**：在Redis中，分布式锁通常通过`SETNX`（Set if Not eXists）命令或者`SET`命令配合`nx`和`ex`选项来创建...
基于redis实现分布式锁的原理与方法
12-14
redis实现分布式锁 数据库实现分布式锁 zk实现分布式锁 今天我们介绍通过redis实现分布式锁。实际上这三种和java对比看属于一类。都是属于程序外部锁。 原理剖析 上述三种分布式锁都是通过各自为依据对各个请求...
redis实现分布式锁(java/jedis)
08-06
redis实现分布式锁(java/jedis),其中包含工具方法以及使用demo 本资源是利用java的jedis实现 redis实现分布式锁(java/jedis),其中包含工具方法以及使用demo 本资源是利用java的jedis实现
redis锁 Redlock
jm19920911的博客
05-24 1712
参考文章：https://blog.csdn.net/pfnie/article/details/52234735#commentBox public class RedisUtil { //失效时间 public static int ONE_DAY = 60 * 60 * 24; //锁的过期时间,秒 private static long LOC...
Redis实现分布式锁
记录各种Bug解决案例及日常学习内容
04-29 1077
目录一、Redis分布式锁实现思路二、Zookeeper实现分布式锁思路三、分布式锁的应用场景有那些四、Redis分布式锁核心代码1. Maven2. Service3. utils 一、Redis分布式锁实现思路 Redis实现分布式锁基于SetNx命令，因为在Redis中key是保证是唯一的。所以当多个线程同时的创建setNx时，只要谁能够创建成功谁就能够获取到锁。 Set 命令 每次set时，可以修改原来旧值； SetNx命令 每次SetNx检查该 key是否已经存在，如果已经存在的话不会执行任何操作
redis实现分布式锁与java信号量.zip
最新发布
06-07
在实际项目中，`redis实现分布式锁与java信号量.md`文件可能详细介绍了如何将这些理论知识应用到实际代码中，包括连接Redis、设置和获取锁、释放锁、异常处理等步骤。而`项目说明.zip`文件则可能包含了一个实际的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值