Spring Boot+Redis 分布式锁：模拟抢单

标签：return String val Spring Redis 抢单 jedis key append

如何删除锁 模拟抢单动作(10w个⼈开抢) jedis的nx⽣成锁 对于java中想操作redis，好的⽅式是使⽤jedis，⾸先pom中引⼊依赖：

<dependency> <groupId> redis.clients </groupId> <artifactId> jedis </artifactId> </dependency>

对于分布式锁的⽣成通常需要注意如下⼏个⽅⾯： 创建锁的策略： 创 redis的普通key⼀般都允许覆盖，A⽤⼾set某个key后，B在set相同的key时同样能成功，如果是锁场景， 那就⽆法知道到底是哪个⽤⼾set成功的；这⾥jedis的setnx⽅式为我们解决了这个问题，简单原理是：当A⽤⼾先set成功 了，那B⽤⼾set的时候就返回失败，满⾜了某个时间点只允许⼀个⽤⼾拿到锁。 锁过期时间： 锁 某个抢购场景时候，如果没有过期的概念，当A⽤⼾⽣成了锁，但是后⾯的流程被阻塞了⼀直⽆法释放锁，那 其他⽤⼾此时获取锁就会⼀直失败，⽆法完成抢购的活动；当然正常情况⼀般都不会阻塞，A⽤⼾流程会正常释放锁；过期 时间只是为了更有保障。 下⾯来上段setnx操作的代码：

p boolean setnx(String key, String val) {
Jedis jedis = null;
try t {
jedis = jedisPool.getResource();
iiff (jedis == null) {
return r false;
}
return r jedis.set(key, val, "NX", "PX", 1000 * 60).
equalsIgnoreCase("ok");
} catch c (Exception ex) {
} finally f {
iiff (jedis != null) {
jedis.close();
}
}
return r false;
}

这⾥注意点在于jedis的set⽅法，其参数的说明如： NX：是否存在key，存在就不set成功 PX：key过期时间单位设置为毫秒（EX：单位秒） setnx如果失败直接封装返回false即可，下⾯我们通过⼀个get⽅式的api来调⽤下这个setnx⽅法：

@GetMapping("/setnx/{key}/{val}")
public boolean setnx(@PathVariable String key, @PathVariable String val) {
return r jedisCom j .setnx(key, val);
}

访问如下测试url，正常来说第⼀次返回了true，第⼆次返回了false，由于第⼆次请求的时候redis的key已存在，所以⽆法set成 功 由上图能够看到只有⼀次set成功，并key具有⼀个有效时间，此时已到达了分布式锁的条件。 如何删除锁 如 上⾯是创建锁，同样的具有有效时间，但是我们不能完全依赖这个有效时间，场景如：有效时间设置1分钟，本⾝⽤⼾A获取锁 后，没遇到什么特殊情况正常⽣成了抢购订单后，此时其他⽤⼾应该能正常下单了才对，但是由于有个1分钟后锁才能⾃动释 放，那其他⽤⼾在这1分钟⽆法正常下单（因为锁还是A⽤⼾的），因此我们需要A⽤⼾操作完后，主动去解锁：

public int i delnx(String key, String val) {
Jedis jedis = null;
try {
jedis = jedisPool.getResource();
iiff (jedis == null) {
return r 0;
}
//if redis.call('get','orderkey')=='1111' then return redis.call('del','orderkey') else return 0 end
StringBuilder sbScript = new StringBuilder();
sbScript.append("if redis.call('get','").append(key).append("')").append("=='").append(val).append("'").
append(" then ").
append(" return redis.call('del','").append(key).append("')").
append(" else ").
append(" return 0").
append(" end");
return r Integer.valueOf(jedis.eval(sbScript.toString()).toString());
} catch (Exception ex) {
} finally {
iiff (jedis != null) {
jedis.close();
}
}
return r 0;
}

这⾥也使⽤了jedis⽅式，直接执⾏lua脚本：根据val判断其是否存在，如果存在就del； 其实个⼈认为通过jedis的get⽅式获取val后，然后再⽐较value是否是当前持有锁的⽤⼾，如果是那最后再删除，效果其实相 当；只不过直接通过eval执⾏脚本，这样避免多⼀次操作了redis⽽已，缩短了原⼦操作的间隔。(如有不同⻅解请留⾔探讨)；同 样这⾥创建个get⽅式的api来测试：

@GetMapping("/delnx/{key}/{val}")
public int delnx(@PathVariable String key, @PathVariable String val) {
return r jedisCom j .delnx(key, val);
}

注意的是delnx时，需要传递创建锁时的value，因为通过et的value与delnx的value来判断是否是持有锁的操作请求，只有 value⼀样才允许del； 模拟抢单动作(10w个⼈开抢) 模 有了上⾯对分布式锁的粗略基础，我们模拟下10w⼈抢单的场景，其实就是⼀个并发操作请求⽽已，由于环境有限，只能如此测 试；如下初始化10w个⽤⼾，并初始化库存，商品等信息，如下代码：

//总库存
private p long nKuCuen = 0;
//商品key名字
private p String shangpingKey = "computer_key";
//获取锁的超时时间 秒
private p int timeout = 30 * 1000;
@GetMapping @ ("/qiangdan")
public p List<String> qiangdan() {
//抢到商品的⽤⼾
List<String> shopUsers = new n ArrayList<>();
//构造很多⽤⼾
List<String> users = new n ArrayList<>();
IntStream.range(0, 100000).parallel().forEach(b -> {
users.add("神⽜-" + b);
});
//初始化库存
nKuCuen = 10;
//模拟开抢
users.parallelStream().forEach(b -> {
String shopUser = qiang(b);
iiff (!StringUtils.isEmpty(shopUser)) {
shopUsers.add(shopUser);
}
});
return r shopUsers;
}

有了上⾯10w个不同⽤⼾，我们设定商品只有10个库存，然后通过并⾏流的⽅式来模拟抢购，如下抢购的实现： /**

/**
* 模拟抢单动作
*
* @param b
* @return
*/
private p String qiang q (String b) {
//⽤⼾开抢时间
long l startTime = System.currentTimeMillis();
//未抢到的情况下，30秒内继续获取锁
while w ((startTime + timeout) >= System.currentTimeMillis()) {
//商品是否剩余
iiff (nKuCuen <= 0) {
break b ;
}
iiff (jedisCom.setnx(shangpingKey, b)) {
//⽤⼾b拿到锁
logger.info("⽤⼾{}拿到锁...", b);
try t {
//商品是否剩余
iiff (nKuCuen <= 0) {
break b ;
}
//模拟⽣成订单耗时操作，⽅便查看：神⽜-50 多次获取锁记录
try t {
TimeUnit.SECONDS.sleep(1);
} catch c (InterruptedException e) {
e.printStackTrace();
}
//抢购成功，商品递减，记录⽤⼾
nKuCuen -= 1;
//抢单成功跳出
logger.info("⽤⼾{}抢单成功跳出...所剩库存：{}", b, nKuCuen);
return r b + "抢单成功，所剩库存：" + nKuCuen;
} finally f {
logger.info("⽤⼾{}释放锁...", b);
//释放锁
jedisCom.delnx(shangpingKey, b);
}
} else e {
//⽤⼾b没拿到锁，在超时范围内继续请求锁，不需要处理
// if (b.equals("神⽜-50") || b.equals("神⽜-69")) {
// logger.info("⽤⼾{}等待获取锁...", b);
// }
}
}
return r "";
}

这⾥实现的逻辑是： parallelStream()：并⾏流模拟多⽤⼾抢购 (startTime + timeout) >= System.currentTimeMillis()：判断未抢成功的⽤⼾，timeout秒内继续获取锁 获取锁前和后都判断库存是否还⾜够 jedisCom.setnx(shangpingKey, b)：⽤⼾获取抢购锁 获取锁后并下单成功，最后释放锁：jedisCom.delnx(shangpingKey, b) 再来看下记录的⽇志结果： 最终返回抢购成功的⽤⼾

标签：return,String,val,Spring,Redis,抢单,jedis,key,append
From： https://blog.csdn.net/qq_49018210/article/details/140456342