简介这套基于Java语言构建的在线教育平台设计源码面向具备一定Java基础的后端开发者、毕业设计或课程设计学生帮助理解在线教育系统的模块划分与工程结构。资源压缩包共二十一个文件约三十八KB涵盖十个XML配置文件、七个Java源文件、两个Git忽略文件、一个属性配置文件及一个说明文档XML负责数据库连接与应用配置Java文件实现登录验证、课程管理、在线测试等核心功能属性文件存储运行参数整体结构精简、层次清晰。当前已有三百五十四人学习适合需要快速参考在线教育平台分层设计与Spring整合思路的读者。通过阅读源码可掌握配置文件与业务代码的关联了解多线程并发在课程推送、考试评分等场景中的应用并借助Gitignore规范版本管理习惯为独立开发或二次开发提供直接可用的起点。1. 基于Java语言的在线教育平台设计源码到底该先看哪里拿到一套在线教育平台的Java源码很多人的第一反应是赶紧启动起来跑一个课程列表看看长什么样。但真正让这套源码值钱的不是启动速度而是它的模块边界、数据模型和并发处理方式。在线教育平台的业务链路不算复杂但远比普通的CRUD工程要长从注册登录、课程浏览、视频点播到下单支付、学习进度上报中间任何一环的写法和异常处理都能看出设计者对高并发和一致性问题的理解程度。适合谁来看这套源码准备Java面试的开发者可以从认证、缓存、幂等这些高频考点里提炼回答框架后端工程师想接手类似项目可以照着它的分层和表结构少走弯路即便只做单体应用也能从它的模块划分里找到可复用的边界。要理解这套源码先抓住三个问题它怎么分层、核心表怎么设计、高并发节点做了哪些防护。2. 在线教育平台的工程结构与技术选型先看懂源码的骨架2.1 用Maven多模块划分源码common包和framework包不能混在一个工程里在线教育平台的Java源码通常不会把全部类放在一个工程里而是按照Maven多模块拆分。常见的做法是拆成四个模块edu-common存放通用工具类与统一返回结果edu-framework放配置类和框架整合代码edu-module-system放后台管理接口edu-module-api对小程序和App端提供接口。这样拆的核心原因是依赖方向要尽量单向业务模块依赖frameworkframework依赖common避免出现两个业务模块互相引用的泥潭。这里需要理解一个关键点源码里最容易被忽视的edu-common模块才是整个项目的稳定性底座。统一返回对象ResultT、全局异常处理器、分页参数封装、JWT工具类、Redis工具类都应该放这里而不是散落在各个业务模块里。如果看到一个在线教育项目把这些东西写在某个service包里说明它的模块边界还没有理清。同时common模块不应该依赖任何Spring Boot的Web层注解否则工具类会被迫带上Web环境。模块名职责范围依赖关系edu-common统一返回、异常码、工具类、JWT、常量无Spring依赖edu-frameworkSecurity配置、MyBatis-Plus配置、Redis配置、OSS配置edu-commonedu-module-system后台课程管理、用户管理、订单管理edu-frameworkedu-module-api小程序/H5端接口、登录、课程列表、观看、购买edu-framework这个划分策略在源代码阅读时很容易验证如果一个类的import只涉及自己的模块和framework层说明分层是健康的。如果出现了两个业务模块互相import那这个模块划分就退化为逻辑分包失去多模块的意义。2.2 Spring Boot版本和核心依赖配齐MyBatis-Plus比JPA更适合业务快速迭代在线教育平台源码的技术栈通常锁定在Spring Boot上版本选择直接影响后续维护成本。当前比较稳妥的组合是JDK 8配合Spring Boot 2.7.xJDK 17可以往上走Spring Boot 3.x但要注意3.x版本里javax包名换成了jakarta部分老代码需要做替换。ORM层大多选择MyBatis-Plus而不是Spring Data JPA理由很实际在线教育平台的查询条件动态变化多课程名称、分类、价格区间、上架状态经常组合过滤MyBatis-Plus的LambdaQueryWrapper可以直接拼条件不需要为每个查询写Query方法。下面是一份典型的pom.xml关键依赖清单覆盖了在线教育平台的核心中间件dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdcom.aliyun.oss/groupId artifactIdaliyun-sdk-oss/artifactId version3.15.2/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-amqp/artifactId /dependency版本参数方面有三个点要说明。第一MyBatis-Plus 3.5.x要求MyBatis版本不低于3.5.x它自带分页插件PaginationInnerInterceptor代码里只需要配置一个MybatisPlusInterceptor的Bean。第二jjwt依赖被拆成了api、impl、jackson三个artifact只引api会运行时报NoClassDefFoundError必须把impl也加上。第三Redis依赖要指定spring-boot-starter-data-redis不要直接引jedis或lettuce-core否则Spring Boot的自动配置不会生效RedisTemplate无法直接注入。2.3 核心表设计要覆盖课程、订单、学习记录三条数据链在线教育平台的数据库设计是整套源码的落脚点表结构不清晰service层写出花也没有用。核心表至少要有五张课程表course、课程章节表course_section、订单表orders、学习记录表study_record、用户表user。如果用MySQL 8.x建议统一使用utf8mb4字符集和InnoDB引擎主键用BIGINT自增即可。课程表的简洁实例CREATE TABLE course ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 课程ID, title VARCHAR(128) NOT NULL COMMENT 课程标题, cover_url VARCHAR(255) DEFAULT NULL COMMENT 封面图, price DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 课程价格, category_id BIGINT DEFAULT NULL COMMENT 分类ID, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未上架 1已上架, deleted TINYINT NOT NULL DEFAULT 0 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_category_status (category_id, status), KEY idx_title (title) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT课程表;这个表围绕业务链的过滤条件做了索引设计。idx_category_status覆盖了前台按分类上架状态查询的常见场景idx_title在有后台搜索需求时起到作用。deleted字段配合MyBatis-Plus的逻辑删除注解TableLogic使用业务查询不需要手动拼WHERE deleted0。需要特别注意的是逻辑删除字段不能加唯一索引比如课程表如果对title做了唯一约束逻辑删除会造成历史数据重新上架时主键冲突这一点在源码里很容易踩坑。订单表要把status设为TINYINT并预留状态机空间例如0待支付、1已支付、2已取消、3退款中不要用字符串存状态否则后续状态统计和索引效率都会受影响。3. 用户登录与课程浏览模块的源码实现JWT令牌和Redis缓存一起用3.1 Spring Security整合JWT做无状态登录token放Redis里踢人下线在线教育平台面向小程序、H5和App三类端登录态不能依赖于传统Session因为Session是黏在服务器上的多实例部署时要么做Session共享要么引入更麻烦的粘滞会话。Java源码里最常见的做法是用JWT做无状态令牌再用Redis保存用户信息来做主动失效控制。这其实是Java面试八股文里常考的“Session和Token区别”的真实业务落点JWT本身无法主动过期必须依靠Redis里的黑名单或会话版本来踢人。JWT工具类里最核心的是生成与解析两个方法。生成时把用户ID和角色放进claims里解析时只依赖密钥验签。密钥要放在配置文件的jwt.secret里且长度不能低于32字节否则mac算法会报长度不足的异常。public String generateToken(Long userId, String role) { long now System.currentTimeMillis(); long expire now jwtProperties.getExpire() * 1000L; return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setIssuedAt(new Date(now)) .setExpiration(new Date(expire)) .signWith(Keys.hmacShaKeyFor(jwtProperties.getSecret().getBytes(StandardCharsets.UTF_8)), SignatureAlgorithm.HS256) .compact(); }signWith方法需要传入Key对象不能直接传字符串密钥否则旧版jjwt会警告格式问题。setExpiration和setIssuedAt这两个时间戳不要省略因为很多网关层的过滤器会直接读取过期时间做提前续期判断。登录认证过滤器是第二个关键类。它继承OncePerRequestFilter从Authorization头中截取Bearer开头的字符串解析并校验签名。如果Redis中存有login:token:{userId}且值与当前token不一致说明用户在别处登录这里应直接返回401让前端重新跳转登录页。3.2 课程列表和详情接口的缓存策略穿透和击穿都要考虑课程浏览是并发量最高的接口之一。一门热门课程在上架推广期间详情接口可能被刷到每秒上千次请求如果每次都打到MySQL数据库压力会非常大。源码里的处理方式通常是两级缓存先用Redis缓存课程详情再在本地进程里加一层Caffeine冷热数据分层处理。对于中小规模的在线教育平台先做好Redis这一层就够了。查询课程详情的核心代码如下public CourseVO getCourseDetail(Long courseId) { String key course:detail: courseId; String cache redisTemplate.opsForValue().get(key); if (StringUtils.isNotBlank(cache)) { return JSON.parseObject(cache, CourseVO.class); } Course course courseMapper.selectById(courseId); if (course null) { // 空值缓存防止缓存穿透 redisTemplate.opsForValue().set(key, , 1, TimeUnit.MINUTES); return null; } CourseVO vo convertToVO(course); redisTemplate.opsForValue().set(key, JSON.toJSONString(vo), 30, TimeUnit.MINUTES); return vo; }这里的缓存处理考虑了两种情况。第一是避免了缓存穿透当数据库查不到课程时仍然向Redis写入一个空字符串并设置极短的过期时间避免恶意用不存在的课程ID打穿后端。第二是缓存击穿的规避如果热点课程刚好在某一刻失效大量请求会同时回源到MySQL通常还需要用分布式锁做单飞。不过对于源码学习阶段先把空值缓存和过期时间设置好已经能规避绝大多数问题。course:detail:前缀统一了key的命名空间后续如果要清理某分类下的所有课程缓存可以按前缀扫描Redis中尽量不要用KEYS course:detail:*这种命令量大时会造成堵塞。3.3 视频点播URL签名与学习进度上报接口设计课程详情页的播放器不会直接拿一个永久地址去播放因为视频文件通常存在OSS或云点播服务上永久地址会带来盗链问题。在线教育平台源码里的通用做法是后端生成临时签名URL过期时间设置在30到60分钟之间。生成签名URL的核心逻辑public String generateVodUrl(String videoKey, long expireSeconds) { Date expiration new Date(System.currentTimeMillis() expireSeconds * 1000L); URL url ossClient.generatePresignedUrl(bucketName, videoKey, expiration); // 生成后拼接鉴权参数供播放器直接拉流 return url.toString(); }这段代码有两个参数要注意。expireSeconds是URL的有效时长太短会导致用户看一半视频重新拉流太长又会增加被盗用的风险一般半小时起步比较合适。ossClient的初始化要放在配置类里不能每次请求都新建客户端因为每创建一个OSSClient都会建立独立的HTTP连接池线上会直接表现为连接数打满。学习进度上报接口则要处理一个高频问题播放器每隔十几秒上报一次进度一个用户连续观看两个小时会产生几百条写请求。源码里常见的方案是先用Redis做增量累加再定时落库。用户每次上报时把观看秒数INCRBY到study:progress:{userId}:{courseId}这个key上超过60秒再同步到MySQL。这样既兼顾了实时性又减少了数据库写放大。4. 下单与支付模块的并发处理幂等、分布式锁与MQ异步补偿4.1 创建订单的幂等机制用token模式防止重复提交在线教育平台的用户下单流程里最常见的并发问题是用户在课程详情页重复点击“立即购买”按钮导致前端连续发送多次下单请求。如果后端不做幂等控制会生成多笔重复订单。源码里最成熟的做法是后端预发一个幂等token下单时携带并在后端校验校验通过后立即删除保证一个token只能使用一次。幂等token的获取与校验可以放在一个切面里PostMapping(/order/create) public ResultLong createOrder(RequestBody CreateOrderRequest request) { // 直接从Redis中删除token利用setnx机制保证只有一个请求成功 Boolean success redisTemplate.opsForValue() .setIfAbsent(order:idempotent: request.getIdempotentToken(), 1, 10, TimeUnit.MINUTES); if (Boolean.FALSE.equals(success)) { return Result.fail(请勿重复提交); } // 执行业务逻辑 return Result.success(orderService.createOrder(request)); }setIfAbsent是关键它是Redis的SETNX命令多个并发请求同时到达时只有第一个能设置成功其余全部返回false。这个方案比“先查再删”的检查方式更稳妥因为查询和删除之间存在时间窗口并发下会漏。token本身的过期时间设为10分钟覆盖用户从点击购买到完成支付的全流程时间太短会出现用户填写完信息提交时报错的情况。还有一点值得注意幂等token只解决了“重复提交生成多个订单”的问题没有解决支付回调重复通知的问题。支付平台的回调接口天然会重试所以回调处理的幂等要在下面单独处理。4.2 扣减库存与锁的选型setnx、Redisson和数据库乐观锁怎么用在线教育平台的“库存”概念和秒杀系统不太一样课程通常是虚拟商品库存上下限很大但会有“限量发售”的营销场景。源码里实现限量课程扣库存时用UPDATE course SET stock stock - 1 WHERE id ? AND stock 0是最高效的做法数据库层面的行锁天然保证原子性但对于追求极致吞吐量的场景会在Service层再加一层分布式锁来拦截请求。RLock lock redissonClient.getLock(course:lock: courseId); boolean tryLock lock.tryLock(3, 30, TimeUnit.SECONDS); if (!tryLock) { return Result.fail(系统繁忙请重试); } try { int count courseMapper.deductStock(courseId); if (count 0) { return Result.fail(课程已售罄); } } finally { lock.unlock(); }tryLock(3, 30, TimeUnit.SECONDS)的三个参数依次是等待时间、锁持有时间、时间单位。等待时间设为3秒表示拿不到锁的请求最多阻塞3秒后返回失败锁持有时间设为30秒要考虑业务最长执行时间设置太短会在业务未完成时提前释放锁设置太长又会在宕机时出现锁无法自动释放的问题Redisson虽然提供了看门狗自动续期但显式设置leaseTime后门狗会自动失效。这里用Redisson而不是SETNX手写分布式锁主要是考虑到可重入性和看门狗机制手写锁无法解决重入问题在线程等待都完成前就可能出现死锁。4.3 支付回调与RabbitMQ异步补偿重复消费必须做幂等支付回调是整个在线教育平台里对数据一致性要求最高的环节。用户成功支付后支付平台发起回调后端需要更新订单状态、开通课程权限、记录支付流水。这三个操作如果直接串行执行回调接口会一直被慢操作占用大量重复回调时可能超时。源码里的标准做法是回调接口只负责验签和改状态然后把“开通课程权限”这个耗时操作丢进MQ异步完成。消费者侧要处理的核心问题是重复消费。RabbitMQ在没有手动ACK且消费失败的情况下消息会不断重新投递。因此消费端首先要做记录判重RabbitListener(queues queue.course.open) public void onCourseOpen(OrderMessage message) { // 使用Redis setnx做消费幂等已处理过的消息直接跳过 Boolean first redisTemplate.opsForValue() .setIfAbsent(course:open: message.getOrderId(), 1, 24, TimeUnit.HOURS); if (Boolean.FALSE.equals(first)) { return; } userCourseMapper.insert(new UserCourse(message.getUserId(), message.getCourseId())); // 手动ACK channel.basicAck(deliveryTag, false); }处理逻辑里用Redis的setIfAbsent来标记消息已经消费过key的过期时间设为24小时覆盖支付回调的重试周期。万一消费者处理完消息后、设置标记之前宕机会存在极小的重复执行窗口但userCourse表可以在设计上增加(user_id, course_id)唯一索引来兜底。这层幂等设计就是支付回调安全的核心少做一步都会在线上出现用户付费后课程权限迟迟不到账的客诉。5. 在线教育平台的部署配置与源码排错环境变量到MyBatis的坑逐个清5.1 用Maven profile做多环境打包把数据库地址和Redis密码从源码里抽走在线教育平台的源码里最危险的一件事就是把开发环境的数据库密码直接提交到Git仓库。正确做法是用Maven的profile区分dev、test、prod三套环境每套环境只维护自己的配置文件打包时通过参数指定激活哪一套。application.yml里的占位符写法如下spring: datasource: url: jdbc:mysql://${db.host}:${db.port}/${db.name}?useUnicodetruecharacterEncodingutf8 username: ${db.username} password: ${db.password}然后创建三份配置文件application-dev.yml、application-test.yml、application-prod.yml分别填充各自的数据库地址、Redis密码和OSS的Bucket名称。打包时执行mvn clean package -DskipTests -Pprod-Pprod参数会激活prod的Maven profileSpring Boot的spring.profiles.active也会被同步设置为prod。这里需要理解一个容易混淆的点Maven的profile决定的是构建阶段用哪个application-{profile}.yml参与打包而Spring Boot启动时读取的是资源目录下的配置。因此pom.xml里需要配置resources插件的resource数组把对应环境下的配置文件过滤进target/classes。5.2 Java环境变量配置与启动失败的排查顺序拿到源码后第一个坎往往是本地环境变量没有配对。在线教育平台的源码依赖JDK和MavenJAVA_HOME和MAVEN_HOME不配好mvn命令直接报command not found或者提示JAVA_HOME is not set。在Windows上通常需要在系统变量中新增JAVA_HOME指向JDK安装根目录再在Path中追加%JAVA_HOME%\binLinux上则在~/.bashrc或/etc/profile里写入export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64和export MAVEN_HOME/opt/maven。启动失败时建议按下表顺序排查错误现象可能原因排查手段Web server failed to start端口被占用lsof -i:8080或netstat -anoAccess denied for user root数据库密码错误或权限不足先用Navicat等客户端直连验证ERR Client sent AUTH, but no password is setRedis密码未设置但配置里填了修改spring.redis.password为空串Failed to configure a DataSource数据源相关配置缺失检查application.yml的url和驱动类实际项目中,Failed to configure a DataSource是最容易误导人的报错它未必是数据库不可达更多时候是配置文件里数据源参数没读取到。优先检查pom.xml里是否引入了spring-boot-starter-jdbc以及资源文件是否被打包进了classpath。5.3 MyBatis-Plus自动填充与逻辑删除的隐蔽坑在线教育平台源码用MyBatis-Plus后会引入两个常见问题理解了这两个问题在面试中也能讲出“源码为什么这样设计”的层次。第一个是create_time和update_time的自动填充。很多源码里表设计用了DEFAULT CURRENT_TIMESTAMP这只能在插入时生效如果业务代码里更新了status字段update_time不会自动变化导致后台排查问题时看不到记录的最新修改时间。MyBatis-Plus里要自定义MetaObjectHandler实现类在insertFill和updateFill中显式赋值。Component public class MyMetaObjectHandler implements MetaObjectHandler { Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, createTime, LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } }这里的strictInsertFill和strictUpdateFill只有在实体字段为null时才会生效因此实体类的createTime和updateTime都不要在代码中手动赋值。第二个坑是逻辑删除字段与唯一索引的冲突例如user_course表为了防重复开通给course_id和user_id加上唯一索引但deleted做逻辑删除后同一用户退课再购课时新记录会因唯一索引冲突无法插入。源码设计上通常通过业务层先查询所有记录包括已删除的判断唯一约束字段是否已存在再决定是更新原记录还是新增记录。6. 性能验证与源码级调优技巧用Arthas定位慢接口6.1 用Arthas trace命令定位在线教育接口的热点方法课程详情接口慢、下单接口偶尔超时这类问题不能靠猜。Arthas是排查Java应用线上问题的常用工具进入目录后执行java -jar arthas-boot.jar再选择正在运行的进程号即可接入。定位慢方法用trace命令trace com.edu.service.impl.CourseServiceImpl getCourseDetail该命令执行后接下来每次调用CourseServiceImpl#getCourseDetail时终端都会输出方法内部各个子调用的耗时明细。输出的时间单位是毫秒重点关注redisTemplate.opsForValue().get和courseMapper.selectById两行的耗时占比。如果Redis耗时普遍超过10毫秒说明可能是大key或频繁序列化如果selectById较慢则优先排查数据库索引是否命中。这个思路和Java环境变量配置的问题域完全不同但恰好是源码调优中需要具备的底层手段。6.2 缓存击穿与幂等控制的最终自测清单性能调优的终点不是看代码而是做一轮可重复的验证。针对在线教育平台最核心的三个场景可以直接用下面的清单来确认源码设计是否合格。用JMeter或wrk同时发起200个并发请求访问同一个不存在的课程ID观察后端数据库连接池的活跃连接数若没有空值缓存连接数会瞬间打满单发请求校验下单接口连续提交两次确认第二次被拦截且数据库中只有一条订单记录模拟分布式多实例部署后同时调用扣库存接口确认总扣减数不超过库存上限。这三个验证依次对应缓存穿透、接口幂等、分布式锁的正确性全部通过后这套源码才算真正达到上线标准。本文还有配套的精品资源点击获取
在线教育平台Java源码深度解析：高并发与模块化设计
简介这套基于Java语言构建的在线教育平台设计源码面向具备一定Java基础的后端开发者、毕业设计或课程设计学生帮助理解在线教育系统的模块划分与工程结构。资源压缩包共二十一个文件约三十八KB涵盖十个XML配置文件、七个Java源文件、两个Git忽略文件、一个属性配置文件及一个说明文档XML负责数据库连接与应用配置Java文件实现登录验证、课程管理、在线测试等核心功能属性文件存储运行参数整体结构精简、层次清晰。当前已有三百五十四人学习适合需要快速参考在线教育平台分层设计与Spring整合思路的读者。通过阅读源码可掌握配置文件与业务代码的关联了解多线程并发在课程推送、考试评分等场景中的应用并借助Gitignore规范版本管理习惯为独立开发或二次开发提供直接可用的起点。1. 基于Java语言的在线教育平台设计源码到底该先看哪里拿到一套在线教育平台的Java源码很多人的第一反应是赶紧启动起来跑一个课程列表看看长什么样。但真正让这套源码值钱的不是启动速度而是它的模块边界、数据模型和并发处理方式。在线教育平台的业务链路不算复杂但远比普通的CRUD工程要长从注册登录、课程浏览、视频点播到下单支付、学习进度上报中间任何一环的写法和异常处理都能看出设计者对高并发和一致性问题的理解程度。适合谁来看这套源码准备Java面试的开发者可以从认证、缓存、幂等这些高频考点里提炼回答框架后端工程师想接手类似项目可以照着它的分层和表结构少走弯路即便只做单体应用也能从它的模块划分里找到可复用的边界。要理解这套源码先抓住三个问题它怎么分层、核心表怎么设计、高并发节点做了哪些防护。2. 在线教育平台的工程结构与技术选型先看懂源码的骨架2.1 用Maven多模块划分源码common包和framework包不能混在一个工程里在线教育平台的Java源码通常不会把全部类放在一个工程里而是按照Maven多模块拆分。常见的做法是拆成四个模块edu-common存放通用工具类与统一返回结果edu-framework放配置类和框架整合代码edu-module-system放后台管理接口edu-module-api对小程序和App端提供接口。这样拆的核心原因是依赖方向要尽量单向业务模块依赖frameworkframework依赖common避免出现两个业务模块互相引用的泥潭。这里需要理解一个关键点源码里最容易被忽视的edu-common模块才是整个项目的稳定性底座。统一返回对象ResultT、全局异常处理器、分页参数封装、JWT工具类、Redis工具类都应该放这里而不是散落在各个业务模块里。如果看到一个在线教育项目把这些东西写在某个service包里说明它的模块边界还没有理清。同时common模块不应该依赖任何Spring Boot的Web层注解否则工具类会被迫带上Web环境。模块名职责范围依赖关系edu-common统一返回、异常码、工具类、JWT、常量无Spring依赖edu-frameworkSecurity配置、MyBatis-Plus配置、Redis配置、OSS配置edu-commonedu-module-system后台课程管理、用户管理、订单管理edu-frameworkedu-module-api小程序/H5端接口、登录、课程列表、观看、购买edu-framework这个划分策略在源代码阅读时很容易验证如果一个类的import只涉及自己的模块和framework层说明分层是健康的。如果出现了两个业务模块互相import那这个模块划分就退化为逻辑分包失去多模块的意义。2.2 Spring Boot版本和核心依赖配齐MyBatis-Plus比JPA更适合业务快速迭代在线教育平台源码的技术栈通常锁定在Spring Boot上版本选择直接影响后续维护成本。当前比较稳妥的组合是JDK 8配合Spring Boot 2.7.xJDK 17可以往上走Spring Boot 3.x但要注意3.x版本里javax包名换成了jakarta部分老代码需要做替换。ORM层大多选择MyBatis-Plus而不是Spring Data JPA理由很实际在线教育平台的查询条件动态变化多课程名称、分类、价格区间、上架状态经常组合过滤MyBatis-Plus的LambdaQueryWrapper可以直接拼条件不需要为每个查询写Query方法。下面是一份典型的pom.xml关键依赖清单覆盖了在线教育平台的核心中间件dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdcom.aliyun.oss/groupId artifactIdaliyun-sdk-oss/artifactId version3.15.2/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-amqp/artifactId /dependency版本参数方面有三个点要说明。第一MyBatis-Plus 3.5.x要求MyBatis版本不低于3.5.x它自带分页插件PaginationInnerInterceptor代码里只需要配置一个MybatisPlusInterceptor的Bean。第二jjwt依赖被拆成了api、impl、jackson三个artifact只引api会运行时报NoClassDefFoundError必须把impl也加上。第三Redis依赖要指定spring-boot-starter-data-redis不要直接引jedis或lettuce-core否则Spring Boot的自动配置不会生效RedisTemplate无法直接注入。2.3 核心表设计要覆盖课程、订单、学习记录三条数据链在线教育平台的数据库设计是整套源码的落脚点表结构不清晰service层写出花也没有用。核心表至少要有五张课程表course、课程章节表course_section、订单表orders、学习记录表study_record、用户表user。如果用MySQL 8.x建议统一使用utf8mb4字符集和InnoDB引擎主键用BIGINT自增即可。课程表的简洁实例CREATE TABLE course ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 课程ID, title VARCHAR(128) NOT NULL COMMENT 课程标题, cover_url VARCHAR(255) DEFAULT NULL COMMENT 封面图, price DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 课程价格, category_id BIGINT DEFAULT NULL COMMENT 分类ID, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未上架 1已上架, deleted TINYINT NOT NULL DEFAULT 0 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_category_status (category_id, status), KEY idx_title (title) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT课程表;这个表围绕业务链的过滤条件做了索引设计。idx_category_status覆盖了前台按分类上架状态查询的常见场景idx_title在有后台搜索需求时起到作用。deleted字段配合MyBatis-Plus的逻辑删除注解TableLogic使用业务查询不需要手动拼WHERE deleted0。需要特别注意的是逻辑删除字段不能加唯一索引比如课程表如果对title做了唯一约束逻辑删除会造成历史数据重新上架时主键冲突这一点在源码里很容易踩坑。订单表要把status设为TINYINT并预留状态机空间例如0待支付、1已支付、2已取消、3退款中不要用字符串存状态否则后续状态统计和索引效率都会受影响。3. 用户登录与课程浏览模块的源码实现JWT令牌和Redis缓存一起用3.1 Spring Security整合JWT做无状态登录token放Redis里踢人下线在线教育平台面向小程序、H5和App三类端登录态不能依赖于传统Session因为Session是黏在服务器上的多实例部署时要么做Session共享要么引入更麻烦的粘滞会话。Java源码里最常见的做法是用JWT做无状态令牌再用Redis保存用户信息来做主动失效控制。这其实是Java面试八股文里常考的“Session和Token区别”的真实业务落点JWT本身无法主动过期必须依靠Redis里的黑名单或会话版本来踢人。JWT工具类里最核心的是生成与解析两个方法。生成时把用户ID和角色放进claims里解析时只依赖密钥验签。密钥要放在配置文件的jwt.secret里且长度不能低于32字节否则mac算法会报长度不足的异常。public String generateToken(Long userId, String role) { long now System.currentTimeMillis(); long expire now jwtProperties.getExpire() * 1000L; return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setIssuedAt(new Date(now)) .setExpiration(new Date(expire)) .signWith(Keys.hmacShaKeyFor(jwtProperties.getSecret().getBytes(StandardCharsets.UTF_8)), SignatureAlgorithm.HS256) .compact(); }signWith方法需要传入Key对象不能直接传字符串密钥否则旧版jjwt会警告格式问题。setExpiration和setIssuedAt这两个时间戳不要省略因为很多网关层的过滤器会直接读取过期时间做提前续期判断。登录认证过滤器是第二个关键类。它继承OncePerRequestFilter从Authorization头中截取Bearer开头的字符串解析并校验签名。如果Redis中存有login:token:{userId}且值与当前token不一致说明用户在别处登录这里应直接返回401让前端重新跳转登录页。3.2 课程列表和详情接口的缓存策略穿透和击穿都要考虑课程浏览是并发量最高的接口之一。一门热门课程在上架推广期间详情接口可能被刷到每秒上千次请求如果每次都打到MySQL数据库压力会非常大。源码里的处理方式通常是两级缓存先用Redis缓存课程详情再在本地进程里加一层Caffeine冷热数据分层处理。对于中小规模的在线教育平台先做好Redis这一层就够了。查询课程详情的核心代码如下public CourseVO getCourseDetail(Long courseId) { String key course:detail: courseId; String cache redisTemplate.opsForValue().get(key); if (StringUtils.isNotBlank(cache)) { return JSON.parseObject(cache, CourseVO.class); } Course course courseMapper.selectById(courseId); if (course null) { // 空值缓存防止缓存穿透 redisTemplate.opsForValue().set(key, , 1, TimeUnit.MINUTES); return null; } CourseVO vo convertToVO(course); redisTemplate.opsForValue().set(key, JSON.toJSONString(vo), 30, TimeUnit.MINUTES); return vo; }这里的缓存处理考虑了两种情况。第一是避免了缓存穿透当数据库查不到课程时仍然向Redis写入一个空字符串并设置极短的过期时间避免恶意用不存在的课程ID打穿后端。第二是缓存击穿的规避如果热点课程刚好在某一刻失效大量请求会同时回源到MySQL通常还需要用分布式锁做单飞。不过对于源码学习阶段先把空值缓存和过期时间设置好已经能规避绝大多数问题。course:detail:前缀统一了key的命名空间后续如果要清理某分类下的所有课程缓存可以按前缀扫描Redis中尽量不要用KEYS course:detail:*这种命令量大时会造成堵塞。3.3 视频点播URL签名与学习进度上报接口设计课程详情页的播放器不会直接拿一个永久地址去播放因为视频文件通常存在OSS或云点播服务上永久地址会带来盗链问题。在线教育平台源码里的通用做法是后端生成临时签名URL过期时间设置在30到60分钟之间。生成签名URL的核心逻辑public String generateVodUrl(String videoKey, long expireSeconds) { Date expiration new Date(System.currentTimeMillis() expireSeconds * 1000L); URL url ossClient.generatePresignedUrl(bucketName, videoKey, expiration); // 生成后拼接鉴权参数供播放器直接拉流 return url.toString(); }这段代码有两个参数要注意。expireSeconds是URL的有效时长太短会导致用户看一半视频重新拉流太长又会增加被盗用的风险一般半小时起步比较合适。ossClient的初始化要放在配置类里不能每次请求都新建客户端因为每创建一个OSSClient都会建立独立的HTTP连接池线上会直接表现为连接数打满。学习进度上报接口则要处理一个高频问题播放器每隔十几秒上报一次进度一个用户连续观看两个小时会产生几百条写请求。源码里常见的方案是先用Redis做增量累加再定时落库。用户每次上报时把观看秒数INCRBY到study:progress:{userId}:{courseId}这个key上超过60秒再同步到MySQL。这样既兼顾了实时性又减少了数据库写放大。4. 下单与支付模块的并发处理幂等、分布式锁与MQ异步补偿4.1 创建订单的幂等机制用token模式防止重复提交在线教育平台的用户下单流程里最常见的并发问题是用户在课程详情页重复点击“立即购买”按钮导致前端连续发送多次下单请求。如果后端不做幂等控制会生成多笔重复订单。源码里最成熟的做法是后端预发一个幂等token下单时携带并在后端校验校验通过后立即删除保证一个token只能使用一次。幂等token的获取与校验可以放在一个切面里PostMapping(/order/create) public ResultLong createOrder(RequestBody CreateOrderRequest request) { // 直接从Redis中删除token利用setnx机制保证只有一个请求成功 Boolean success redisTemplate.opsForValue() .setIfAbsent(order:idempotent: request.getIdempotentToken(), 1, 10, TimeUnit.MINUTES); if (Boolean.FALSE.equals(success)) { return Result.fail(请勿重复提交); } // 执行业务逻辑 return Result.success(orderService.createOrder(request)); }setIfAbsent是关键它是Redis的SETNX命令多个并发请求同时到达时只有第一个能设置成功其余全部返回false。这个方案比“先查再删”的检查方式更稳妥因为查询和删除之间存在时间窗口并发下会漏。token本身的过期时间设为10分钟覆盖用户从点击购买到完成支付的全流程时间太短会出现用户填写完信息提交时报错的情况。还有一点值得注意幂等token只解决了“重复提交生成多个订单”的问题没有解决支付回调重复通知的问题。支付平台的回调接口天然会重试所以回调处理的幂等要在下面单独处理。4.2 扣减库存与锁的选型setnx、Redisson和数据库乐观锁怎么用在线教育平台的“库存”概念和秒杀系统不太一样课程通常是虚拟商品库存上下限很大但会有“限量发售”的营销场景。源码里实现限量课程扣库存时用UPDATE course SET stock stock - 1 WHERE id ? AND stock 0是最高效的做法数据库层面的行锁天然保证原子性但对于追求极致吞吐量的场景会在Service层再加一层分布式锁来拦截请求。RLock lock redissonClient.getLock(course:lock: courseId); boolean tryLock lock.tryLock(3, 30, TimeUnit.SECONDS); if (!tryLock) { return Result.fail(系统繁忙请重试); } try { int count courseMapper.deductStock(courseId); if (count 0) { return Result.fail(课程已售罄); } } finally { lock.unlock(); }tryLock(3, 30, TimeUnit.SECONDS)的三个参数依次是等待时间、锁持有时间、时间单位。等待时间设为3秒表示拿不到锁的请求最多阻塞3秒后返回失败锁持有时间设为30秒要考虑业务最长执行时间设置太短会在业务未完成时提前释放锁设置太长又会在宕机时出现锁无法自动释放的问题Redisson虽然提供了看门狗自动续期但显式设置leaseTime后门狗会自动失效。这里用Redisson而不是SETNX手写分布式锁主要是考虑到可重入性和看门狗机制手写锁无法解决重入问题在线程等待都完成前就可能出现死锁。4.3 支付回调与RabbitMQ异步补偿重复消费必须做幂等支付回调是整个在线教育平台里对数据一致性要求最高的环节。用户成功支付后支付平台发起回调后端需要更新订单状态、开通课程权限、记录支付流水。这三个操作如果直接串行执行回调接口会一直被慢操作占用大量重复回调时可能超时。源码里的标准做法是回调接口只负责验签和改状态然后把“开通课程权限”这个耗时操作丢进MQ异步完成。消费者侧要处理的核心问题是重复消费。RabbitMQ在没有手动ACK且消费失败的情况下消息会不断重新投递。因此消费端首先要做记录判重RabbitListener(queues queue.course.open) public void onCourseOpen(OrderMessage message) { // 使用Redis setnx做消费幂等已处理过的消息直接跳过 Boolean first redisTemplate.opsForValue() .setIfAbsent(course:open: message.getOrderId(), 1, 24, TimeUnit.HOURS); if (Boolean.FALSE.equals(first)) { return; } userCourseMapper.insert(new UserCourse(message.getUserId(), message.getCourseId())); // 手动ACK channel.basicAck(deliveryTag, false); }处理逻辑里用Redis的setIfAbsent来标记消息已经消费过key的过期时间设为24小时覆盖支付回调的重试周期。万一消费者处理完消息后、设置标记之前宕机会存在极小的重复执行窗口但userCourse表可以在设计上增加(user_id, course_id)唯一索引来兜底。这层幂等设计就是支付回调安全的核心少做一步都会在线上出现用户付费后课程权限迟迟不到账的客诉。5. 在线教育平台的部署配置与源码排错环境变量到MyBatis的坑逐个清5.1 用Maven profile做多环境打包把数据库地址和Redis密码从源码里抽走在线教育平台的源码里最危险的一件事就是把开发环境的数据库密码直接提交到Git仓库。正确做法是用Maven的profile区分dev、test、prod三套环境每套环境只维护自己的配置文件打包时通过参数指定激活哪一套。application.yml里的占位符写法如下spring: datasource: url: jdbc:mysql://${db.host}:${db.port}/${db.name}?useUnicodetruecharacterEncodingutf8 username: ${db.username} password: ${db.password}然后创建三份配置文件application-dev.yml、application-test.yml、application-prod.yml分别填充各自的数据库地址、Redis密码和OSS的Bucket名称。打包时执行mvn clean package -DskipTests -Pprod-Pprod参数会激活prod的Maven profileSpring Boot的spring.profiles.active也会被同步设置为prod。这里需要理解一个容易混淆的点Maven的profile决定的是构建阶段用哪个application-{profile}.yml参与打包而Spring Boot启动时读取的是资源目录下的配置。因此pom.xml里需要配置resources插件的resource数组把对应环境下的配置文件过滤进target/classes。5.2 Java环境变量配置与启动失败的排查顺序拿到源码后第一个坎往往是本地环境变量没有配对。在线教育平台的源码依赖JDK和MavenJAVA_HOME和MAVEN_HOME不配好mvn命令直接报command not found或者提示JAVA_HOME is not set。在Windows上通常需要在系统变量中新增JAVA_HOME指向JDK安装根目录再在Path中追加%JAVA_HOME%\binLinux上则在~/.bashrc或/etc/profile里写入export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64和export MAVEN_HOME/opt/maven。启动失败时建议按下表顺序排查错误现象可能原因排查手段Web server failed to start端口被占用lsof -i:8080或netstat -anoAccess denied for user root数据库密码错误或权限不足先用Navicat等客户端直连验证ERR Client sent AUTH, but no password is setRedis密码未设置但配置里填了修改spring.redis.password为空串Failed to configure a DataSource数据源相关配置缺失检查application.yml的url和驱动类实际项目中,Failed to configure a DataSource是最容易误导人的报错它未必是数据库不可达更多时候是配置文件里数据源参数没读取到。优先检查pom.xml里是否引入了spring-boot-starter-jdbc以及资源文件是否被打包进了classpath。5.3 MyBatis-Plus自动填充与逻辑删除的隐蔽坑在线教育平台源码用MyBatis-Plus后会引入两个常见问题理解了这两个问题在面试中也能讲出“源码为什么这样设计”的层次。第一个是create_time和update_time的自动填充。很多源码里表设计用了DEFAULT CURRENT_TIMESTAMP这只能在插入时生效如果业务代码里更新了status字段update_time不会自动变化导致后台排查问题时看不到记录的最新修改时间。MyBatis-Plus里要自定义MetaObjectHandler实现类在insertFill和updateFill中显式赋值。Component public class MyMetaObjectHandler implements MetaObjectHandler { Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, createTime, LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } }这里的strictInsertFill和strictUpdateFill只有在实体字段为null时才会生效因此实体类的createTime和updateTime都不要在代码中手动赋值。第二个坑是逻辑删除字段与唯一索引的冲突例如user_course表为了防重复开通给course_id和user_id加上唯一索引但deleted做逻辑删除后同一用户退课再购课时新记录会因唯一索引冲突无法插入。源码设计上通常通过业务层先查询所有记录包括已删除的判断唯一约束字段是否已存在再决定是更新原记录还是新增记录。6. 性能验证与源码级调优技巧用Arthas定位慢接口6.1 用Arthas trace命令定位在线教育接口的热点方法课程详情接口慢、下单接口偶尔超时这类问题不能靠猜。Arthas是排查Java应用线上问题的常用工具进入目录后执行java -jar arthas-boot.jar再选择正在运行的进程号即可接入。定位慢方法用trace命令trace com.edu.service.impl.CourseServiceImpl getCourseDetail该命令执行后接下来每次调用CourseServiceImpl#getCourseDetail时终端都会输出方法内部各个子调用的耗时明细。输出的时间单位是毫秒重点关注redisTemplate.opsForValue().get和courseMapper.selectById两行的耗时占比。如果Redis耗时普遍超过10毫秒说明可能是大key或频繁序列化如果selectById较慢则优先排查数据库索引是否命中。这个思路和Java环境变量配置的问题域完全不同但恰好是源码调优中需要具备的底层手段。6.2 缓存击穿与幂等控制的最终自测清单性能调优的终点不是看代码而是做一轮可重复的验证。针对在线教育平台最核心的三个场景可以直接用下面的清单来确认源码设计是否合格。用JMeter或wrk同时发起200个并发请求访问同一个不存在的课程ID观察后端数据库连接池的活跃连接数若没有空值缓存连接数会瞬间打满单发请求校验下单接口连续提交两次确认第二次被拦截且数据库中只有一条订单记录模拟分布式多实例部署后同时调用扣库存接口确认总扣减数不超过库存上限。这三个验证依次对应缓存穿透、接口幂等、分布式锁的正确性全部通过后这套源码才算真正达到上线标准。本文还有配套的精品资源点击获取
