学生抢课接口(高并发入门)

最新推荐文章于 2024-07-22 19:55:23 发布

原创

最新推荐文章于 2024-07-22 19:55:23 发布 · 2.1k 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#java #测试工具 #高并发 #新手

使用Mysql

常规测试

原始代码:

@Override
@Transactional
public ResponseResult selectCourse(SelectParmas selectParmas) {
    if (Objects.isNull(selectParmas)){
        return new ResponseResult(500,"传入参数有误!");
    }
    //1. 检查课程限选人数是否已经超标
    Course course = courseMapper.findByNo(selectParmas.getCno()+"");
    //1.1 获取当前可选人数
    int limitSelects = course.getLimitSelects();
    //1.2 检查可选人数是否已经<1
    if (limitSelects<1){
        return new ResponseResult(500,"本课人数已满!");
    }
    //2. 检查是否有重复选课
    //2.1 查询当前用户是否已经选了这门课
    int isSelect = studentCourseMapper.findByUnoAndCno(selectParmas);
    if (isSelect >0){
        return new ResponseResult(500,"不能重复选课哦");
    }
    //3. 扣减课程表可选人数
    //3.1 乐观锁扣减可选数
    int cnt = courseMapper.subSelects(course.getCno());
    if (cnt<1){
        //说明扣减失败，直接返回
        return new ResponseResult(500,"本课人数已满!");
    }
    //4. 插入选课信息表(传入用户id和课程的id)
    studentCourseMapper.insert(selectParmas);
    return new ResponseResult(200,"选课成功!");
}

以上代码，使用了乐观锁防止课程表可选人数出现超抢的情况

下面模拟1000个线程(用户)同时抢同一门课时，会出现的情况。

生成了1000个登录用户：

tokens文件生成也成功了

postman使用一个用户测试一下看看：

多点几下试试看

postman测试通过，现在用jmeter做压测:

1000个线程，1秒钟发起请求

设置请求体参数，选课id为1 用户为传进来的no（读取文件）

请求头,token 设置为传进来的token（读取文件）

开始测试

每个请求的平均值(ms)干到了2841
查看一下数据库

我又测试了几次，发现结果没有问题。说明以上代码(乐观锁)确实可以防止高并发情况下，出现超出限制人数的抢课情况。

张三测试

但是，凡是都有例外！

设想一下，假如某位比较坏的学生(张三)，觉得自己懂一点技术很厉害，使用脚本去抢课，那么会出现啥情况。

这里我使用jmeter，用同一个用户并且模拟1000个线程去发起抢课。

结果:

张三这小子！居然一个人就抢占了10个名额！

回头看代码，找找问题。

@Override
@Transactional
public ResponseResult selectCourse(SelectParmas selectParmas) {
    ......

        //XXXXXXXXXXXXX问题XXXXXXXXXXXXXX
        //2. 检查是否有重复选课
        //2.1 查询当前用户是否已经选了这门课
        int isSelect = studentCourseMapper.findByUnoAndCno(selectParmas);
    if (isSelect >0){
        return new ResponseResult(500,"不能重复选课哦");
    }
    //XXXXXXXXXXXXX问题XXXXXXXXXXXXXX
    //3. 扣减课程表可选人数
    //3.1 乐观锁扣减可选数
    int cnt = courseMapper.subSelects(course.getCno());
    if (cnt<1){
        //说明扣减失败，直接返回
        return new ResponseResult(500,"本课人数已满!");
    }
    //4. 插入选课信息表(传入用户id和课程的id)
    studentCourseMapper.insert(selectParmas);
    return new ResponseResult(200,"选课成功!");
}

观察代码可以发现，在检查是否有重复选课这里，其实存在问题的。

一般的学生确实不会出现问题，但是遇上张三这样的学生就遭殃了。因为多个线程同时进来，假如线程A和线程B同时查询到此时选课表里面isSelect为0，那么他们就会同时往下执行，这样就出现了一人多选的情况。

解决：

从查询是否重复选课，到最后的插入选课表这里需要加锁。
这里我为了方便使用了synchornized锁，但是使用synchornized需要考虑一些问题：
- 问题1：锁的对象是谁？如果把后面的代码封装为一个方法，加锁加在方法体上面，那么锁住的是this，这样显然会大大降低服务的性能，因为锁的范围太大了。将锁的范围缩小，锁住当前用户即可。也就是锁住一个字符串对象，这个字符串对象可以拼接当前用户的id，以此来缩小锁的范围提升服务的性能。
- 问题2：为什么要把后面这一段业务代码封装为一个方法，直接锁住代码段不行吗？答案是不行，因为我们需要考虑事务。事务的提交是在锁释放之后才提交的，也就是到最后return出去才会提交，但是如果锁释放了，事务没来得及提交，此时其他线程冲进来一顿操作，就破坏了我们前一次事务了。所以必须把后面的一段业务封装起来，将Transactional注解加在它的头上
- 问题3：事务加在它的头上，此时还能用this来调用吗？不行，如果此时使用this调用，那么事务就会失效，所以我们要用代理对象来调用它。
- 问题4：使用了synchornized，假如服务器做集群部署(水平拓展) 锁是会失效的。因为synchornized锁住了同一台JVM的监视器，如果做了水平拓展，还是可能出现同一用户同时持有多把锁的现象。解决的办法:后面可以改用redisson分布式锁来代替它，但是现在先用synchornized就行。
考虑完以上的一些问题，接下来就改写代码。