1. 项目概述：多技术栈选课系统的设计与实现
这个选课系统项目采用了Java+SSM（Spring+SpringMVC+MyBatis）和Django双技术栈的混合架构方案，实现了从课程发布、选课操作到后台管理的完整闭环。作为教育信息化领域的典型应用，系统解决了传统纸质选课流程中存在的效率低下、数据统计困难等问题，为师生提供了便捷的在线选课服务。
我在实际开发中发现，这种跨技术栈的架构设计特别适合需要同时兼顾高并发选课操作（Java处理）和灵活内容管理（Python实现）的场景。系统前端采用Bootstrap响应式布局，后端通过RESTful API进行数据交互，数据库则根据模块特性分别选用MySQL和PostgreSQL，整体架构既保证了性能又具备良好的扩展性。
2. 核心功能模块解析
2.1 用户权限管理体系
系统采用RBAC（基于角色的访问控制）模型，划分了学生、教师、教务管理员三级权限：
- 学生：查看可选课程、进行选课/退课操作、查询个人课表
- 教师：发布/管理课程信息、设置选课条件、查看选课名单
- 教务：开停课程管理、选课规则配置、系统参数设置
权限控制通过Spring Security和Django Admin的组合实现，关键代码片段：
java复制// Java端权限拦截示例
@PreAuthorize("hasRole('TEACHER')")
@PostMapping("/courses")
public ResponseEntity createCourse(@RequestBody CourseDTO dto) {
// 课程创建逻辑
}
2.2 选课核心业务流程
选课流程包含几个关键技术点：
- 选课冲突检测：基于时间窗算法的课程时间冲突判断
- 选课条件验证：前置课程、专业限制等规则的链式校验
- 名额控制：Redis分布式锁防止超选
- 事务管理：@Transactional确保选课数据一致性
Python端实现的选课条件验证逻辑：
python复制def validate_selection(student, course):
# 检查前置课程
if not set(course.prerequisites).issubset(student.completed_courses):
raise ValidationError("未完成前置课程要求")
# 检查专业限制
if course.major_restrict and student.major not in course.major_restrict:
raise ValidationError("专业不符合要求")
3. 技术架构实现细节
3.1 混合架构设计
系统采用前后端分离设计，技术栈组合方案如下表所示：
| 模块 | 技术选型 | 选用理由 |
|---|---|---|
| 选课核心业务 | Java+SSM | 高并发处理能力，事务管理完善 |
| 内容管理 | Django+DRF | 快速开发CMS功能，Admin后台强大 |
| 数据存储 | MySQL(主)+PostgreSQL | 事务型+分析型需求分离 |
| 缓存 | Redis集群 | 应对选课高峰期的瞬时流量 |
| 消息队列 | RabbitMQ | 异步处理选课结果通知等非即时任务 |
3.2 数据库关键设计
课程表的核心字段设计（MySQL）：
sql复制CREATE TABLE `course` (
`id` bigint NOT NULL AUTO_INCREMENT,
`course_code` varchar(20) NOT NULL COMMENT '课程编号',
`name` varchar(100) NOT NULL,
`credit` tinyint NOT NULL COMMENT '学分',
`max_students` int NOT NULL DEFAULT 100,
`current_students` int NOT NULL DEFAULT 0,
`teacher_id` bigint NOT NULL,
`schedule_json` json DEFAULT NULL COMMENT '排课时间安排',
`prerequisites` json DEFAULT NULL COMMENT '前置课程要求',
`major_restrict` json DEFAULT NULL COMMENT '专业限制',
PRIMARY KEY (`id`),
UNIQUE KEY `uk_code` (`course_code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
4. 高并发场景优化方案
4.1 选课峰值应对策略
在选课开放时段，系统需要应对瞬时高并发请求，我们采用了多级缓冲方案：
- 前端限流：按钮点击后禁用3秒，防止重复提交
- Nginx层限流：限制单个IP的请求频率
- 服务层队列：请求进入RabbitMQ进行削峰
- Redis原子计数器：实时统计已选人数
- 数据库最终一致性：异步更新选课结果
Java端的选课核心方法示例：
java复制public boolean selectCourse(Long studentId, Long courseId) {
// 获取分布式锁
String lockKey = "lock:course:" + courseId;
try {
boolean locked = redisTemplate.opsForValue()
.setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS);
if (!locked) {
throw new BusyException("选课人数过多，请稍后重试");
}
// 检查名额
String countKey = "course:count:" + courseId;
long remain = maxCount - redisTemplate.opsForValue().increment(countKey);
if (remain < 0) {
redisTemplate.opsForValue().decrement(countKey);
throw new FullException("课程已满员");
}
// 落库操作
return courseMapper.insertSelection(studentId, courseId) > 0;
} finally {
redisTemplate.delete(lockKey);
}
}
5. 系统部署与监控
5.1 容器化部署方案
采用Docker Compose编排服务，关键服务包括：
- Java应用：Spring Boot打包为Jar运行在OpenJDK容器中
- Django应用：Gunicorn+Gevent作为WSGI服务器
- MySQL：主从架构保证数据安全
- Redis：哨兵模式实现高可用
- Prometheus+Grafana：监控系统运行状态
docker-compose.yml部分配置：
yaml复制services:
java-app:
image: openjdk:11-jre
ports:
- "8080:8080"
volumes:
- ./java-app.jar:/app.jar
command: java -jar /app.jar
depends_on:
- redis
- mysql-master
django-app:
image: python:3.8
ports:
- "8000:8000"
volumes:
- ./django:/code
command: gunicorn --workers 4 --bind :8000 core.wsgi
5.2 监控指标设计
系统监控重点关注以下指标：
- 选课接口QPS/响应时间
- 数据库连接池使用率
- Redis内存/命中率
- JVM GC频率/耗时
- 课程名额剩余预警
6. 开发经验与避坑指南
-
跨技术栈会话共享：
- 问题：Java和Python服务需要共享用户会话
- 方案：采用JWT作为无状态token，双方实现相同的验证逻辑
- 注意：签名算法和密钥必须完全一致
-
分布式事务处理：
- 问题：选课记录与课程名额更新需要跨服务事务
- 方案：最终一致性+补偿机制（定时核对修复数据）
- 关键点：设计幂等的补偿操作接口
-
课程时间冲突检测：
- 踩坑：初期使用简单的时间段字符串比较，无法处理复杂排课
- 优化：引入joda-time库进行时间窗计算
- 示例：将"周一 1-2节"转换为时间区间对象进行比较
-
Excel导入性能：
- 问题：教务批量导入课程数据时内存溢出
- 解决：采用SAX模式解析Excel，分批次提交
- 技巧：使用Apache POI的Event API处理大文件
-
缓存雪崩预防：
- 现象：选课开始时大量缓存同时失效
- 方案：对课程数据设置随机过期时间
- 补充：本地缓存+Redis的多级缓存结构
这个项目让我深刻体会到，教育类系统的开发不仅要考虑技术实现，更需要理解教学管理的实际业务流程。比如选课规则的灵活性配置、特殊情况的处理流程等，都需要与教务部门充分沟通。在后续迭代中，我们还计划加入选课策略模拟、智能推荐等高级功能，进一步提升系统的实用价值。