最近写大转盘的时候测试那边测到了一个-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单机部署的场景,所以容错性我们暂不考虑。
6.
我们解锁只需要两行代码就搞定了!第一行代码,我们写了一个简单的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
有问题可以私我