互联网大厂 Java 面试实战：在线教育场景下的 Spring Boot、Kafka、RAG 与安全架构

面试官：聊聊在线教育平台的 Java 技术栈，你别整花活

场景：某互联网大厂在线教育业务，负责直播课、题库、作业批改、智能推荐与课程交易的核心 Java 后端岗位面试。

面试官：今天不聊虚的，直接从业务链路开始。你先说说，在线教育平台从下单、开课到学习记录回传，后端怎么分层设计？

燕双非：这题我会。一般分成订单服务、课程服务、学习中心、消息通知、支付回调几个模块。前面用 Spring Boot 做 REST 接口，内部服务之间可以用 OpenFeign 调用，复杂一点的异步用 Kafka。课程状态、订单状态最好别揉在一个大服务里，不然改一个功能像拆炸弹。

面试官：能说到服务拆分，说明你不是完全水。那如果直播课开播时，系统要同时给十万学生推送开播通知，你怎么保证通知不雪崩？

燕双非：先把通知写进消息队列，比如 Kafka。然后消费者限流、批量发送，配合 Redis 做开课状态缓存。前端轮询太费，最好用 WebSocket 或者长连接推送。嗯……还可以加个熔断降级，别让通知把主链路拖死。

面试官：这个方向是对的，说明你知道先削峰，再做异步。那如果有学生反馈“开播提醒收到了，但进直播间却提示已结束”，你怎么排查？

燕双非：大概率是缓存和数据库状态不一致。比如 Redis 里课程状态没及时更新，或者 Kafka 消息重复消费了。得看日志，最好有链路追踪，像 Jaeger 或 Zipkin。然后看数据库事务有没有提交成功，缓存有没有做双写一致性处理。

——

第二轮：题库、批改与推荐

面试官：题库系统里，学生做题后要实时判题。选择题简单，主观题要走 AI 批改。你怎么设计接口和数据流？

燕双非：选择题直接规则判分，主观题可以先落库，再异步发到 AI 服务。接口层用 Spring MVC 或 Spring Boot 提供提交答案接口，返回任务 ID。判题结果回来后再更新作业状态。如果要做流式反馈，Spring WebFlux 也能派上用场。

面试官：不错，已经开始有异步思维了。那 AI 批改里，如果要结合课程讲义、历史优秀答案做 RAG 检索，你会怎么理解？

燕双非：嗯……RAG 就是先去向量数据库里找相似内容，再把检索结果拼到提示词里给模型。比如把讲义、题目解析、标准答案做 embedding，存 Milvus 或 Redis 向量索引。学生提交后，先做语义检索，再喂给大模型。这样能减少幻觉，不然模型容易瞎编。

面试官：说到点子上了。那你知道怎么控制提示填充，避免把太多无关内容塞进去吗？

燕双非：控制上下文长度，按召回分数截断，优先保留题目相关的知识点；再结合 Agent 工具调用，只让模型调用必要的文档检索、评分器、知识库查询工具。嗯，提示词不能像往火锅里倒整箱调料，太多就串味。

面试官：比喻很离谱，但方向还行。那推荐系统每次给学生推课程，怎么让结果更稳定、可回放？

燕双非：可以把推荐请求和特征快照一起落库，后面用同样特征重放。缓存层用 Caffeine 或 Redis，热门课程做本地缓存，用户偏好做分布式缓存。推荐结果最好加版本号，不然今天推荐“考研冲刺”，明天又推荐“学会飞”，就很抽象。

——

第三轮：并发、事务、安全与发布

面试官：在线教育平台大促，课程秒杀、优惠券、支付回调一起上。你怎么保证订单不超卖、不重复扣款？

燕双非：库存秒杀要做预扣减，可以用 Redis 原子操作或者 Lua 脚本，订单创建和扣款回调要幂等。支付回调那边最好用唯一业务单号，数据库加唯一索引。事务里别把远程支付接口也包进去，容易把锁持太久。

面试官：嗯，这个答得比较像样。那订单状态流转里，如果用 MyBatis 和 JPA 混着来，你会注意什么？

燕双非：最好别在同一个核心事务里乱混，容易把 ORM 的缓存和 SQL 手写逻辑搞冲突。复杂查询用 MyBatis，简单对象关系映射用 JPA。事务边界要统一，连接池用 HikariCP，别让连接泄漏把线程都堵住。

面试官：最后一个问题。你们团队要上线 AI 助教，要求支持文档问答、智能客服和多轮会话记忆，还要能接企业内部工具。你怎么做安全和发布？

燕双非：安全上用 Spring Security + JWT，企业内部工具权限细分，重要接口加审计。多轮会话内存可以放 Redis，长期知识进向量库。发布方面走 Jenkins 或 GitHub Actions，镜像化部署到 Kubernetes，灰度发布，观察 Prometheus 和 Grafana 指标。AI 助教如果接 MCP 或工具调用标准化协议，工具权限要单独隔离，不然模型一激动把财务报表给发出去了，那就完了。

面试官：行，今天先到这。你回去等通知吧。

面试问题详细解答

1. 在线教育平台如何分层与拆服务？
核心原则是按业务能力拆分：课程、订单、学习记录、通知、支付、AI 批改等服务各自独立。接口层负责接收请求，应用层编排流程，领域层处理核心规则，基础设施层负责数据库、缓存、消息队列和外部接口。Spring Boot 适合快速搭建服务，OpenFeign 适合服务间调用，Kafka 适合异步解耦。业务上要优先保证订单、支付、学习记录等核心链路稳定，非核心动作如通知、埋点、推荐可异步化。

2. 十万级开播通知如何避免雪崩？
常见做法是“削峰填谷 + 异步化 + 限流降级”。先把通知请求写入 Kafka，消费者按固定并发批量处理；热点数据如课程开播状态使用 Redis 缓存；必要时使用 WebSocket 做实时推送。若下游服务压力过大，可以使用 Resilience4j 做熔断、限流和超时控制，保证主链路不被拖垮。日志建议配合 SLF4J/Logback，监控用 Micrometer + Prometheus + Grafana，排障时再结合 Jaeger 或 Zipkin 看链路。

3. 缓存与数据库状态不一致怎么排查？
最常见问题是双写不一致、消息重复消费、缓存失效时机不对。排查时先看消息队列是否重复投递，再看数据库事务是否提交成功，最后看缓存更新逻辑是否幂等。对于状态型数据，建议采用“数据库为准、缓存为辅”的策略；更新时先写数据库，再删缓存或延迟双删。对于强一致要求高的场景，可以把状态变更和事件发送放在同一事务消息或 Outbox 模式中处理。

4. AI 批改中的 RAG 如何落地？
RAG 的核心是“先检索，再生成”。文档、讲义、题解、优秀答案先切分、清洗、向量化，存入 Milvus、Chroma 或 Redis 向量能力中。用户提问后，先做语义检索，召回最相关的上下文，再把检索结果拼接到提示词中交给大模型。这样能提升回答准确率，减少幻觉。企业场景里还要加文档权限控制、召回结果过滤和引用来源展示，避免“看起来很对，其实乱编”。

5. 提示填充与 Agent 工具有哪些实践要点？
提示填充要控制上下文长度、信息密度和角色边界。不要把大量无关文档全塞进 prompt，而要按检索分数、主题相关度和业务优先级筛选。Agent 则适合处理多步骤任务，如“先查课程，再查订单，再生成答复”。工具调用要标准化，权限要最小化，避免模型误用高危接口。复杂工作流可以把“检索、校验、生成、审核”拆开，形成可观测、可回放的流程。

6. 推荐系统如何保证可回放与稳定性？
推荐结果不仅要准，还要能复现。做法是记录请求时的特征快照、模型版本、召回策略和排序策略。缓存层可以使用 Redis、Caffeine 或 Spring Cache；热点课程适合本地缓存，用户画像适合分布式缓存。对于实验场景，建议做 AB 测试和版本化管理，保证推荐结果可追踪、可回滚。这样才能在排查线上问题时复现当时的推荐逻辑。

7. 秒杀、扣款、回调为什么强调幂等？
因为网络重试、消息重复投递、用户重复点击都可能造成重复请求。幂等设计通常依赖唯一业务单号、数据库唯一索引、状态机校验、去重表或 Redis 记录请求指纹。支付回调尤其要注意，回调接口应允许重复调用但结果只生效一次。库存扣减可用 Redis 原子操作或 Lua 脚本保证并发安全，复杂场景再配合数据库乐观锁或分布式锁。

8. MyBatis 与 JPA 混用要注意什么？
MyBatis 适合复杂 SQL、报表查询和性能调优，JPA 适合简单对象关系映射和快速开发。混用时要重点控制事务边界、实体状态和数据库连接。不要在一个关键事务里把多个 ORM 的缓存机制搅在一起，容易出现脏读、重复更新或脏对象问题。连接池推荐 HikariCP，因为性能和稳定性都较好；同时要做好 SQL 监控和慢查询治理。

9. AI 助教如何做安全与发布？
安全上要做身份认证、授权、审计和接口隔离。Spring Security + JWT 适合前后端分离场景；企业内部工具则要按角色、部门和数据域授权。会话记忆可以放 Redis，长期知识放向量数据库。发布时用 Jenkins、GitHub Actions 或 GitLab CI 做自动化构建，容器化后部署到 Kubernetes，结合灰度发布和金丝雀发布逐步放量。监控指标建议覆盖接口延迟、错误率、队列堆积、GPU/CPU 占用以及模型调用成功率。

10. 为什么面试中要特别关注日志、监控与链路追踪？
因为分布式系统不是“写完就跑”，而是“出了问题能不能快速找到”。日志负责还原现场，监控负责发现异常，链路追踪负责定位瓶颈。SLF4J 只是门面，Logback 或 Log4j2 才是具体实现；Micrometer 可以统一采集指标，Prometheus 存储指标，Grafana 展示看板，Jaeger/Zipkin 则帮助定位一次请求跨多个服务的耗时分布。没有这些手段，线上问题基本等于“猜”。

11. WebSocket 在在线教育场景里有什么价值？
WebSocket 适合实时通知、直播互动、作业进度推送、答题结果回传等场景。相比轮询，它能减少请求开销并提升实时性。实现时要注意连接管理、心跳保活、断线重连和消息确认。对于大规模连接场景，要结合网关、负载均衡和消息中间件做分发，避免单点压力过高。

12. 总结
这组面试题的主线是：在线教育业务如何在高并发、强一致、异步化、AI 化和可观测性之间平衡。真正的面试回答，不只是背概念，而是把技术点放回业务链路中去解释：为什么要拆服务、为什么要异步、为什么要幂等、为什么要加监控、为什么 AI 要引入 RAG 和工具调用。只有能结合业务讲清楚，才算真正理解了这些技术。

感谢阅读，希望这篇内容能帮助到正在准备 Java 面试的你，祝你面试顺利、拿到心仪 offer！