
互联网大厂 Java 面试实录Spring Boot Redis Kafka RAG 场景下的“三轮拷打”面试场景某互联网大厂业务为本地生活 内容社区 AI 客服候选人是自称“熟悉全栈”的 Java 开发者燕双非。第一轮核心技术与基础设施面试官你先说说为什么我们本地生活业务常用 Spring Boot而不是传统 Spring MVC 加一堆 XML燕双非Spring Boot 快嘛开箱即用配置少启动也快。对我们这种要快速迭代的业务很友好尤其是门店活动、团购券这种需求经常变。面试官不错能把“快”落到业务上。那如果订单服务要接 Redis 做缓存你怎么设计缓存 Key避免活动高峰期出现雪崩燕双非Key 要有业务前缀和版本号比如coupon:activity:v1:shopId。雪崩的话……可以加随机过期时间热点数据预热必要时加本地缓存。面试官回答得还行说明你不是只会背名词。那你觉得 Redis 做库存预扣最大风险是什么燕双非嗯……并发扣减、超卖、还有……数据一致性吧。可能要用 Lua 保证原子性或者用消息队列异步落库。面试官行至少方向对了。最后一个基础题Kafka 在我们的商家消息中心里适合承担什么角色燕双非适合做削峰填谷。比如商家上新、订单状态变化、用户评价通知都可以先发 Kafka再由下游异步消费。第二轮业务链路与中间件协同面试官现在我们扩展一下本地生活平台里有一个“商家智能客服”模块用户问“我的退款多久到账”。你怎么把请求从前台一路传到后端燕双非前端请求进网关后端先查用户订单再判断是否命中缓存如果没命中就查数据库。客服模块可以通过 REST 调订单服务返回退款状态。面试官如果客服系统要做高并发流式问答你会考虑什么技术栈燕双非可能会用 Spring WebFlux 做异步非阻塞再配合 WebSocket 把答案分段推给前端体验会更像“实时聊天”。面试官这个思路对。那如果我们把 FAQ 文档、工单记录、退款政策做成检索增强生成也就是 RAG你怎么理解燕双非就是先把文档切块然后做向量化存进向量数据库。用户提问时先做语义检索把相关片段取出来喂给大模型减少它胡说八道。面试官很好终于说到重点了。那你觉得 RAG 里最容易翻车的问题是什么燕双非嗯……召回不准、切块不合理、embedding 不匹配还有大模型可能会幻觉。面试官对尤其是“幻觉”。如果让你选 Spring AI、MCP、工具调用标准化来做企业客服你会怎么串起来燕双非Spring AI 负责接模型和提示词MCP 负责把外部工具比如订单查询、退款查询标准化暴露出来。模型根据问题决定调用哪个工具再把结果组织成回复。第三轮稳定性、安全与工程化落地面试官最后一轮假设大促期间商家端接口突然慢了你怎么定位燕双非先看监控比如 Prometheus 和 Grafana确认是接口整体慢还是某个依赖慢。再看链路追踪比如 Zipkin 或 Jaeger定位是数据库、缓存还是远程调用的问题。面试官如果发现是数据库慢你会怎么优化燕双非先看 SQL 和索引再看连接池配置比如 HikariCP 参数是否合理读多写少的地方可以加缓存必要时做读写分离。面试官那安全方面呢客服系统会接用户隐私数据怎么保护燕双非可以用 Spring Security 做认证鉴权敏感字段加密存储接口用 JWT 或 OAuth2 控制访问。日志里不能直接打印身份证、手机号这些信息。面试官如果再给你加一个“AI 工单自动归类”需求你怎么保证它不会乱分燕双非先给模型加明确的提示词和标签体系再加人工兜底。对于低置信度结果就不自动流转转人工审核避免误分单。面试官嗯今天就到这吧。你回去等通知。我们后面如果有进展会尽快联系你。面试题详细解答1. 为什么本地生活业务常用 Spring BootSpring Boot 的核心价值是约定优于配置非常适合迭代快、需求多变的互联网业务。本地生活场景里团购、预约、优惠券、商家入驻等能力经常变化Spring Boot 可以快速搭建服务、减少 XML 配置和样板代码并且天然适合微服务架构。2. Redis 缓存 Key 设计与雪崩防护缓存 Key 一般要包含业务域、资源类型、版本号和唯一标识例如coupon:activity:v1:shopId。这样便于维护和灰度升级。防雪崩常见措施包括随机过期时间、热点预热、互斥重建缓存、本地缓存兜底、限流降级等。在大促场景下建议对核心热点数据提前加载并配合熔断策略保护数据库。3. Redis 库存预扣的风险Redis 适合做高并发库存预扣但要注意超卖和最终一致性。常见做法是用 Lua 脚本保证扣减原子性然后把扣减结果通过 Kafka 异步发送到订单和库存服务最终落库。若消息发送失败要有补偿机制避免缓存和数据库不一致。4. Kafka 在消息中心中的作用Kafka 主要承担异步解耦、削峰填谷、事件驱动的角色。比如订单状态变更、商家通知、评价通知等都可以通过 Kafka 传递避免同步调用链过长。高峰时段生产端和消费端可以各自按能力处理提升系统吞吐。5. WebFlux 与 WebSocket 在实时客服中的作用Spring WebFlux 适合高并发、IO 密集型场景使用响应式编程减少线程阻塞。WebSocket 则适合双向实时通信客服问答可以一边生成一边推送到前端实现“流式输出”的体验。二者结合适合做智能客服、在线陪聊、实时通知等场景。6. RAG 的工作原理RAGRetrieval-Augmented Generation检索 生成。先把企业文档、FAQ、工单等内容做切分、清洗、向量化并存入向量数据库如 Milvus、Chroma、Redis 向量。用户提问后先做语义检索找到最相关的知识片段再连同问题一起送入大模型生成答案。这样能显著降低幻觉提高答案的可控性与可解释性。7. RAG 中常见问题主要问题包括切块过大或过小、召回不准、embedding 模型不匹配、上下文窗口不够、以及模型幻觉。解决办法包括优化切分策略、引入重排序rerank、使用更合适的 embedding 模型、控制提示词和回答边界、对低置信度问题转人工。8. Spring AI 与 MCP 的协同Spring AI 更偏向于 Java 生态下对大模型能力的封装负责模型接入、提示词管理、对话记忆、RAG 组合等。MCP模型上下文协议则把外部工具、数据源和能力以统一方式暴露给模型便于标准化工具调用。企业客服场景中可以把订单查询、退款查询、物流查询等能力通过 MCP 暴露再由模型选择性调用实现“可控的智能化”。9. Prometheus、Grafana、Zipkin/Jaeger 的定位方式Prometheus 用于采集指标Grafana 用于可视化展示Zipkin/Jaeger 用于分布式链路追踪。定位接口慢时先看整体 QPS、P95/P99 延迟再通过链路追踪找出慢点是在网关、服务、数据库还是外部依赖最后结合日志进一步分析。10. HikariCP、索引、缓存在数据库优化中的作用如果数据库慢首先检查 SQL 是否命中索引、是否存在全表扫描、是否有锁等待。HikariCP 作为高性能连接池要合理设置最大连接数、超时和空闲策略。对于读多写少的业务可以增加缓存层减少数据库压力对于复杂查询则需要从表结构和 SQL 设计上优化。11. Spring Security、JWT、OAuth2 在安全中的作用Spring Security 用于统一认证与鉴权JWT 适合无状态身份传递OAuth2 适合第三方授权和统一登录。业务系统里敏感接口必须做权限控制并在日志、监控、报表中对隐私数据脱敏避免泄露用户手机号、身份证号、地址等信息。12. AI 工单自动归类如何避免“乱分”可以通过提示词约束、标签体系、置信度阈值和人工兜底四层保障。模型输出低置信度时不直接自动流转而是进入人工审核队列。对于高风险工单还可以保留人工确认步骤确保系统可靠性。感谢阅读希望这篇互联网大厂 Java 面试实录能帮助大家在技术面试中更有思路也能把知识点真正结合业务场景理解透彻。祝大家面试顺利早日拿到理想 offer