互联网大厂Java面试实录：Spring Boot、Redis、Kafka、Kubernetes、Spring Security 与 AI RAG

互联网大厂 Java 面试实录：Spring Boot、Redis、Kafka、Kubernetes、Spring Security 与 AI RAG

场景：某互联网大厂电商增长与智能客服团队面试

角色：

• 面试官：严肃、专业、问题层层递进
• 小Y：自称“什么都会一点”的水货程序员，简单题能答，复杂题开始含糊

---

第一轮：基础能力与业务理解

1）面试官：你先说说，电商下单接口为什么通常要做幂等？

小Y：因为用户可能会重复点按钮，或者网络超时重试。如果不做幂等，可能会下两单、扣两次库存。一般可以用订单号、请求唯一ID、数据库唯一索引来保证同一请求只处理一次。

面试官：这个回答不错，说明你做过真实业务，不是只背概念。

2）面试官：那你用 Spring Boot 做下单服务时，怎么拆分 Controller、Service、Repository？

小Y：Controller 负责接收参数和返回结果，Service 负责业务编排，比如校验库存、创建订单、发消息，Repository 负责和数据库交互。这样分层后，代码更清晰，也方便测试。

面试官：分层思路对，继续往下讲事务边界。

3）面试官：订单创建时要同时写订单表、库存表，你怎么处理事务？

小Y：通常会用 Spring 的 @Transactional 包住核心业务，保证要么都成功，要么都失败。跨服务场景就不能只靠本地事务了，可能要用消息最终一致性或者 Saga 思路。

面试官：很好，你已经从本地事务想到分布式事务了。

4）面试官：如果库存扣减非常频繁，你会怎么优化？

小Y：可以先在 Redis 里做库存预扣，减少数据库压力，再异步落库；热点商品可以加缓存和限流。还要注意缓存和数据库的一致性，避免超卖。

面试官：回答还行，已经开始碰到高并发问题了。

---

第二轮：中间件、稳定性与微服务

1）面试官：那订单创建成功后，你会怎么通知库存、物流、营销系统？

小Y：我会发 Kafka 消息，让库存服务、物流服务、优惠券服务分别消费。这样是异步解耦的，主链路更快。消费端要做幂等，避免重复消费造成脏数据。

面试官：对，消息驱动是电商系统的常见设计。

2）面试官：如果 Kafka 消息积压了，你怎么排查？

小Y：先看生产速度是不是突然增大，再看消费者是否挂了、分区是否不均衡、是否存在慢 SQL。监控上会关注消费延迟、broker CPU、磁盘、网络，还有消费组的 lag。

面试官：不错，能把业务现象和监控指标联系起来。

3）面试官：你刚才提到 Redis，面试里常问缓存穿透、击穿、雪崩，你分别怎么处理？

小Y：

• 穿透：查不存在的数据一直打到数据库，可以缓存空值或者布隆过滤器。
• 击穿：热点 key 失效导致大量请求打到数据库，可以加互斥锁、逻辑过期。
• 雪崩：大量 key 同时失效，可以加随机过期时间、分批失效、做多级缓存。

面试官：这个答得比较完整，说明你理解过缓存体系。

4）面试官：如果这个系统要上 Kubernetes，你最关心什么？

小Y：我会关心应用的健康检查、资源限制、滚动发布、配置中心、日志采集和弹性伸缩。比如 Spring Boot 服务要提供 readiness 和 liveness 探针，避免流量打到未就绪实例。

面试官：很好，已经开始有云原生意识了。

---

第三轮：安全、AI 与复杂场景

1）面试官：现在我们给订单系统加一个智能客服，用户可以自然语言查订单、退货、发票。你会怎么设计？

小Y：我会把它做成一个 AI 服务层，前面接 Spring Boot 网关，后面接 RAG。先把订单政策、退货规则、发票说明等文档做向量化，存到向量数据库里；用户提问后先检索相关内容，再交给大模型生成回答。

面试官：思路对，已经从“聊天”走向“业务问答”了。

2）面试官：那如果用户问“帮我把上个月买的那双鞋退了”，AI 只能回答流程吗？

小Y：理论上它不只是回答流程，还可以调用工具，比如查询订单、校验退货条件、创建售后单。但工具调用要做权限校验和参数校验，不能让模型直接乱操作。

面试官：不错，你提到了工具执行边界，这是关键。

3）面试官：那 Spring Security、JWT、OAuth2 在这里怎么配合？

小Y：用户登录后由认证中心签发 JWT，网关和业务服务验证 Token。OAuth2 适合第三方授权或统一登录，Spring Security 负责权限拦截。对于客服后台、运营后台，还要做角色控制和接口级鉴权。

面试官：思路清楚，说明你不是只会“放行所有请求”。

4）面试官：最后一个问题，如果 AI 回答错了，甚至产生幻觉，你怎么兜底？

小Y：呃……这个要看模型能力吧，可以多训一下，或者让它多思考一下……

面试官：你这个回答太虚了。实际要做的是：限制知识来源、强化检索召回、答案引用原文、敏感操作必须走确定性规则和人工确认。今天先到这里，你回去等通知吧。

---

题后答案解析：把每一题讲透

1. 为什么订单接口要幂等？

在电商场景里，用户重复点击、前端重试、网关重发、消息重复投递都可能让同一个请求被执行多次。若不幂等，就会出现重复下单、重复扣款、重复发券。

常见做法：

• 请求唯一号：前端或网关生成 requestId
• 业务唯一键：例如订单号、支付流水号
• 数据库约束：唯一索引是最后一道防线
• 分布式锁：只适合短时间互斥，不是幂等的唯一方案

核心原则：同一个业务请求无论执行多少次，结果都应一致。

2. Spring Boot 分层为什么重要？

分层不是为了“好看”，而是为了职责隔离：

• Controller：接收请求、参数校验、响应封装
• Service：编排业务流程，处理领域规则
• Repository/Mapper：持久化访问
• DTO/VO：隔离接口与内部对象

这样做的好处：

• 更容易测试，Service 可以单测
• 更容易维护，改接口不一定影响业务
• 更容易扩展，比如后面接 MQ 或 AI 服务

3. 本地事务与分布式事务怎么选？

@Transactional 只能解决单库或单服务内的数据一致性。跨服务后，不能指望一个数据库事务覆盖所有系统。

电商常见方案：

• 订单服务本地事务成功后发消息
• 库存、营销、物流异步消费
• 失败通过补偿机制修正

这类模式强调最终一致性，适合高吞吐业务。

4. 热点库存如何优化？

热点商品会让数据库和锁竞争变得非常严重。常用思路：

• Redis 预扣库存，先挡掉大量无效请求
• 消息队列削峰，异步落库
• 本地缓存或多级缓存减少读取压力
• 限流与排队，防止系统被打穿

注意：缓存只是性能手段，不是业务真相，最终还是要回到可靠存储。

5. 为什么订单后续系统适合用 Kafka？

Kafka 适合高吞吐、异步解耦、事件驱动的场景。订单创建后，库存、物流、营销、风控都可以订阅订单事件。

关键点：

• 生产者写入成功不代表业务完全成功，业务状态要设计清楚
• 消费者必须幂等
• 消费失败要有重试和死信处理
• 分区设计影响吞吐和顺序性

6. Kafka 积压怎么排查？

通常从三层看：

• 生产端：消息量是否暴增，是否有异常重试
• Broker：CPU、磁盘、网络、ISR 是否异常
• 消费端：实例是否宕机，是否存在慢 SQL、外部依赖慢、分区不均衡

监控重点：lag、吞吐量、消费延迟、错误率。

7. Redis 三大缓存问题怎么处理？

• 穿透：请求不存在的数据，命中不了缓存和数据库。解决：布隆过滤器、缓存空值。
• 击穿：热点 key 过期瞬间并发打到数据库。解决：互斥锁、逻辑过期。
• 雪崩：大量 key 同时过期。解决：随机过期时间、多级缓存、限流降级。

这是互联网面试高频题，最好能结合具体业务说，比如秒杀、商品详情、活动页。

8. Kubernetes 上线时要关注什么？

一个 Java 服务上 K8s，不只是“能跑起来”。更要关注：

• 健康检查：readinessProbe、livenessProbe
• 资源配置：CPU / 内存 requests 和 limits
• 配置管理：ConfigMap、Secret
• 发布策略：滚动发布、灰度发布
• 观测：日志、指标、链路追踪

如果是 Spring Boot 服务，最好在启动、降级、优雅停机上都做好适配。

9. AI 客服为什么要用 RAG？

直接让大模型回答业务问题，容易出现“胡说八道”的幻觉。RAG 的做法是：

• 先把企业文档切分、清洗、向量化
• 存到向量数据库中，如 Milvus、Chroma、Redis 向量能力
• 用户提问时先做语义检索
• 把检索结果作为上下文喂给模型生成回答

这样模型更像“基于资料作答”，而不是凭空编造。

10. AI 什么时候需要工具调用？

当问题不是“解释知识”，而是“执行动作”时，就需要工具调用。

例如：

• 查订单：调用订单查询接口
• 退货：调用售后服务接口
• 发票：调用发票系统接口

原则：

• 模型负责理解意图
• 工具负责确定性执行
• 所有敏感操作都要鉴权、审计、参数校验

这也是 Agent 和普通聊天机器人的关键区别。

11. Spring Security、JWT、OAuth2 怎么配合？

• JWT：承载用户身份和部分权限信息，便于无状态校验
• Spring Security：负责认证、授权、拦截器链
• OAuth2：适合统一登录、第三方授权、SSO 场景

在企业系统里，常见是登录中心签发 Token，业务系统只负责校验和授权，不自己保存会话状态。

12. AI 幻觉怎么兜底？

这题最容易被答虚。

正确思路：

• 限制知识来源，只让模型基于检索结果回答
• 输出引用来源，降低“看起来很对”的错误
• 对金额、订单、退款等关键操作，必须走规则引擎或人工确认
• 做提示词约束，但不要迷信提示词能完全解决问题
• 对高风险回答设置拒答和转人工

真正的生产级 AI，不是“更会说”，而是“更可控”。

---

面试官想看的能力

这类大厂 Java 面试，不只是问你会不会 Spring Boot、Redis、Kafka，而是看你能不能把这些技术放进真实业务里：

• 是否理解高并发下的幂等、缓存、消息、事务
• 是否理解云原生部署、监控和稳定性
• 是否理解安全、权限与审计
• 是否理解 AI 在业务中的边界，尤其是 RAG、工具调用和幻觉治理

如果你能把“下单、退款、客服、风控、活动、通知”这些场景讲明白，技术栈才真正落地。