本项目主要解决在高校选课场景下,保证选课系统在大量读写压力下不宕机,以及选课时尽可能提高选课QPS,给学生一个良好的选课体验,完成上述功能同时保证选课安全

其他效果图请到image文件夹中查看

前端:Bootstrap、JQuery、Thymeleaf

后端:SpringBoot、Shiro、JPA、Caffeine

中间件:Redis、RabbitMQ、Druid

数据库:MySQL

解决思路:从Redis缓存中查看数据,减少数据库访问

从数据可见性角度来讲,分为对所有人可见的公有信息,和只有自己可见的私有信息

不变动: 必修课课程表中的数据是不变动,一般展现的是该专业学生本学期所必选的的课程信息,这类信息不发生变动,缓存到Redis中,缓存时间为一天

变动:

1. 必修课课程一般对应好几个授课计划,以高数来讲,这个课可能会对应好几个授课教师以及好几个时段的授课计划,但这类必修课授课计划学校一般会为学生预选,只有少部分学生因不满意授课时段或授课老师会去退课并重新选课,所以这类数据变动频率小,Redis缓存一分钟
2. 选修课授课计划一般是一个课程对应一个授课计划,因为是选修课,所以学校不为学生预选,需要学生自己选,所以这块并发压力大,数据变化频繁,Redis缓存一分钟

缺点: 学生看到的课程余量存在延迟,可能已经选完了,但列表上还显示有课,因此会在学生第一次进入选课页面提醒学生数据有延迟

特有优化: 数据库在加载授课计划信息时,只会加载有余量的课程

不变动: 考试查询和成绩查询,这类数据不会发生变动,学生看个几次就不会再看了,Redis缓存30分钟

变动: 选课结果,在选课初期学生可能频繁查看选课结果,Redis缓存30分钟

特有优化: 选课结果按时间降序排序,优先展示最新选的课程

1. 学生可能多次登陆系统,第一次登陆时将学生信息加载进Redis,减少后续登陆时对数据库的访问
2. 通过单例模式构建全局唯一类,根据sessionID保存学生学号,供后续使用

此功能为整个系统的重点优化之处, 主要分为两大步骤,选课安全验证和执行选课操作

1. IP限流,每分钟可以访问三次,与学号绑定,通过Redis实现

Integer sno = StudentIDUtils.getStudentIDFromMap();
 Integer count = (Integer) redisService.get("ip-", String.valueOf(sno));
 if (count == null) {
 //一分钟内可以访问三次
 redisService.set("ip-", String.valueOf(sno), 1, 1, TimeUnit.MINUTES);
 }else if (count < 3){
 redisService.incr("ip-"+sno, 1);
 }else {
 throw new GlobalException(CodeMsg.COUNT_OVER);
 }

2. 判断是否存在该课程,从Redis中查看
3. 判断是否在规定选课时限范围内,从Redis中查看
4. 若满足上述步骤,根据课程号生成其md5值,暴露秒杀地址
5. 执行选课操作时验证秒杀地址是否正确

1. 通过本地标记判断是否有余量,若有,执行后续
2. 判断是否重选,通过查看Redis是否有对应缓存来实现
3. 判断上课时间是否冲突,构造冲突判断算法,遍历Redis中已选课程进行验证
4. 库存预减,当库存为0时,将该授课计划添加到本地缓存中,本地缓存通过Caffeine构建

Long num = redisService.hdecr("forPlanCount", String.valueOf(pno), 1);
// LOGGER.info("redis中读取pno={} 的授课计划余量为{}", pno, num);
 if(num < 0){
 //没余量,写入本地缓存中
 caffeineCache.put(pno, true);
 throw new GlobalException(CodeMsg.PlAN_OVER);
 }

5. 选课请求压入MQ,异步执行,流量削峰,消费端消费选课信息,将结果写入数据库,结果写入数据库这一步采用事务机制,先插入结果,后减余量,减少事务期间锁持有时间,优化数据库读写性能

6. 返回执行成功标识,但结果需要到选课查询页面确认

@Service
public class ChooseServiceImpl implements ChooseService, InitializingBean {
 @Override
 public void afterPropertiesSet() throws Exception {
 //预加载相关操作
 }
}

通过上述代码所示,Spring在生成Bean初期,会将选课所需要的相关数据加载到Redis中

//选课
 @Modifying
 @Query("update PlanEntity p set p.num = p.num-1 where p.pno =?1 and p.num > 0")
 Integer reduceNumByPno(Integer pno);

1. 到Redis中查看是否存在该条选课记录
2. 删除该条选课记录,对应授课计划余量加一(事务,减少锁持有时间)
3. 修改Redis中对应数据,余量加一,删除掉该条选课记录
4. 返回退课成功标识

安全相关: 存储在数据库中的密码和选课链接都经过了MD5加密,对应MD5值的生成经过了两次加盐

数据库操作: 引入Druid数据库连接池,提升对数据库的操作性能

测试内容:选课QPS

测试技术:Jmeter

测试环境:MacBook Pro2018,JDK1.8,Jmeter 5.3

测试计划:理想状态下(余量充足,不存在重复选课,上课时间不冲突等),同时执行5000个线程(模仿5000个同学),选同一节课,看选课执行情况

测试方案:

1. 利用mysql存储过程生成5000个学生学号,并将数据导出为cvs格式,供Jmeter使用

delimiter //
create procedure createSno ()
begin
 declare i int;
 set i = 1;
 while i <= 5000 do
 insert into testData values(i);
 set i = i + 1;
 end while;
end //
delimiter ;
call createSno();

2. 使用Jmeter图形化界面生成测试方案,验证测试方案可行性

3. 使用Jmeter命令行压测(图形化界面仅用来做验证,并不适合高负载压测),执行5次,查看结果

jmeter -n -t [xuanke.jmx,测试文件] -l [xuanke.txt,结果输出] -e -o [/test,web输出]

多次压测后得出来的平均选课qps为500出头,读页面的平均选课qps为900多

备注:为了简化测试,测试时修改了部分代码,主要是去除url校验和写死pno