共计 5651 个字符，预计需要花费 15 分钟才能阅读完成。
本篇内容次要解说的是 redis 分布式锁，这个在各大厂面试简直都是必备的，上面联合模仿抢单的场景来应用她；本篇不波及到的 redis 环境搭建，疾速搭建集体测试环境，这里倡议应用 docker；本篇内容节点如下：
Jedis 的 nx 生成锁
- 如何删除锁
- 模仿抢单动作(10w 集体开抢)
- jedis 的 nx 生成锁
对于 java 中想操作 redis，好的形式是应用 jedis，首先 pom 中引入依赖：
| <dependency> | |
| <groupId>redis.clients</groupId> | |
| <artifactId>jedis</artifactId> | |
| </dependency> |
对于分布式锁的生成通常须要留神如下几个方面：
Spring Boot 根底就不介绍了，举荐下这个实战教程：https://github.com/javastacks…
创立锁的策略： redis 的一般 key 个别都容许笼罩，A 用户 set 某个 key 后，B 在 set 雷同的 key 时同样能胜利，如果是锁场景，那就无奈晓得到底是哪个用户 set 胜利的；这里 jedis 的 setnx 形式为咱们解决了这个问题，简略原理是：当 A 用户先 set 胜利了，那 B 用户 set 的时候就返回失败，满足了某个工夫点只容许一个用户拿到锁。
锁过期工夫： 某个抢购场景时候，如果没有过期的概念，当 A 用户生成了锁，然而前面的流程被阻塞了始终无奈开释锁，那其余用户此时获取锁就会始终失败，无奈实现抢购的流动；当然失常状况个别都不会阻塞，A 用户流程会失常开释锁；过期工夫只是为了更有保障。
上面来上段 setnx 操作的代码：
| public boolean setnx(String key, String val) { | |
| Jedis jedis = null; | |
| try {jedis = jedisPool.getResource(); | |
| if (jedis == null) {return false;} | |
| return jedis.set(key, val, "NX", "PX", 1000 * 60). | |
| equalsIgnoreCase("ok"); | |
| } catch (Exception ex) { } finally {if (jedis != null) {jedis.close(); | |
| } | |
| } | |
| return 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 jedisCom.setnx(key, val); | |
| } |
拜访如下测试 url，失常来说第一次返回了 true，第二次返回了 false，因为第二次申请的时候 redis 的 key 已存在，所以无奈 set 胜利。
由上图可能看到只有一次 set 胜利，并 key 具备一个无效工夫，此时已达到了分布式锁的条件。
如何删除锁
下面是创立锁，同样的具备无效工夫，然而咱们不能齐全依赖这个无效工夫，场景如：无效工夫设置 1 分钟，自身用户 A 获取锁后，没遇到什么非凡状况失常生成了抢购订单后，此时其余用户应该能失常下单了才对，然而因为有个 1 分钟后锁能力主动开释，那其余用户在这 1 分钟无奈失常下单（因为锁还是 A 用户的），因而咱们须要 A 用户操作完后，被动去解锁：
| public int delnx(String key, String val) { | |
| Jedis jedis = null; | |
| try {jedis = jedisPool.getResource(); | |
| if (jedis == null) {return 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 Integer.valueOf(jedis.eval(sbScript.toString()).toString()); | |
| } catch (Exception ex) { } finally {if (jedis != null) {jedis.close(); | |
| } | |
| } | |
| return 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 jedisCom.delnx(key, val); | |
| } |
留神的是 delnx 时，须要传递创立锁时的 value，因为通过 et 的 value 与 delnx 的 value 来判断是否是持有锁的操作申请，只有 value 一样才容许 del；
模仿抢单动作（10w 集体开抢）
有了上面对分布式锁的粗略根底，咱们模仿下 10w 人抢单的场景，其实就是一个并发操作申请而已，因为环境无限，只能如此测试；如下初始化 10w 个用户，并初始化库存，商品等信息，如下代码：
| // 总库存 | |
| private long nKuCuen = 0; | |
| // 商品 key 名字 | |
| private String shangpingKey = "computer_key"; | |
| // 获取锁的超时工夫 秒 | |
| private int timeout = 30 * 1000; | |
| @GetMapping("/qiangdan") | |
| public List<String> qiangdan() { | |
| // 抢到商品的用户 | |
| List<String> shopUsers = new ArrayList<>(); | |
| // 结构很多用户 | |
| List<String> users = new ArrayList<>(); | |
| IntStream.range(0, 100000).parallel().forEach(b -> {users.add("神牛 -" + b); | |
| }); | |
| // 初始化库存 | |
| nKuCuen = 10; | |
| // 模仿开抢 | |
| users.parallelStream().forEach(b -> {String shopUser = qiang(b); | |
| if (!StringUtils.isEmpty(shopUser)) {shopUsers.add(shopUser); | |
| } | |
| }); | |
| return shopUsers; | |
| } |
有了下面 10w 个不同用户，咱们设定商品只有 10 个库存，而后通过并行流的形式来模仿抢购，如下抢购的实现：
| /** | |
| * 模仿抢单动作 | |
| * | |
| * @param b | |
| * @return | |
| */ | |
| private String qiang(String b) { | |
| // 用户开抢工夫 | |
| long startTime = System.currentTimeMillis(); | |
| // 未抢到的状况下，30 秒内持续获取锁 | |
| while ((startTime + timeout) >= System.currentTimeMillis()) { | |
| // 商品是否残余 | |
| if (nKuCuen <= 0) {break;} | |
| if (jedisCom.setnx(shangpingKey, b)) { | |
| // 用户 b 拿到锁 | |
| logger.info("用户 {} 拿到锁...", b); | |
| try { | |
| // 商品是否残余 | |
| if (nKuCuen <= 0) {break;} | |
| // 模仿生成订单耗时操作，不便查看：神牛 -50 屡次获取锁记录 | |
| try {TimeUnit.SECONDS.sleep(1); | |
| } catch (InterruptedException e) {e.printStackTrace(); | |
| } | |
| // 抢购胜利，商品递加，记录用户 | |
| nKuCuen -= 1; | |
| // 抢单胜利跳出 | |
| logger.info("用户 {} 抢单胜利跳出... 所剩库存：{}", b, nKuCuen); | |
| return b + "抢单胜利，所剩库存：" + nKuCuen; | |
| } finally {logger.info("用户 {} 开释锁...", b); | |
| // 开释锁 | |
| jedisCom.delnx(shangpingKey, b); | |
| } | |
| } else { | |
| // 用户 b 没拿到锁，在超时范畴内持续申请锁，不须要解决 | |
| // if (b.equals("神牛 -50") || b.equals("神牛 -69")) {// logger.info("用户 {} 期待获取锁...", b); | |
| // } | |
| } | |
| } | |
| return ""; | |
| } |
这里实现的逻辑是：
1、parallelStream()：并行流模仿多用户抢购
2、(startTime + timeout) >= System.currentTimeMillis()：判断未抢胜利的用户，timeout 秒内持续获取锁
3、获取锁前和后都判断库存是否还足够
4、jedisCom.setnx(shangpingKey, b)：用户获取抢购锁
5、获取锁后并下单胜利，最初开释锁：jedisCom.delnx(shangpingKey, b)
再来看下记录的日志后果：
最终返回抢购胜利的用户：
— End —
