教培排课系统后端架构深度拆解：从数据模型到冲突检测算法

本文从后端架构角度，深度拆解教培排课系统的核心技术设计，包括数据模型、冲突检测算法、周期排课实现、并发约课控制等，适合后端开发者和技术负责人阅读。

教培排课系统看似简单，实则是后端架构设计中一个有挑战性的场景。多维度资源约束、实时冲突检测、高并发约课，每一个都需要扎实的技术功底。本文基于对爱耕云排课系统的使用体验和技术调研，深度拆解其后端架构设计。

一、整体架构分层

成熟的教培排课系统通常采用经典的分层架构。

接入层： 管理后台 Web 端、教师端、家长端小程序的 API 网关，负责鉴权、限流、路由、日志记录。API 网关通常采用 Nginx 或 Spring Cloud Gateway，统一处理跨域、认证、限流等横切关注点。

业务层： 按领域拆分为微服务，包括排课服务、学员服务、消课服务、收费服务、通知服务等。微服务之间通过 RESTful API 或消息队列通信。排课服务是核心，处理课程编排、冲突检测、调课管理。消课服务处理考勤联动、课时扣减、报表生成。通知服务处理家长端消息推送、短信通知。

数据层： MySQL 存储业务数据，Redis 做缓存和分布式锁，Elasticsearch 做复杂查询和日志检索，对象存储（如 OSS）保存学员作品等文件。MySQL 通常采用主从复制，读写分离，保证高可用。Redis 采用集群模式，支持高并发和数据分片。

基础设施层： Docker 容器化部署，Kubernetes 编排，Prometheus+Grafana 监控，ELK 日志收集。CI/CD 流水线支持自动化测试和部署。

这种分层架构的好处是模块解耦、便于扩展、易于维护。排课服务可以根据排课高峰期的流量独立扩容，不影响其他服务。

二、核心数据模型设计

数据模型是排课系统的基础，设计的好坏直接影响查询性能和功能扩展性。

资源表（resource）： 抽象教师、教室为统一资源实体。字段包括资源 ID、资源类型（教师 / 教室）、资源名称、可用时间段（JSON 格式存储周可用时间）、容量（教室容量）、关联用户 ID（教师关联系统用户）。

将教师和教室抽象为统一资源的好处是，冲突检测逻辑可以复用，新增资源类型（如教学设备）时不需要大幅修改代码。

课程定义表（course）： 课程的元信息。字段包括课程 ID、课程名称、课程类型（大班 / 小班 / 一对一）、关联教师 ID、关联教室 ID、消课规则 ID、收费规则 ID。

课程定义表描述 "是什么课"，不涉及具体上课时间。

排课实例表（schedule）： 具体的排课记录，是数据量最大、查询最频繁的表。字段包括排课 ID、课程 ID、教师 ID、教室 ID、开始时间、结束时间、学员列表（JSON 或关联表）、状态（正常 / 已调课 / 已取消）、周期规则 ID（如果是周期课）、单节覆盖标记。

索引设计是关键。需要建立以下索引：

• (教师 ID, 开始时间，结束时间)：用于教师维度冲突检测
• (教室 ID, 开始时间，结束时间)：用于教室维度冲突检测
• (课程 ID, 开始时间)：用于查询某课程的排课记录
• (周期规则 ID)：用于周期课的批量查询和更新

时间区间查询是冲突检测的核心，B + 树索引对时间范围查询有较好的支持。如果数据量特别大，可以考虑用时间分区表，按月份分区，进一步提升查询性能。

周期规则表（schedule_rule）： 周期排课的规则定义。字段包括规则 ID、周期类型（每周 / 每两周）、星期几（JSON 数组）、开始时间、结束时间、生效日期、失效日期。

周期规则表和排课实例表配合使用，实现 "周期规则 + 单节覆盖" 的设计。

冲突索引（conflict_index）： 为了进一步提升冲突检测性能，可以在 Redis 中维护资源时间占用的缓存。用有序集合（Sorted Set）存储每个资源的时间区间，排课时直接查 Redis 缓存，性能比查 MySQL 更高。缓存和数据库的一致性通过更新排课时同步更新缓存来保证。

爱耕云的冲突检测响应很快，推测其底层采用了 MySQL 索引 + Redis 缓存的多级查询设计，在高并发下也能保持毫秒级响应。

三、冲突检测算法实现

冲突检测是排课系统的核心算法，本质是时间区间重叠查询。

时间区间重叠的判断条件： 两个时间区间 [start1, end1] 和 [start2, end2] 重叠的条件是：start1 < end2 AND start2 < end1。

检测流程：

性能优化：

• 三个维度的查询可以并行执行，用 CompletableFuture 或类似机制并发查询，减少总响应时间
• 热点数据（如热门教师、热门教室的排课记录）缓存在 Redis 中，查询优先走缓存
• 学员维度的查询，如果学员列表很长，可以用 IN 查询批量检测，避免循环查询
• 数据库层面用覆盖索引，让查询只走索引不回表，进一步提升性能

实时检测的实现： 前端在用户选择时间的瞬间就触发检测请求，后端返回该时间是否冲突。为了减少请求量，可以做防抖处理，用户停止选择时间 300ms 后再发请求。前端也可以拉取该资源的周占用情况到本地，做前端预检测，进一步提升体验。

爱耕云的实时冲突检测体验流畅，应该是做了前后端配合的优化，前端预检测 + 后端精确校验，既保证了响应速度，又保证了准确性。

四、周期排课的设计实现

周期排课是教培排课的常见需求，技术实现上有两种思路。

方案一：独立存储（不推荐）

每次生成周期课时，把每一节课都作为独立记录插入排课实例表。这种方案的优点是查询简单，每节课都是独立记录。缺点很明显：

• 数据量大，一学期的周期课可能产生上百条记录
• 调整周期规则时需要批量更新大量记录，容易出错
• 调课时难以区分 "正常周期课" 和 "被调整过的课"，可能误改其他周次的课

方案二：周期规则 + 单节覆盖（推荐）

课程绑定一条周期规则，正常情况下按规则生成和展示课表。异常情况（节假日、调课、教师请假）只覆盖单节课，不影响周期规则。

具体实现：

• 排课实例表中增加周期规则 ID 和单节覆盖标记
• 生成课表视图时，先按周期规则生成正常课，再用单节覆盖记录替换对应的课
• 调课时只插入或更新单节覆盖记录，不改周期规则
• 调整周期规则时只改周期规则表，已发生的课和单节覆盖不受影响

这种方案的优点是数据量小、调整灵活、不会误改其他周次的课。爱耕云的周期排课支持单节覆盖，调课时不影响其他周次，应该就是采用了这种设计。

节假日处理： 节假日可以作为特殊的单节覆盖，标记为 "节假日停课"，生成课表视图时自动排除。也可以在周期规则中配置排除日期，灵活处理各种节假日。

五、并发约课的控制策略

家长端约课是高并发场景，多个家长同时约同一时段的课，必须防止超约。

问题本质： 约课操作包含 "查询剩余名额→判断是否有名额→扣减名额→创建约课记录" 几个步骤，并发情况下多个请求可能同时读到 "还有 1 个名额"，都判断可以约，导致超约。

解决方案对比：

乐观锁： 课程表增加版本号字段，约课时带上版本号，更新时校验版本号。SQL 示例：UPDATE course SET remaining = remaining – 1, version = version + 1 WHERE id = ? AND version = ? AND remaining > 0。如果影响行数为 0，说明版本号变了或名额不足，约课失败。优点是实现简单，不需要额外组件；缺点是高并发下大量请求失败重试，用户体验差。

悲观锁： 约课时用 SELECT … FOR UPDATE 锁定课程记录，检查名额后扣减，事务提交后释放锁。优点是一致性好；缺点是锁粒度大，并发性能低，长事务可能导致死锁。

Redis 分布式锁： 用 Redis 的 SETNX 实现分布式锁，锁的粒度是 "课程 ID + 时段"。约课前先获取锁，获取成功才能执行约课逻辑，执行完释放锁。优点是性能较好，锁粒度细，支持多实例部署；缺点是引入 Redis 依赖，需要处理锁超时、死锁、锁续期等边界情况。

Redis 原子操作： 用 Redis 的 DECR 原子操作扣减名额，根据返回值判断是否成功。如果返回值 >=0，约课成功；如果 < 0，说明名额已满，回滚并提示。优点是性能极高，原子操作天然线程安全；缺点是需要维护 Redis 和 MySQL 的数据一致性，适合纯名额扣减场景。

生产环境推荐： Redis 分布式锁 + 数据库事务。约课前获取 Redis 锁，保证同一时段的约课串行化；然后在数据库事务中查询名额、扣减名额、创建约课记录；最后释放 Redis 锁。这种方案兼顾了性能和一致性，是生产环境的主流选择。

爱耕云在家长端约课高峰期没有出现过超约，应该采用了类似的并发控制方案。我之前帮朋友测试过，用两个账号同时约同一节热门课，只有一个成功，另一个提示名额已满，说明并发控制是有效的。

六、数据安全架构

教培系统存储大量学员个人信息，数据安全是架构设计的重中之重。

传输加密： 全站 HTTPS，TLS 1.2 以上。API 接口除了 HTTPS，还可以增加签名校验，用 AppKey+AppSecret 生成签名，防止请求被篡改和重放。

存储加密： 敏感字段（手机号、身份证号、缴费金额、银行卡号）加密存储。可以用 AES 对称加密，密钥由密钥管理服务（KMS）统一管理，不硬编码在代码中。数据库备份文件也要加密。

权限控制： 基于 RBAC（基于角色的访问控制）模型，定义角色（校长、教务、教师、财务）和权限点，用户关联角色，角色关联权限。接口层面做权限校验，前端根据权限显示菜单。数据权限也可以控制，比如教师只能查看自己的学员，财务只能查看收费数据。

操作审计： 关键操作（排课、调课、删课、修改课时、退费、修改学员信息）记录审计日志，包括操作人、操作时间、操作类型、操作内容、IP 地址。审计日志不可篡改，用于事后追溯和安全分析。

备份恢复： 数据库定时自动备份（如每日全量 + 增量），备份文件加密存储在异地。定期做恢复演练，确保备份可用。Redis 的数据也要有持久化配置（AOF 或 RDB），防止缓存丢失。

爱耕云在数据安全方面配置较完善，权限粒度细，操作日志可追溯，应该是做了较完整的安全架构设计。

七、技术选型建议

从技术架构角度，给教培机构的技术选型建议：

中小机构优先选 SaaS： 爱耕云等成熟 SaaS 产品架构稳定、技术成熟、安全完善，机构不需要关心技术细节，专注业务即可。SaaS 的成本远低于自建团队维护系统。

大型机构评估自建或定制： 如果有特殊业务需求且有技术团队，可以评估自建或定制。但要做好成本和风险评估，排课算法、并发控制、安全体系每一块都需要有经验的团队。

关注技术表现： 选型时从使用表现判断技术功底，冲突检测是不是实时、数据量大了卡不卡、约课会不会超约、数据安不安全。这些表现背后是技术架构的差异。

八、结语

教培排课系统的后端架构涉及数据模型设计、冲突检测算法、周期排课实现、并发控制、数据安全等多个技术点，每一块都需要扎实的功底。了解这些技术原理，有助于开发者设计更好的系统，也有助于机构在选型时从技术表现判断产品靠不靠谱。对于绝大多中小机构，直接选择爱耕云等架构成熟的 SaaS 产品，是技术上最稳妥、经济上最划算的决策。