基于springboot实现redis分布式锁的方法

在公司的项目中用到了分布式锁,但只会用却不明白其中的规则
所以写一篇文章来记录
使用场景:交易服务,使用redis分布式锁,防止重复提交订单,出现超卖问题

分布式锁的实现方式

  1. 基于数据库乐观锁/悲观锁
  2. Redis分布式锁(本文)
  3. Zookeeper分布式锁

redis是如何实现加锁的?

在redis中,有一条命令,实现锁

SETNX key value

该命令的作用是将 key 的值设为 value ,当且仅当 key 不存在。若给定的 key 已经存在,则 SETNX不做任何动作。设置成功,返回 1 ;设置失败,返回 0

使用 redis 来实现锁的逻辑就是这样的

线程 1 获取锁  -- > setnx lockKey lockvalue
              -- >  1  获取锁成功
线程 2 获取锁  -- > setnx lockKey lockvalue
              -- >  0  获取锁失败  (继续等待,或者其他逻辑)
线程 1 释放锁  -- >
线程 2 获取锁  -- > setnx lockKey lockvalue
              -- > 1 获取成功

接下来我们将基于springboot实现redis分布式锁

1. 引入redis、springmvc、lombok依赖

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.4.0</version>
    <relativePath/> <!-- lookup parent from repository -->
  </parent>
  <groupId>cn.miao.redis</groupId>
  <artifactId>springboot-caffeine-demo</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <name>springboot-redis-lock-demo</name>
  <description>Demo project for Redis Distribute Lock</description>

  <properties>
    <java.version>1.8</java.version>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter</artifactId>
    </dependency>

    <!--redis-->
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-redis</artifactId>
      <version>2.1.4.RELEASE</version>
    </dependency>

    <!--springMvc-->
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
      <version>2.3.3.RELEASE</version>
    </dependency>

    <!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
    <dependency>
      <groupId>org.projectlombok</groupId>
      <artifactId>lombok</artifactId>
      <version>1.18.12</version>
      <scope>provided</scope>
    </dependency>

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-test</artifactId>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
      </plugin>
    </plugins>
  </build>

</project>

2. 新建RedisDistributedLock.java并书写加锁解锁逻辑

import lombok.extern.slf4j.Slf4j;
import org.springframework.data.redis.connection.RedisStringCommands;
import org.springframework.data.redis.connection.ReturnType;
import org.springframework.data.redis.core.RedisCallback;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.types.Expiration;

import java.nio.charset.StandardCharsets;

/**
 * @author miao
 * redis 加锁工具类
 */
@Slf4j
public class RedisDistributedLock {

  /**
   * 超时时间
   */
  private static final long TIMEOUT_MILLIS = 15000;

  /**
   * 重试次数
   */
  private static final int RETRY_TIMES = 10;

  /***
   * 睡眠时间
   */
  private static final long SLEEP_MILLIS = 500;

  /**
   * 用来加锁的lua脚本
   * 因为新版的redis加锁操作已经为原子性操作
   * 所以放弃使用lua脚本
   */
  private static final String LOCK_LUA =
      "if redis.call(\"setnx\",KEYS[1],ARGV[1]) == 1 " +
          "then " +
          "  return redis.call('expire',KEYS[1],ARGV[2]) " +
          "else " +
          "  return 0 " +
          "end";

  /**
   * 用来释放分布式锁的lua脚本
   * 如果redis.get(KEYS[1]) == ARGV[1],则redis delete KEYS[1]
   * 否则返回0
   * KEYS[1] , ARGV[1] 是参数,我们只调用的时候 传递这两个参数就可以了
   * KEYS[1] 主要用來传递在redis 中用作key值的参数
   * ARGV[1] 主要用来传递在redis中用做 value值的参数
   */
  private static final String UNLOCK_LUA =
      "if redis.call(\"get\",KEYS[1]) == ARGV[1] "
          + "then "
          + "  return redis.call(\"del\",KEYS[1]) "
          + "else "
          + "  return 0 "
          + "end ";

  /**
   * 检查 redisKey 是否上锁
   *
   * @param redisKey redisKey
   * @param template template
   * @return Boolean
   */
  public static Boolean isLock(String redisKey, String value, RedisTemplate<Object, Object> template) {

    return lock(redisKey, value, template, RETRY_TIMES);
  }

  private static Boolean lock(String redisKey,
                String value,
                RedisTemplate<Object, Object> template,
                int retryTimes) {

    boolean result = lockKey(redisKey, value, template);

    while (!(result) && retryTimes-- > 0) {
      try {

        log.debug("lock failed, retrying...{}", retryTimes);
        Thread.sleep(RedisDistributedLock.SLEEP_MILLIS);
      } catch (InterruptedException e) {

        return false;
      }
      result = lockKey(redisKey, value, template);
    }

    return result;
  }

  private static Boolean lockKey(final String key,
                  final String value,
                  RedisTemplate<Object, Object> template) {
    try {

      RedisCallback<Boolean> callback = (connection) -> connection.set(
          key.getBytes(StandardCharsets.UTF_8),
          value.getBytes(StandardCharsets.UTF_8),
          Expiration.milliseconds(RedisDistributedLock.TIMEOUT_MILLIS),
          RedisStringCommands.SetOption.SET_IF_ABSENT
      );

      return template.execute(callback);
    } catch (Exception e) {

      log.info("lock key fail because of ", e);
    }

    return false;
  }

  /**
   * 释放分布式锁资源
   *
   * @param redisKey key
   * @param value  value
   * @param template redis
   * @return Boolean
   */
  public static Boolean releaseLock(String redisKey,
                   String value,
                   RedisTemplate<Object, Object> template) {
    try {
      RedisCallback<Boolean> callback = (connection) -> connection.eval(
          UNLOCK_LUA.getBytes(),
          ReturnType.BOOLEAN,
          1,
          redisKey.getBytes(StandardCharsets.UTF_8),
          value.getBytes(StandardCharsets.UTF_8)
      );

      return template.execute(callback);
    } catch (Exception e) {

      log.info("release lock fail because of ", e);
    }

    return false;
  }

}

补充:
1. spring-data-redis 有StringRedisTempla和RedisTemplate两种,但是我选择了RedisTemplate,因为他比较万能。他们的区别是:当你的redis数据库里面本来存的是字符串数据或者你要存取的数据就是字符串类型数据的时候,那么你就使用StringRedisTemplate即可, 但是如果你的数据是复杂的对象类型,而取出的时候又不想做任何的数据转换,直接从Redis里面取出一个对象,那么使用RedisTemplate是 更好的选择。
2.  选择lua脚本是因为,脚本运行是原子性的,在脚本运行期间没有客户端可以操作,所以在释放锁的时候用了lua脚本,
而redis最新版加锁时保证了Redis值和自动过期时间的原子性,所用没用lua脚本

3. 创建测试类 TestController

import lombok.extern.slf4j.Slf4j;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RestController;

import javax.annotation.Resource;

/**
 * @author miao
 */
@RestController
@Slf4j
public class TestController {

  @Resource
  private RedisTemplate<Object, Object> redisTemplate;

  @PostMapping("/order")
  public String createOrder() throws InterruptedException {

    log.info("开始创建订单");

    Boolean isLock = RedisDistributedLock.isLock("testLock", "456789", redisTemplate);

    if (!isLock) {

      log.info("锁已经被占用");
      return "fail";
    } else {
      //.....处理逻辑
    }

    Thread.sleep(10000);
    //一定要记得释放锁,否则会出现问题
    RedisDistributedLock.releaseLock("testLock", "456789", redisTemplate);

    return "success";
  }
}

4. 使用postman进行测试

5. redis分布式锁的缺点

上面我们说的是redis,是单点的情况。如果是在redis sentinel集群中情况就有所不同了。在redis sentinel集群中,我们具有多台redis,他们之间有着主从的关系,例如一主二从。我们的set命令对应的数据写到主库,然后同步到从库。当我们申请一个锁的时候,对应就是一条命令 setnx mykey myvalue ,在redis sentinel集群中,这条命令先是落到了主库。假设这时主库down了,而这条数据还没来得及同步到从库,sentinel将从库中的一台选举为主库了。这时,我们的新主库中并没有mykey这条数据,若此时另外一个client执行 setnx mykey hisvalue , 也会成功,即也能得到锁。这就意味着,此时有两个client获得了锁。这不是我们希望看到的,虽然这个情况发生的记录很小,只会在主从failover的时候才会发生,大多数情况下、大多数系统都可以容忍,但是不是所有的系统都能容忍这种瑕疵。

6.redis分布式锁的优化

为了解决故障转移情况下的缺陷,Antirez 发明了 Redlock 算法,使用redlock算法,需要多个redis实例,加锁的时候,它会想多半节点发送 setex mykey myvalue 命令,只要过半节点成功了,那么就算加锁成功了。释放锁的时候需要想所有节点发送del命令。这是一种基于【大多数都同意】的一种机制。感兴趣的可以查询相关资料。在实际工作中使用的时候,我们可以选择已有的开源实现,python有redlock-py,java 中有Redisson redlock。

redlock确实解决了上面所说的“不靠谱的情况”。但是,它解决问题的同时,也带来了代价。你需要多个redis实例,你需要引入新的库 代码也得调整,性能上也会有损。所以,果然是不存在“完美的解决方案”,我们更需要的是能够根据实际的情况和条件把问题解决了就好。

我大致讲清楚了redis分布式锁方面的问题(日后如果有新的领悟就继续更新)。更多相关springboot redis分布式锁内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • springboot+redis分布式锁实现模拟抢单

    本篇内容主要讲解的是redis分布式锁,这个在各大厂面试几乎都是必备的,下面结合模拟抢单的场景来使用她:本篇不涉及到的redis环境搭建,快速搭建个人测试环境,这里建议使用docker:本篇内容节点如下: jedis的nx生成锁 如何删除锁 模拟抢单动作(10w个人开抢) jedis的nx生成锁 对于java中想操作redis,好的方式是使用jedis,首先pom中引入依赖: <dependency> <groupId>redis.clients</groupId> &

  • SpringBoot使用Redisson实现分布式锁(秒杀系统)

    前面讲完了Redis的分布式锁的实现,接下来讲Redisson的分布式锁的实现,一般提及到Redis的分布式锁我们更多的使用的是Redisson的分布式锁,Redis的官方也是建议我们这样去做的.Redisson点我可以直接跳转到Redisson的官方文档. 1.1.引入Maven依赖 <dependency> <groupId>org.redisson</groupId> <artifactId>redisson-spring-boot-starter&l

  • SpringBoot使用Redis实现分布式锁

    前言 在单机应用时代,我们对一个共享的对象进行多线程访问的时候,使用java的synchronized关键字或者ReentrantLock类对操作的对象加锁就可以解决对象的线程安全问题. 分布式应用时代这个方法却行不通了,我们的应用可能被部署到多台机器上,运行在不同的JVM里,一个对象可能同时存在多台机器的内存中,怎样使共享对象同时只被一个线程处理就成了一个问题. 在分布式系统中为了保证一个对象在高并发的情况下只能被一个线程使用,我们需要一种跨JVM的互斥机制来控制共享资源的访问,此时就需要用到

  • SpringBoot整合Redis正确的实现分布式锁的示例代码

    前言 最近在做分块上传的业务,使用到了Redis来维护上传过程中的分块编号. 每上传完成一个分块就获取一下文件的分块集合,加入新上传的编号,手动接口测试下是没有问题的,前端通过并发上传调用就出现问题了,并发的get再set,就会存在覆盖写现象,导致最后的分块数据不对,不能触发分块合并请求. 遇到并发二话不说先上锁,针对执行代码块加了一个JVM锁之后问题就解决了. 仔细一想还是不太对,项目是分布式部署的,做了负载均衡,一个节点的代码被锁住了,请求轮询到其他节点还是可以进行覆盖写,并没有解决到问题啊

  • SpringBoot集成Redisson实现分布式锁的方法示例

    上篇 <SpringBoot 集成 redis 分布式锁优化>对死锁的问题进行了优化,今天介绍的是 redis 官方推荐使用的 Redisson ,Redisson 架设在 redis 基础上的 Java 驻内存数据网格(In-Memory Data Grid),基于NIO的 Netty 框架上,利用了 redis 键值数据库.功能非常强大,解决了很多分布式架构中的问题. Github的wiki地址: https://github.com/redisson/redisson/wiki 官方文档

  • springboot redis分布式锁代码实例

    这篇文章主要介绍了springboot redis分布式锁代码实例,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 随着微服务等分布式架构的快速发展及应用,在很多情况下,我们都会遇到在并发情况下多个线程竞争资源的情况,比如我们耳熟能详的秒杀活动,多平台多用户对同一个资源进行操作等场景等.分布式锁的实现方式有很多种,比如基于数据库.Zookeeper.Redis等,本文我们主要介绍Spring Boot整合Redis实现分布式锁. 工具类如下: i

  • SpringBoot中使用redis做分布式锁的方法

    一.模拟问题 最近在公司遇到一个问题,挂号系统是做的集群,比如启动了两个相同的服务,病人挂号的时候可能会出现同号的情况,比如两个病人挂出来的号都是上午2号.这就出现了问题,由于是集群部署的,所以单纯在代码中的方法中加锁是不能解决这种情况的.下面我将模拟这种情况,用redis做分布式锁来解决这个问题. 1.新建挂号明细表 2.在idea上新建项目 下图是创建好的项目结构,上面那个parent项目是其他项目不用管它,和新建的没有关系 3.开始创建controller,service,dao(mapp

  • 基于springboot实现redis分布式锁的方法

    在公司的项目中用到了分布式锁,但只会用却不明白其中的规则 所以写一篇文章来记录 使用场景:交易服务,使用redis分布式锁,防止重复提交订单,出现超卖问题 分布式锁的实现方式 基于数据库乐观锁/悲观锁 Redis分布式锁(本文) Zookeeper分布式锁 redis是如何实现加锁的? 在redis中,有一条命令,实现锁 SETNX key value 该命令的作用是将 key 的值设为 value ,当且仅当 key 不存在.若给定的 key 已经存在,则 SETNX不做任何动作.设置成功,返

  • 关于SpringBoot 使用 Redis 分布式锁解决并发问题

    目录 问题背景 解决方案 主要实现原理: 可靠性: SpringBoot 集成使用 Redis 分布式锁 使用示例 参考文档 问题背景 现在的应用程序架构中,很多服务都是多副本运行,从而保证服务的稳定性.一个服务实例挂了,其他服务依旧可以接收请求.但是服务的多副本运行随之也会引来一些分布式问题,比如某个接口的处理逻辑是这样的:接收到请求后,先查询 DB 看是否有相关的数据,如果没有则插入数据,如果有则更新数据.在这种场景下如果相同的 N 个请求并发发到后端服务实例,就会出现重复插入数据的情况:

  • 详解redis分布式锁(优化redis分布式锁的过程及Redisson使用)

    目录 1. redis在实际的应用中 2.如何使用redis的功能进行实现分布式锁 2.1 redis分布式锁思想 2.1.1设计思想: 2.1.2 根据上面的设计思想进行代码实现 2.2 使用redisson进行实现分布式锁 1. redis在实际的应用中 不仅可以用来缓存数据,在分布式应用开发中,经常被用来当作分布式锁的使用,为什么要用到分布式锁呢? 在分布式的开发中,以电商库存的更新功能进行讲解,在实际的应用中相同功能的消费者是有多个的,假如多个消费者同一时刻要去消费一条数据,假如业务逻辑

  • Redis分布式锁升级版RedLock及SpringBoot实现方法

    分布式锁概览 在多线程的环境下,为了保证一个代码块在同一时间只能由一个线程访问,Java中我们一般可以使用synchronized语法和ReetrantLock去保证,这实际上是本地锁的方式.但是现在公司都是流行分布式架构,在分布式环境下,如何保证不同节点的线程同步执行呢?因此就引出了分布式锁,它是控制分布式系统之间互斥访问共享资源的一种方式. 在一个分布式系统中,多台机器上部署了多个服务,当客户端一个用户发起一个数据插入请求时,如果没有分布式锁机制保证,那么那多台机器上的多个服务可能进行并发插

  • Springboot基于Redisson实现Redis分布式可重入锁源码解析

    目录 一.前言 二.为什么使用Redisson 1.我们打开官网 2.我们可以看到官方让我们去使用其他 3.打开官方推荐 4.找到文档 三.Springboot整合Redisson 1.导入依赖 2.以官网为例查看如何配置 3.编写配置类 4.官网测试加锁例子 5.根据官网简单Controller接口编写 6.测试 四.lock.lock()源码分析 1.打开RedissonLock实现类 2.找到实现方法 3.按住Ctrl进去lock方法 4.进去尝试获取锁方法 5.查看tryLockInne

  • 基于Redis实现分布式锁的方法(lua脚本版)

    1.前言 在Java中,我们通过锁来避免由于竞争而造成的数据不一致问题.通常我们使用synchronized .Lock来实现.但是Java中的锁只能保证在同一个JVM进程内中可用,在跨JVM进程,例如分布式系统上则不可靠了. 2.分布式锁 分布式锁,是一种思想,它的实现方式有很多,如基于数据库实现.基于缓存(Redis等)实现.基于Zookeeper实现等等.为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件 互斥性:在任意时刻,只有一个客户端能持有锁. 不会发生死锁:即使客户端

  • 基于Redis分布式锁Redisson及SpringBoot集成Redisson

    目录 - 分布式锁需要具备的条件和刚需 - Redisson使用 - SpringBoot集成Redisson - 分布式锁需要具备的条件和刚需 独占性:OnlyOne,任何时刻只能有且仅有一个线程持有 高可用:若redis集群环境下,不能因为某一个节点挂了而出现获取锁和释放锁失败的情况 防死锁:杜绝死锁,必须有超时控制机制或者撤销操作,有个兜底终止跳出方案 不乱抢:防止张冠李戴,不能私下unlock别人的锁,只能自己加锁自己释放 重入性:同一个节点的同一个线程如果获得锁之后,它也可以再次获取这

随机推荐