redis分布式锁，key,value参数设置解析，抽奖问题理解

最新推荐文章于 2024-04-10 23:15:20 发布

小龙飞2

最新推荐文章于 2024-04-10 23:15:20 发布

阅读量6.8k

点赞数

分类专栏：后台

本文链接：https://blog.csdn.net/weixin_40898368/article/details/96993944

版权

后台专栏收录该内容

21 篇文章 7 订阅

订阅专栏

最近写大转盘的时候测试那边测到了一个-1问题，也就是抽奖剩余次数变成了-1，这个问题其实很常见，每个后端都会遇到的问题，初出茅庐的我特此记录一下自己第一次遇到并且解决这个问题。

说明：我的剩余次数是 remainTimes = setTimes - drawTimes,即是由设置的活动抽奖次数减去已经抽的次数，设置的抽奖次数是在活动信息表里面，已经抽奖次数是count中奖记录表中中奖条数。

首先，一个抽奖活动一个用户可以抽多次，-1问题出现的原因是因为这个用户疯狂的点击抽奖，前端没有限制，因此大量的请求发送到后台，当用户把抽奖次数耗光了，只剩下1次抽奖机会，两个请求同时过来，验证的时候发现剩余抽奖次数都是1，因此都可以进行抽奖，所以抽了两回，记录插入两回，剩余次数变成了1-2=-1

为了解决这个问题，我引入了redis分布式锁。

伪代码如下：

         //加锁
        String requestId = UUID.randomUUID().toString();
        String lockKey = RedisKeyConstant.IDK_LUCKY_DRAW_KEY + customerId;
        Jedis jedis = jedisPool.getResource();
        if(!RedisUtil.tryGetDistributedLock(jedis, lockKey, requestId, RedisKeyConstant.TDK_LUCKY_DRAW_KEY_EXPIRE_TIME)){   
            //抛出异常“您的操作过于频繁，请稍后再试”
            throw new LuckyDrawException(ErrorCode.LUCKY_DRAW_TOO_MANY_TIMES);
        }

        try{
            //业务代码开始
            //得到剩余次数
            int remainTimes = getRemainTimes(luckyDrawDoc,customerId);
            //进行抽奖权限验证
            //抽奖
            //发奖
            //插入抽奖记录
        }catch (Exception e){
            throw e;
        }finally {
            //释放锁
            if(!RedisUtil.releaseDistributedLock(jedis,lockKey,requestId)){
                log.error("custommerId:"+customerId+" releaseDistributedLock error");
            }
        }

这里是redis的加锁释放锁代码：

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

    /**
     * 尝试获取分布式锁
     *
     * @param jedis      Redis客户端
     * @param lockKey    锁
     * @param requestId  请求标识
     * @param expireTime 超期时间
     * @return 是否获取成功
     *      
     */
    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {
        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
        if (LOCK_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

    /**
     * 释放分布式锁
     *
     * @param jedis     Redis客户端
     * @param lockKey   锁
     * @param requestId 请求标识
     * @return 是否释放成功
     */
    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {

        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));

        if (RELEASE_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

1.首先回到第一个代码，都知道加锁，首先是key,value的设置。这里我的key是锁的字符串是常量+customerId,我锁的是这个用户，因为不同用户不会出现这个问题，如果是秒杀的话就因该锁一个字符串常量了，也就是将整个资源锁起来，所有的请求一起竞争，我这种场景是一个用户进行竞争。如果key变成了一个固定字符串，相当于将整个资源都锁了。

2.锁的粒度。回顾一下我的业务代码，得到剩余次数之后是有一个验证的，剩余次数大于0才可以继续抽奖，如果将锁把就锁前面两行代码即是得到剩余次数，验证，保证了这里是串行，如果小于0则通不过验证抛出异常，一切好像没有问题。然而不是，路过的朋友可以想一下这样会出现什么问题？

再仔细看一下，剩余次数是总的次数减去记录中的数据，那么会存在这么一种情况，一个请求过来得到剩余次数是1，继续运行，还没有插入记录，然后又过来一个请求，得到剩余次数也是1，那么也会继续运行，结果这个锁还是没有起到作用。因此，锁的粒度应该是包括插入语句的。

3.关于抽奖的逻辑，我的另外一篇博客里面有，地址是https://blog.csdn.net/weixin_40898368/article/details/96120035，至于放在try，catch里面，是可以更好的做异常处理，而且将解锁代码放在finally里面可以保证执行。

4.为什么加锁参数中需要requestId,原因就是我们对于锁的可靠性时，分布式锁要满足条件解铃还须系铃人，通过给value赋值为requestId，我们就知道这把锁是哪个请求加的了，在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成。

5.对五个参数进行解释：

加锁就一行代码：jedis.set(String key, String value, String nxxx, String expx, int time)，这个set()方法一共有五个形参：

第一个为key，我们使用key来当锁，因为key是唯一的。
第二个为value，我们传的是requestId，很多童鞋可能不明白，有key作为锁不就够了吗，为什么还要用到value？原因就是我们在上面讲到可靠性时，分布式锁要满足第四个条件解铃还须系铃人，通过给value赋值为requestId，我们就知道这把锁是哪个请求加的了，在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成。
第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作；
第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期的设置，具体时间由第五个参数决定。
第五个为time，与第四个参数相呼应，代表key的过期时间。

总的来说，执行上面的set()方法就只会导致两种结果：1. 当前没有锁（key不存在），那么就进行加锁操作，并对锁设置个有效期，同时value表示加锁的客户端。2. 已有锁存在，不做任何操作。

心细的童鞋就会发现了，我们的加锁代码满足我们可靠性里描述的三个条件。首先，set()加入了NX参数，可以保证如果已有key存在，则函数不会调用成功，也就是只有一个客户端能持有锁，满足互斥性。其次，由于我们对锁设置了过期时间，即使锁的持有者后续发生崩溃而没有解锁，锁也会因为到了过期时间而自动解锁（即key被删除），不会发生死锁。最后，因为我们将value赋值为requestId，代表加锁的客户端请求标识，那么在客户端在解锁的时候就可以进行校验是否是同一个客户端。由于我们只考虑Redis单机部署的场景，所以容错性我们暂不考虑。

我们解锁只需要两行代码就搞定了！第一行代码，我们写了一个简单的Lua脚本代码，上一次见到这个编程语言还是在《黑客与画家》里，没想到这次居然用上了。第二行代码，我们将Lua代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。

那么这段Lua代码的功能是什么呢？其实很简单，首先获取锁对应的value值，检查是否与requestId相等，如果相等则删除锁（解锁）。那么为什么要使用Lua语言来实现呢？因为要确保上述操作是原子性的。那么为什么执行eval()方法可以确保原子性，源于Redis的特性，下面是官网对eval命令的部分解释：

简单来说，就是在eval命令执行Lua代码的时候，Lua代码将被当成一个命令去执行，并且直到eval命令执行完成，Redis才会执行其他命令。

7.redis配置如下，此处我是单机版：

# redis 配置
spring.redis.host=
spring.redis.port=6379
spring.redis.password=
#连接超时时间（毫秒）
spring.redis.timeout=1000
#连接池最大连接数
spring.redis.jedis.pool.max-active=100
#redis最大阻塞等待
spring.redis.jedis.pool.max-wait=-1
#连接池中最大空闲连接
spring.redis.jedis.pool.max-idle=8
#连接池中最小空闲连接
spring.redis.jedis.pool.min-idle=10

package com.aiduoka.stat.common.config;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.cache.CacheManager;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.cache.RedisCacheManager;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;

/**
 * @author by zengzhiqin
 * 2019-07-17
 */
@Configuration
public class RedisConfig {
    @Value("${spring.redis.host}")
    private String hostName;

    @Value("${spring.redis.port}")
    private int port;

    @Value("${spring.redis.password}")
    private String password;

    @Value("${spring.redis.timeout}")
    private int timeout;

    @Value("${spring.redis.jedis.pool.max-idle}")
    private int maxIdle;

    @Value("${spring.redis.jedis.pool.min-idle}")
    private int minIdle;


    @Value("${spring.redis.jedis.pool.max-active}")
    private int maxTotal;

    @Value("${spring.redis.jedis.pool.max-wait}")
    private long maxWaitMillis;



    @Bean
    public JedisPool getJedisPool(){
        JedisPoolConfig config = new JedisPoolConfig();
        config.setMaxTotal(maxTotal);
        config.setMaxIdle(maxIdle);
        config.setMinIdle(minIdle);
        config.setTestOnReturn(false);
        config.setBlockWhenExhausted(true);
        config.setMaxWaitMillis(maxWaitMillis);
        JedisPool pool = new JedisPool(config,hostName,port,timeout,password);
        return pool;
    }

    @Bean
    public CacheManager cacheManager(RedisConnectionFactory factory) {

        return RedisCacheManager.create(factory);
    }
}

下面是我参考过的一篇博客：https://www.cnblogs.com/williamjie/p/9395659.html

有问题可以私我

小龙飞2

关注

0
点赞
踩
17

收藏

觉得还不错? 一键收藏
1
评论
redis分布式锁，key,value参数设置解析，抽奖问题理解

最近写大转盘的时候测试那边测到了一个-1问题，也就是抽奖剩余次数变成了-1，这个问题其实很常见，每个后端都会遇到的问题，初出茅庐的我特此记录一下自己第一次遇到并且解决这个问题。说明：我的剩余次数是 remainTimes = setTimes - drawTimes,即是由设置的活动抽奖次数减去已经抽的次数，设置的抽奖次数是在活动信息表里面，已经抽奖次数是count中奖记录表中中奖条数。首...
复制链接

扫一扫