互联网大厂 Java 面试实录Spring Boot、Kafka、Redis、RAG 与 Kubernetes 的业务追问场景某互联网大厂的技术面试现场业务方向为在线教育 企业协同 AIGC 智能客服。面试官严肃、问题连环递进候选人“燕双非”嘴上很稳遇到简单题还能答上来遇到复杂题就开始含糊其辞。第一轮基础能力与项目落地面试官先说说你们在线教育平台里为什么前端静态资源和课程详情页主要用Spring Boot Thymeleaf而不是全套前后端分离燕双非因为……嗯Thymeleaf 能直接把后端数据渲染到页面适合首屏快、SEO 也更友好。课程详情页、活动页这种偏内容展示的页面用模板引擎开发效率高和 Spring Boot 集成也很顺手。面试官回答得还行。那你们怎么做接口文档和联调管理燕双非我们一般会用Swagger/OpenAPI接口定义清晰前后端协作方便。复杂一点的接口还会配合统一返回结构和错误码减少联调扯皮。面试官那课程购买后的订单流转为什么会选Kafka而不是直接同步调用燕双非因为下单、支付成功、发放权益、通知讲师这些动作耦合太高。Kafka 更适合削峰填谷和异步解耦主链路先返回后续通过消息驱动多个下游系统处理。面试官说得不错。那消息重复消费你怎么处理燕双非嗯……一般就是幂等吧。比如订单号做唯一键消费前先查状态或者用数据库唯一索引、Redis 去重保证同一业务事件不会重复发权益。面试官继续说说你们缓存怎么设计的为什么不用只查数据库燕双非热点课程、首页推荐、讲师信息这些读多写少的场景会放Redis配合Spring Cache做缓存抽象。这样能降低数据库压力提升响应时间。对一些本地热点配置也会用Caffeine做一级缓存。第二轮中间件、微服务与稳定性面试官那你们微服务之间是怎么发现服务和做容错的燕双非服务发现可以用Consul或者注册中心方案调用侧一般会结合OpenFeign再加Resilience4j做熔断、限流、重试和隔离。这样某个服务抖动时不会把整个链路拖垮。面试官如果你们有一个“直播课签到”接口高峰期瞬间几万并发怎么扛燕双非先在网关或入口层做限流再把签到请求写入消息队列异步处理必要时配合Redis预扣减和原子操作防止超卖。核心原则就是把同步强依赖改成异步可控。面试官如果要给直播课签到做实时通知WebSocket 和消息队列怎么配合燕双非签到成功后业务服务往 Kafka 发事件通知服务消费后通过WebSocket推给前端在线用户。这样既能保证业务解耦也能做到准实时提醒。面试官你提到了容错。那如果支付回调服务突然不可用你怎么设计补偿燕双非可以先把支付结果落库并记录待处理状态通过定时任务或补偿消息重新投递。配合Flyway管理数据库变更确保补偿逻辑在版本演进时可追踪、可回滚。面试官那你们线上监控怎么做怎么知道接口慢了燕双非会用Micrometer统一采集指标接Prometheus Grafana看 QPS、P99、错误率链路追踪用Jaeger/Zipkin日志侧配合ELK排查问题。面试官不错排障思路比较完整。第三轮AIGC、检索增强与架构延伸面试官现在公司要做一个“智能客服 企业文档问答”系统你会怎么引入 AI燕双非我会用Spring AI做统一接入层把大模型、Embedding、向量检索、工具调用封装起来。对企业知识库做文档加载、切分、向量化先用RAG把相关文档检索出来再把上下文喂给模型回答减少幻觉。面试官那向量库和语义检索你怎么选燕双非如果是企业文档问答优先考虑Milvus、Chroma或Redis Vector这类向量数据库。Embedding 模型可以选OpenAI或Ollama体系根据成本、私有化和效果权衡。语义检索本质是把自然语言映射到向量空间做相似度匹配。面试官那如果客服系统需要调用工单、订单、知识库、用户画像多个工具你怎么组织燕双非要做工具调用标准化和扩展能力设计。可以把每个外部能力抽象成统一工具接口模型先决定是否调用工具再由工具执行框架去路由执行。再结合Agent和Agentic RAG让系统能根据用户意图自己规划步骤。面试官如果模型答非所问或者出现幻觉你怎么兜底燕双非要做约束生成、引用来源展示、置信度判断和人工兜底。比如答案必须基于检索到的企业文档如果检索不到就转人工或返回“当前知识库未覆盖”。面试官最后一个问题假设这个系统要部署到 Kubernetes 上你会关注哪些点燕双非嗯……主要是弹性伸缩、健康检查、配置中心、灰度发布还有资源限制吧。推理服务和业务服务要分开部署避免模型调用把整个应用拖慢。面试官行今天先到这吧。回去等通知。问题详解结合在线教育 企业协同 AIGC 场景逐题拆解1. Spring Boot Thymeleaf 为什么适合内容型页面在在线教育或活动运营场景里课程详情、专题页、落地页通常更看重首屏渲染速度和搜索引擎可见性。Thymeleaf 直接在服务端完成模板渲染减少前后端接口往返开发效率高和 Spring Boot 集成成本低。对于需要交互较强的业务可以逐步演进为前后端分离。2. Swagger/OpenAPI 的价值是什么它不仅是接口展示工具更是接口契约的一部分。对于多人协作的中大型项目统一接口定义、参数说明、返回模型、错误码能显著降低联调成本也方便自动生成客户端代码或 Mock 数据。3. Kafka 为什么适合订单、权益、通知链路这类链路通常是高并发、强解耦、多下游消费的典型业务。Kafka 支持高吞吐、分区扩展和消费者组模型适合把“下单成功”拆分成多个异步动作如发券、发短信、加学习群、发站内信等。核心收益是削峰、解耦、扩展和容错。4. 消息重复消费怎么保证幂等幂等手段常见有业务唯一键、数据库唯一索引、状态机校验、Redis 去重标记、消费日志表。实际工程里通常不是单一方案而是“消息幂等 业务状态校验 存储约束”组合使用避免重复发货、重复发券。5. Redis Spring Cache Caffeine 如何分层Redis 适合分布式共享缓存Caffeine 适合单机本地热点缓存。典型做法是本地缓存做一级、Redis 做二级、数据库做最终一致来源。Spring Cache 可以屏蔽缓存实现细节降低业务代码侵入。6. Consul、OpenFeign、Resilience4j 的组合意义是什么Consul 用于服务发现与健康检查OpenFeign 提供声明式 HTTP 调用Resilience4j 提供熔断、限流、重试、隔离等容错能力。这一套组合解决的是微服务调用链上的“找得到、调得通、扛得住”的问题。7. 高并发签到如何设计入口限流防止瞬时打爆服务Redis 原子扣减或 Lua 脚本控制库存/名额消息队列异步落库和发通知必要时使用本地缓存减少读压力。核心是把强一致、强实时的部分尽量收敛到最小其他环节异步化。8. WebSocket 与 Kafka 如何配合实时通知Kafka 负责系统内部事件分发WebSocket 负责把结果推送到在线客户端。前者是后端异步解耦后者是前端实时体验。二者组合可以兼顾稳定性和时效性常见于直播互动、订单状态、审批流通知。9. Micrometer、Prometheus、Grafana、Jaeger、ELK 如何形成可观测性闭环Micrometer 统一埋点指标Prometheus 负责采集和存储时序指标Grafana 负责可视化看板Jaeger/Zipkin 负责分布式链路追踪ELK 负责日志检索与分析。三者合起来能从“指标、链路、日志”三个维度快速定位故障。10. AI 客服为什么要先做 RAG而不是直接让大模型回答企业场景最怕模型“看似会说、实际乱说”。RAG 通过先检索企业知识库再把相关文档作为上下文传给模型能显著提升准确率和可解释性。特别适合制度问答、产品手册、工单知识、售后 FAQ 等场景。11. 向量数据库、Embedding、语义检索分别解决什么问题Embedding 把文本转换成向量表示向量数据库负责高效存储和相似度检索语义检索则是“按意思找内容”而不是“按字面匹配”。三者结合后系统能理解“用户想问什么”而不是只做关键词命中。12. Agent、工具调用、Agentic RAG 的区别是什么Agent 是能自主规划步骤的智能体工具调用是它执行外部能力的方法Agentic RAG 则是在检索增强生成基础上引入代理式决策让系统能根据任务目标多轮检索、调用工具、综合推理适合复杂工作流和多步骤问答。13. 如何控制 AI 幻觉常用方法包括只允许基于检索内容作答、展示引用来源、设置回答边界、低置信度时转人工、对敏感领域引入规则引擎和审核机制。企业落地里幻觉控制通常比“回答很聪明”更重要。14. Kubernetes 部署 AI 与业务服务时要注意什么要区分推理服务和业务服务设置资源请求与限制避免模型服务抢占 CPU/内存配置 readiness/liveness 探针结合 HPA 做弹性伸缩必要时引入灰度发布和熔断降级。这样才能保证大模型不把整个业务系统拖垮。感谢阅读希望这篇互联网大厂 Java 面试实录能够帮助大家在 Spring Boot、Kafka、Redis、微服务、RAG 和 Kubernetes 等方向上建立更完整的知识体系也希望对正在准备面试的你有所帮助。