基于SpringBoot+Bootstrap+MySQL的高并发选课系统

person 匿名

发布日期: 2021-08-12 11:31:15 浏览量: 243
评分:
star_border star_border star_border star_border star_border star_border star_border star_border star_border star_border
*转载请注明来自write-bug.com

一、项目简介

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

二、运行效果图

登陆

首页

列表

选课

退课

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

三、技术选型

  • 前端:Bootstrap、JQuery、Thymeleaf

  • 后端:SpringBoot、Shiro、JPA、Caffeine

  • 中间件:Redis、RabbitMQ、Druid

  • 数据库:MySQL

四、优化思路

4.1 页面查看

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

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

4.1.1 公有信息

不变动

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

变动

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

  • 选修课授课计划一般是一个课程对应一个授课计划,因为是选修课,所以学校不为学生预选,需要学生自己选,所以这块并发压力大,数据变化频繁,Redis缓存一分钟

缺点

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

特有优化

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

4.1.2 私有信息

不变动

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

变动

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

特有优化

选课结果按时间降序排序,优先展示最新选的课程。

4.2 登陆

学生可能多次登陆系统,第一次登陆时将学生信息加载进Redis,减少后续登陆时对数据库的访问。

通过单例模式构建全局唯一类,根据sessionID保存学生学号,供后续使用。

4.3 选课

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

4.3.1 选课安全验证

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

    1. Integer sno = StudentIDUtils.getStudentIDFromMap();
    2. Integer count = (Integer) redisService.get("ip-", String.valueOf(sno));
    3. if (count == null) {
    4. //一分钟内可以访问三次
    5. redisService.set("ip-", String.valueOf(sno), 1, 1, TimeUnit.MINUTES);
    6. }else if (count < 3){
    7. redisService.incr("ip-"+sno, 1);
    8. }else {
    9. throw new GlobalException(CodeMsg.COUNT_OVER);
    10. }
  • 判断是否存在该课程,从Redis中查看

  • 判断是否在规定选课时限范围内,从Redis中查看

  • 若满足上述步骤,根据课程号生成其md5值,暴露秒杀地址

  • 执行选课操作时验证秒杀地址是否正确

4.3.2 执行选课操作

  • 通过本地标记判断是否有余量,若有,执行后续

  • 判断是否重选,通过查看Redis是否有对应缓存来实现

  • 判断上课时间是否冲突,构造冲突判断算法,遍历Redis中已选课程进行验证

  • 库存预减,当库存为0时,将该授课计划添加到本地缓存中,本地缓存通过Caffeine构建

    1. Long num = redisService.hdecr("forPlanCount", String.valueOf(pno), 1);
    2. if(num < 0){
    3. //没余量,写入本地缓存中
    4. caffeineCache.put(pno, true);
    5. throw new GlobalException(CodeMsg.PlAN_OVER);
    6. }
  • 选课请求压入MQ,异步执行,流量削峰,消费端消费选课信息,将结果写入数据库,结果写入数据库这一步采用事务机制,先插入结果,后减余量,减少事务期间锁持有时间,优化数据库读写性能

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

4.3.3 预加载

  1. @Service
  2. public class ChooseServiceImpl implements ChooseService, InitializingBean {
  3. @Override
  4. public void afterPropertiesSet() throws Exception {
  5. //预加载相关操作
  6. }
  7. }

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

4.3.4 超选

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

4.4 退课

  • 到Redis中查看是否存在该条选课记录

  • 删除该条选课记录,对应授课计划余量加一(事务,减少锁持有时间)

  • 修改Redis中对应数据,余量加一,删除掉该条选课记录

  • 返回退课成功标识

4.5 其他优化点

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

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

五、压力测试

  • 测试内容:选课QPS

  • 测试技术:Jmeter

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

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

  • 测试方案

  1. 利用mysql存储过程生成5000个学生学号,并将数据导出为cvs格式,供Jmeter使用
  1. delimiter //
  2. create procedure createSno ()
  3. begin
  4. declare i int;
  5. set i = 1;
  6. while i <= 5000 do
  7. insert into testData values(i);
  8. set i = i + 1;
  9. end while;
  10. end //
  11. delimiter ;
  12. call createSno();
  1. 使用Jmeter图形化界面生成测试方案,验证测试方案可行性

  1. 使用Jmeter命令行压测(图形化界面仅用来做验证,并不适合高负载压测),执行5次,查看结果
  1. jmeter -n -t [xuanke.jmx,测试文件] -l [xuanke.txt,结果输出] -e -o [/test,web输出]

压测结果说明

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

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

上传的附件 cloud_download 开发文档.pdf ( 1.68mb, 0次下载 ) cloud_download xuanke-master.zip ( 7.71mb, 0次下载 )
error_outline 下载需要13点积分
eject