开场先聊个实际场景。我自己搞过几年驾校和健身机构的软件项目排课系统这类东西乍一看不就是“把教练的时间和学员预约对上”嘛真做起来一堆细节。时间冲突、教练排班、临时调课、请假、场地占用、高峰期并发随便拎一个出来都能把你折腾够呛。这也是为什么凡是带“排课”两个字的需求报价从来都不低。这篇博文就围绕一套基于Java技术栈的教练培训排课系统源码来拆讲清楚核心表结构怎么设计、排课流程怎么走、冲突检测怎么实现、并发场景怎么防超约再带上实际调试过程中容易踩的坑。适合刚接触业务系统的Java开发、准备做驾校/健身/培训类项目的团队以及那些想看明白“排课系统到底在排什么”的产品和测试同学。1. 排课系统的业务核心排的到底是什么1.1 先理清教练培训场景下的三个核心实体排课系统听起来复杂业务模型抽出来就是三个核心实体教练、学员、课程或者说时段。这三者之间不是简单的多对多关系每一个“排课动作”实际上是在建立一条“教练在某段时间内带某个学员上课”的强约束记录。先说教练。教练有归属校区、有授课科目比如驾校里的科目二、科目三健身房的私教课、团课还有自己的工作时间段和可预约时段。这些信息不是写死的每周可能都在变。所以表设计里教练信息、教练可预约时段、教练休假记录通常要拆成多张表而不是在教练表里加一个“工作时间”字段就完了。再说学员。学员有报名的课程包、剩余课时、有效期、当前学习进度。这决定了他在某一天能不能约课、能约哪种课、能约多长时间。如果一个学员剩3节课了系统还允许他预约10节那就是严重的业务漏洞。最后是课时时段。这是整个系统的核心资源。每个时段包含开始时间、结束时间、所属课程、教练、学员、状态。注意一个时段一定不能出现两个学员同时占用同一个教练的情况这是刚性约束。基于这个核心约束才能往上叠加场地、车辆、教室等资源。我见过不少初学开发的同学一上来就画一张大表——“排课表”把所有信息塞进去结果后面做冲突检测、做统计报表的时候发现怎么都绕不过去最后只能推倒重来。正确的思路是先拆实体、再定关系、最后才谈流程。1.2 排课系统里最常见的两类冲突场景排课系统里“冲突”这个词指的是资源被重复占用。最常见的有两类时间冲突和人车/场地冲突。时间冲突很好理解。同一个教练10:00-10:45已经排了学员A的课现在又要排学员B的课时间一旦重叠直接冲突。同理学员A在同一时间段内预约了两门课也是时间冲突。代码落地的时候本质就是SQL查重叠区间start_time 新结束时间 AND end_time 新开始时间。这个公式看着简单实际排查问题的时候最容易出错因为很多人写成了“包含了等于”导致正好卡在边界上的预约被误判。人车/场地冲突稍微复杂一点。比如某驾校有10台教练车科目二的训练必须用指定车辆那排课时除了查教练是否空闲还要查车辆在那个时间段是否被占用。这里有一个常见的坑如果你在代码里把“查教练空闲”和“查车辆空闲”分成两条SQL来执行在高并发预约的瞬间两条SQL各自返回“空闲”但组合起来就撞车了。这就是典型的并发问题后面会专门讲怎么用事务和锁来解决。1.3 为什么要用Java Spring Boot这套技术栈排课系统用Java写在实际交付和面试场景里都有很现实的理由。一是Java生态对复杂业务系统的支撑足够成熟从MyBatis/MyBatis Plus的数据访问到Spring的声明式事务到Redis做分布式锁每层都有现成方案开发效率有保障二是这类系统通常要接微信小程序、App、后台管理端多个入口Java在后端API这块的稳定性和社区方案积累是经过大量生产环境验证的三是排课系统本身就是Java面试里的高频项目案例不管是数据库索引、事务隔离、并发控制还是缓存穿透都能在这套系统里找到实际的落脚点。技术栈选型上我给的是一套最稳妥的组合JDK 1.8Spring Boot 2.7.x这是目前存量项目里最普及的版本组合MyBatis Plus 做数据访问代码生成能力强联表查询也很顺手MySQL 8.0 做业务存储配合InnoDB事务Redis 做缓存和分布式锁Vue Element UI 做后台管理界面便于运营人员手动调整排课结果这套组合并不追求新奇但胜在稳定、资料多、招人好招。真要上生产环境这套方案是完全撑得住的。2. 数据库表设计一张一张拆给你看2.1 教练表、学员表的结构细节先看教练表。我见过很多人的教练表写着写着就膨胀起来恨不得把教练的身份证号、驾驶证档案编号、带教通过率全部塞进去。我的建议是教练表只放稳定的基础属性变化频繁的业务属性全部单独建表。具体来说教练表coach的核心字段包括CREATE TABLE coach ( id bigint(20) NOT NULL AUTO_INCREMENT, coach_no varchar(32) NOT NULL COMMENT 教练编号, name varchar(64) NOT NULL COMMENT 教练姓名, phone varchar(20) DEFAULT NULL COMMENT 手机号, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态1正常 0停用, hire_date date DEFAULT NULL COMMENT 入职日期, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_coach_no (coach_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT教练信息表;这里有两个容易忽略的点。第一coach_no一定要建唯一索引。教练编号在业务层是给学员查看、给教务统计用的一旦重复后面所有关联查询都会出问题。第二status字段建议用tinyint不要用varchar存“正常”“停用”。原因无他用数字做状态判断写起来干净而且加新状态时不用改表结构。学员表student的结构类似但要多加两个关键字段remain_lesson_count int(11) NOT NULL DEFAULT 0 COMMENT 剩余课时数, lesson_expire_date date DEFAULT NULL COMMENT 课时有效期这些字段的存在意味着每次成功预约课件后都要对剩余课时做扣减并且每次提交预约时要校验有效期。如果不做校验会出现学员课程包已经过期还在约课的尴尬局面。2.2 课程表与排课表一对多关系怎么建模课程表course相对简单就是定义“科目二”“科目三”“私教体验课”这类基础课程信息。但真正核心的排课表也就是schedule设计上要投入更多心思。下面是我在项目里实际用过的核心结构精简掉跟业务强相关的冗余字段CREATE TABLE schedule ( id bigint(20) NOT NULL AUTO_INCREMENT, course_id bigint(20) NOT NULL COMMENT 课程ID, coach_id bigint(20) NOT NULL COMMENT 教练ID, student_id bigint(20) DEFAULT NULL COMMENT 学员ID为空表示未预约, car_id bigint(20) DEFAULT NULL COMMENT 车辆ID如果启用车辆约束则必填, start_time datetime NOT NULL COMMENT 上课开始时间, end_time datetime NOT NULL COMMENT 上课结束时间, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态0待预约 1已预约 2已完成 3已取消 4已过期, create_by varchar(64) DEFAULT NULL COMMENT 创建人, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_coach_time (coach_id, start_time, end_time), KEY idx_student_time (student_id, start_time, end_time), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT排课表;status字段是整个表的灵魂。待预约的时段表示教练开放了这段时间但还没学员约已预约表示学员占住了已完成表示课已经上完已取消和已过期是兜底状态。很多系统把所有状态的排课记录混在一起查询时逻辑一团乱这里用状态机来管理就清晰得多。索引设计是这个表的重中之重。idx_coach_time和idx_student_time这两个联合索引直接服务于冲突检测。查询“教练X在某个时间段是否有排课”时走的就是coach_id start_time end_time这个索引。没有这两个索引数据量上到几万条以后每次排课都要全表扫系统基本就卡死了。2.3 教练可预约时段表把“开放时间”和“实际排课”分开管理这个设计是容易被忽略但非常实用的一点建议单独建一张coach_available_time表存教练每周可开放的上课时间段。CREATE TABLE coach_available_time ( id bigint(20) NOT NULL AUTO_INCREMENT, coach_id bigint(20) NOT NULL COMMENT 教练ID, week_day tinyint(4) NOT NULL COMMENT 星期几1-7, start_time time NOT NULL COMMENT 开始时间如09:00, end_time time NOT NULL COMMENT 结束时间如10:00, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_coach_week (coach_id, week_day) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT教练可预约时段表;为什么要把可预约时段单独拆出来因为实际业务里教练不是每天都能上课。周一可能全天带训周二下午要去开安全例会这就是“可预约时段”和“实际排课”分离的原因。教务人员在系统里配好了教练的周可用时段学员在App端看到的就是教练真正能约的空档系统内部再把已排的课从空档里剔除剩下的就是可预约时间。这套设计的另外一个好处是调课逻辑变得很简单。教练某天临时有事只需要删除当天的coach_available_time记录或者在那张表上加一个“是否可用”的标记学员端立刻感知不用去跟已经生成的排课记录玩“乾坤大挪移”。3. 核心功能模块的代码级实现3.1 排课主流程校验、加锁、插入三步走排课的核心动作就是生成一条新的schedule记录。但这个动作背后有非常多的前置校验课程是否存在、教练是否正常状态、学员剩余课时是否大于0、时间范围是否合法、教练在目标时间段是否空闲、学员在目标时间段是否空闲。在校验逻辑之前先要处理一个并发问题。假设两个学员同时抢同一个时间段都通过了“教练空闲”校验然后同时插入就出现了重复预约。解决方式不复杂最稳妥的办法是利用数据库层面的互斥把整段排课业务放在一个事务里对coach_available_time表里对应的记录执行SELECT ... FOR UPDATE加锁事务结束后释放锁。示例代码如下基于Spring的Transactional注解Transactional(rollbackFor Exception.class) public Long createSchedule(ScheduleCreateDTO dto) { // 1. 校验基础信息 Course course courseMapper.selectById(dto.getCourseId()); Coach coach coachMapper.selectById(dto.getCoachId()); Student student studentMapper.selectById(dto.getStudentId()); if (course null || coach null || student null) { throw new BizException(课程、教练或学员不存在); } if (student.getRemainLessonCount() 0) { throw new BizException(学员剩余课时不足); } if (student.getLessonExpireDate() ! null student.getLessonExpireDate().isBefore(LocalDate.now())) { throw new BizException(学员课时包已过期); } // 2. 锁定教练的可预约时段记录防止并发重复预约 ListCoachAvailableTime lockedTimes coachAvailableTimeMapper .lockCoachAvailableTime(dto.getCoachId(), dto.getStartTime(), dto.getEndTime()); if (CollectionUtils.isEmpty(lockedTimes)) { throw new BizException(教练在该时间段未开放预约); } // 3. 冲突检测教练维度 Integer coachConflict scheduleMapper .countConflictByCoachId(dto.getCoachId(), dto.getStartTime(), dto.getEndTime()); if (coachConflict 0) { throw new BizException(教练在当前时间段已有排课); } // 4. 冲突检测学员维度 Integer studentConflict scheduleMapper .countConflictByStudentId(dto.getStudentId(), dto.getStartTime(), dto.getEndTime()); if (studentConflict 0) { throw new BizException(学员在当前时间段已有排课); } // 5. 扣减剩余课时 studentMapper.decreaseRemainLessonCount(dto.getStudentId(), 1); // 6. 插入排课记录 Schedule schedule new Schedule(); schedule.setCourseId(dto.getCourseId()); schedule.setCoachId(dto.getCoachId()); schedule.setStudentId(dto.getStudentId()); schedule.setStartTime(dto.getStartTime()); schedule.setEndTime(dto.getEndTime()); schedule.setStatus(ScheduleStatus.BOOKED.getCode()); scheduleMapper.insert(schedule); return schedule.getId(); }这里有一点要特别强调第2步用SELECT ... FOR UPDATE锁的是coach_available_time表里的记录目的是让同时发起预约请求的多个事务在锁上串行执行。如果一个教练开放了多个可预约时段事务只会锁住目标时间范围内命中的那条记录不会影响教练在其他时段的预约并发粒度很合理。3.2 冲突检测SQL到底怎么写才不会漏冲突检测就是要查出“目标时间段”与“已存在的排课时间”是否有重叠。标准写法如下Select(SELECT COUNT(*) FROM schedule WHERE coach_id #{coachId} AND status IN (1, 2) AND start_time #{endTime} AND end_time #{startTime}) Integer countConflictByCoachId(Param(coachId) Long coachId, Param(startTime) LocalDateTime startTime, Param(endTime) LocalDateTime endTime);注意两个条件start_time #{endTime}表示已有的课开始时间早于新课的结束时间end_time #{startTime}表示已有的课结束时间晚于新课的开始时间。这俩条件同时成立说明两个时间段有交集。举个例子已有排课是 10:00-11:00新排课想插入 10:30-11:30那么10:00 11:30成立11:00 10:30也成立判定为冲突正确。已有排课是 09:00-10:00新排课是 10:00-11:00那么09:00 11:00成立但10:00 10:00不成立最终不冲突这正好符合“上一节课刚结束下一节课马上开始”的业务需求。status IN (1, 2)这个条件的用意是只把“已预约”和“已完成”的排课视为占用时间。已完成状态之所以也算占用是为了防止教练在历史排课的时间段上重复排课同时也方便统计教练的带教时长。至于“已取消”的记录它们不占用任何资源所以不参与冲突检测这也是很多初学者容易漏掉的一点如果忘了过滤状态学员取消过的课就会一直占着时间坑影响后续预约。3.3 查询某教练的可用时间段从源头上杜绝冲突做了一个简单的“生成下一周排课空档”的逻辑。这个逻辑用起来非常顺手public ListTimeSlotVO getAvailableSlots(Long coachId, LocalDate targetDate) { // 1. 取教练当天可预约时段 ListCoachAvailableTime availableTimes coachAvailableTimeMapper .selectByCoachAndWeekDay(coachId, targetDate.getDayOfWeek().getValue()); // 2. 查出当天已经预约/完成的排课 ListSchedule scheduledList scheduleMapper .selectByCoachAndDate(coachId, targetDate); ListTimeSlotVO result new ArrayList(); for (CoachAvailableTime at : availableTimes) { // 把可预约时段按已排课拆分成剩余空档 result.addAll(splitAvailableTime(at, scheduledList)); } return result; }splitAvailableTime方法的思路并不复杂把教练当天可预约的时间区间[start, end]看作一条线段把已经排出去的课看作线段上的“障碍”。从开始时间往后遍历每遇到一段没有障碍的空隙就生成一个可预约时间段。这种“线段切割”的方式比每次预约都去查全表判断“这段时间能不能约”要高效得多而且在展示给学员的界面里直接就把不可约的时间过滤掉了。4. 从源码到可运行实操部署与验证4.1 本地环境准备在动手跑源码之前先把环境准备好。JDK 1.8 或者 JDK 11 都行我自己用 JDK 1.8 跑这套代码跑得很稳。Maven 3.6 用来拉依赖、打包这里不展开 Maven 安装步骤了但建议配阿里云镜像否则首次拉取 Spring Boot 全家桶依赖会等得让人怀疑人生。数据库这块生产环境用 MySQL 8.0本地调试用 Docker 起一个 MySQL 8.0 容器就够了。注意字符集一定要指定utf8mb4否则存中文姓名或备注信息可能出现乱码这是老生常谈的问题了。Redis 在这套系统里不是必须的但如果你要跑“高并发预约”演示就必须起一个 Redis用来做分布式锁。本地用 Docker 起 Redis 很省事docker run -d --name redis-local -p 6379:6379 redis:74.2 初始化数据库与项目配置把源码里的sql/init.sql导进 MySQL里面包含表结构、基础数据和几个必要的存储过程。运行成功后确认以下几张核心表存在coach、student、course、schedule、coach_available_time。然后打开application.yml检查数据源配置spring: datasource: url: jdbc:mysql://localhost:3306/coach_schedule?useUnicodetruecharacterEncodingutf8mb4useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver启动类直接运行等控制台打印出 Spring Boot 启动成功的日志再用 Postman 打一个查询接口验证GET http://localhost:8080/api/schedule/available?coachId1date2025-03-10如果接口正常返回教练的可预约时间段列表说明项目已经跑通了接下来可以上手改业务逻辑。4.3 用Postman完整走一遍排课流程我建议新手按这个顺序逐一验证第一步查询教练可预约时段。接口返回timeSlots数组里面是某个教练在某个日期下生成的可用起止时间。 第二步调用创建排课接口。把courseId、coachId、studentId、startTime、endTime填好发起POST /api/schedule请求。正常情况下返回新排课的id。 第三步立刻查询教练在该时间段的排课列表。如果看到刚创建的记录说明插入成功。 第四步再调用一次同一个时间段的创建排课接口。这次应该被拦截下来返回“教练在当前时间段已有排课”的错误提示。 第五步把已创建的排课取消掉再重复第四步。此时请求应该能成功通过因为“已取消”的记录不再参与冲突检测。这一套流程走下来排课系统的核心链路基本就验证完整了。5. 并发、缓存与性能进阶避坑指南5.1 高并发预约下的超卖问题排课系统最容易出事故的场景就是学员同时抢教练的热门时间段。比如驾考前夕科目二的教练晚上8点开放预约几十个学员同时点“预约”按钮。如果代码里没有加锁就可能出现两个学员同时预约同一个教练同一个时间段的情况。前面已经提到了用SELECT ... FOR UPDATE解决这个问题但需要注意两个坑。第一个坑是FOR UPDATE一定要走索引。如果lockCoachAvailableTime这条SQL的WHERE条件没有命中任何索引InnoDB会锁住整张表的所有记录等于把所有教练的预约都串行化了。这在开发环境看不出问题生产环境数据量一大直接雪崩。所以查询条件里coach_id一定要用上联合索引比如(coach_id, week_day)。第二个坑是事务超时。默认的Spring事务超时时间通常足够但如果冲突检测里还包含大范围的报表统计查询事务时间可能超过数据库的innodb_lock_wait_timeout导致锁等待超时报错。建议把锁范围控制到最小冲突检测SQL只查schedule表上用得到索引的关键字段不要把无关查询塞进同一个事务。顺便说一句如果你打算用 Redis 分布式锁建议把锁的粒度设置为“教练ID 时间段”而不是“全局一把锁”。全局锁简单但会把系统吞吐量拉得非常低表现就是高峰时段预约请求排队特别久用户疯狂点按钮体验极差。5.2 缓存穿透、击穿、雪崩排课场景有哪些实际案例排课系统里最常见的性能问题有三个。第一个是缓存穿透查询一个不存在的coachId或scheduleId缓存里没有数据库里也没有请求每次都打到数据库。解决办法除了参数校验还可以把空结果也缓存起来缓存时间设置短一点比如60秒。第二个是缓存击穿。某个明星教练的时间段是“热点key”大量学员同时查询他的可预约时段缓存一旦过期所有请求瞬间打到数据库。解决办法是在“重建缓存”这块做互斥只允许一个线程去查数据库并重建缓存其他线程等待或直接返回旧缓存。第三个是缓存雪崩。大量缓存在同一时刻过期数据库压力突然飙升。解决办法是给缓存过期时间加一个随机值比如5到15分钟随机分布避免同时失效。这三个问题在Java面试里也是常客在排课系统源码里亲手调一遍比单纯背八股文有用得多。5.3 定时任务自动释放未支付的预约名额预约流程里经常有“占位但未支付”的状态。比如学员提交了预约请求但没付钱系统要给15分钟的支付等待期超时自动释放该时间段。这种功能用定时任务最合适。推荐用 Spring Boot 自带的Scheduled注解实现扫描schedule表中状态为“待支付”且创建时间早于15分钟前的记录将其状态改为“已取消”同时给学员退回课时。这里有一个细节定时任务修改状态用一条UPDATE语句加条件判断比如UPDATE schedule SET status 3 WHERE id ? AND status 0利用数据库的行锁与原子性防止刚好用户在支付时被任务误杀。如果你要处理更多复杂的定时调度比如按教练维度自动生成下一周的可用时段建议引入xxl-job这类分布式任务调度框架。不过小项目用Scheduled完全够用别过度设计。6. 这套源码在Java面试里的价值6.1 排课系统对应试八股文的实际印证排课系统是典型的“业务复杂度集中”项目特别适合用来检验Java基础。面试官问“事务失效的场景有哪些”你直接把排课里的Transactional拿来讲同类内部调用导致事务失效、rollbackFor没写异常类型、数据库表引擎不是InnoDB这些在排课系统里全都有实际对应。问“MySQL索引为什么能加速查询”你可以拿idx_coach_time联合索引举例解释最左前缀原则和作用在WHERE条件上的索引如何减少扫描行数。问“缓存穿透怎么解决”你直接把排课系统里的缓存空值方案说一遍。这些都不是死记硬背而是有真实业务背景的实战经验面试官一听就知道你是真写过代码的。6.2 从排课系统延伸出去能扩展的功能方向这套系统源码的价值不止于跑通现有功能。基于现有的表结构和业务模型可以低成本扩展出很多能力微信小程序端学员自助预约多端共用一套后端API教练端日历视图用Vue或React实现周历、月历拖拽调整排课多校区资源隔离在coach表里增加school_id字段收费与订单模块将待支付排课记录接入支付回调消息通知预约成功、开课提醒、教练临时取消时通过短信或微信模板消息触达这些扩展方向做下来一套排课系统源码就能变成完整的中型业务系统。这也是为什么我一直建议做Java项目的开发者不要只做增删改查的“管理后台”而是要挑一到两个有业务深度的系统比如排课、订单、审批流把它们彻底吃透。业务复杂度上来了技术深度自然跟着上来。7. 实际操作中遇到的几个问题与排查记录7.1 一个字符集引发的“幽灵预约”有一回我给一家健身工作室部署这套排课系统学员反馈“明明看到教练有空预约却一直失败”。排查了半天最后发现是接口传参里学员姓名带了特殊空格字符存到MySQL后被替换成了另一个不可见字符导致学员维度的冲突检测永远命中不了已有记录。这类问题只要统一在服务层做入参清洗就能规避。7.2 “刚刚取消的课又出现了”——缓存与数据库不一致处理预约取消时如果先更新了数据库但缓存里的可预约时间段没有同步删除学员端就会看到“已取消的时段仍不可约”的诡异现象。解决思路很直接在取消接口里加缓存删除操作并且给可预约时间段的缓存设置一个合理的过期时间比如5分钟即便漏删也能自动校正。7.3 定时任务重复执行导致课时重复扣减分布式部署下多个实例同时跑Scheduled定时任务会自动释放预约名额导致学员课时被重复扣除。最直接的解决办法是为定时任务加一个分布式锁用 Redis 的SETNX实现。这样做之后即使有多实例在跑同一时刻也只有一个实例能执行任务彻底解决了重复执行问题。8. 我从这套源码里学到的事做排课系统这类业务系统最核心的从来不是某个高深的技术点而是把业务规则梳理清楚然后用最合适的技术手段去落地。一张schedule表加一个时间段重叠判断就能解决教练培训里最头疼的排课冲突问题一条FOR UPDATE加上正确的事务边界就能守住并发预约的底线一套“可预约时段”与“实际排课记录”分离的设计就能让调课和改期变得异常灵活。我实际动手改这套源码时感受最深的一点是不要把业务状态散落在各种零散的字段里而是统一用status状态机去管理查询和判断都会清爽很多。另外调试并发问题时千万别靠肉眼观察日志来推理用SHOW ENGINE INNODB STATUS看锁等待记录比什么都直观。如果你正在做类似的培训、教务、预约类系统这套排课源码的设计思路和代码片段可以直接搬过去用。真踩到坑了欢迎在评论区留言一起讨论怎么优化。
