乐趣区

关于java:SpringBootRedis抗住-10w-人秒杀抢单

本篇内容次要解说的是 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 —

退出移动版