本文由 简悦 SimpRead 转码， 原文地址 blog.csdn.net 如何删除锁
模拟抢单动作 (10w 个⼈开抢)
jedis 的 nx ⽣成锁
对于 java 中想操作 redis，好的⽅式是使⽤ jedis，⾸先 pom 中引⼊依赖：
redis.clients jedis
对于分布式锁的⽣成通常需要注意如下⼏个⽅⾯：
创建锁的策略：
创 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)
再来看下记录的⽇志结果：
最终返回抢购成功的⽤⼾ 