Java 大厂面试实录：Spring Boot + Kafka + Redis + Spring Security + RAG 的全链路深挖

Java 大厂面试实录：Spring Boot + Kafka + Redis + Spring Security + RAG 的全链路深挖

场景：互联网大厂 Java 求职面试

业务背景：一个“电商 + AIGC”融合平台，需要支持商品推荐、智能客服、订单事件驱动、用户登录鉴权、缓存加速、异步消息解耦，以及基于知识库的问答能力。

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

面试官：先说说，你们这个电商平台为什么选 Spring Boot，而不是传统的 Spring MVC+XML 配置？

燕双非：因为……Spring Boot 比较快，开箱即用，少写很多配置。对吧，启动类一跑，很多东西就自动装上了。

面试官：嗯，至少方向对了。那如果下单接口很频繁，你会怎么做一个基础的接口分层？

燕双非：Controller、Service、DAO 三层嘛。Controller 接收参数，Service 放业务，DAO 负责查库。订单这种场景一般还会加个 DTO 和 VO，不然代码会比较乱。

面试官：不错。那如果商品详情页的访问量很大，数据库扛不住，你会先考虑什么？

燕双非：先上 Redis 缓存，热点商品详情可以缓存起来。还可以设置过期时间，避免缓存一直不更新。

面试官：如果缓存失效那一刻，很多请求同时打到数据库，你怎么处理？

燕双非：这个……可以加锁吧，或者做热点预热，避免一起穿透到数据库。还有就是，别让大家都在同一秒失效。

面试官：思路可以，说明你至少见过线上问题。

第二轮：异步化、鉴权与风控

面试官：现在订单创建成功后，要给用户发短信、发站内信、更新积分、触发推荐系统，你会怎么设计？

燕双非：我会用 Kafka。下单成功后发一个订单事件，其他系统订阅这个消息，各做各的，互不影响。

面试官：那 Kafka 的消息会不会重复消费？

燕双非：会的吧。那就得做幂等，比如用订单号做唯一标识，消费前先查一下是否处理过。

面试官：如果你要保证支付回调和库存扣减不出错，幂等之外还要注意什么？

燕双非：嗯……事务一致性吧。可以用本地消息表，或者最终一致性方案。支付成功后不要直接乱改库存，要有补偿机制。

面试官：那用户登录怎么设计？我们这里有 JWT 和 Spring Security。

燕双非：登录后签发 JWT，前端带着 token 请求接口。Spring Security 负责拦截和鉴权，token 里放用户身份信息，后端校验签名和过期时间。

面试官：如果你的平台还有 AI 客服，用户可以用自然语言问“我的订单什么时候到”，你怎么把订单服务和知识问答打通？

燕双非：这个可以做 RAG。先把订单规则、物流说明、客服知识库做向量化，用户提问后先检索，再把相关内容给大模型生成回答。如果涉及实时订单，就再调订单接口补数据。

面试官：不错，已经开始有业务联动意识了。

第三轮：高并发、可观测与云原生落地

面试官：如果这个平台要上 Kubernetes，Spring Boot 服务怎么做优雅发布？

燕双非：可以做滚动发布，控制副本数，先起新 Pod，再逐步切流。健康检查也要做好，不然服务起来了但其实不能用。

面试官：那你怎么监控一个“下单 - 支付 - 发货 - 物流”链路的延迟问题？

燕双非：可以用 Micrometer 接 Prometheus，再配 Grafana 看图表。链路追踪可以用 Jaeger 或 Zipkin，看看请求卡在哪一段。

面试官：如果发现下单接口偶发超时，但数据库、Kafka、Redis 都正常，你会怎么继续排查？

燕双非：可能是线程池满了，或者下游调用太慢。也可能是 JSON 序列化慢、日志打印太多、连接池不够。还得看 JVM GC 有没有抖动。

面试官：说到 JVM，线上 Full GC 很频繁，你会先看什么？

燕双非：先看堆内存分配、对象存活率、是不是大对象太多。再看是不是缓存没做好，导致对象堆积。还要结合 GC 日志分析。

面试官：最后一个问题：如果让你设计一个“订单智能客服 + 活动推荐 + 风控拦截”的平台，你会怎么组合这些技术？

燕双非：前台用 Spring Boot 暴露接口，登录用 Spring Security + JWT；订单、支付、物流用 Kafka 解耦；Redis 做热点缓存；Prometheus/Grafana 做监控；RAG 做客服问答；风控规则可以实时拦截异常行为。大概……先这样吧。

面试官：嗯，整体方向有了，但细节还得再打磨。今天先到这，你回家等通知吧。

面试题详细解析

1. 为什么电商平台常用 Spring Boot

Spring Boot 的核心价值在于自动配置、约定优于配置和独立运行能力。对于电商平台这类高频迭代系统，能快速搭建 Web 服务、整合缓存、消息队列、鉴权、监控等能力，显著提升研发效率。

在业务上，订单、商品、用户中心通常是多个微服务，Spring Boot 可以让每个服务更轻量，便于独立部署和扩缩容。

2. 经典三层架构的作用

Controller 负责请求入口、参数接收与返回包装；Service 负责核心业务逻辑；DAO 负责持久层访问。配合 DTO/VO 可以隔离内部实体与外部接口，减少耦合。

在订单场景中，Controller 处理参数校验，Service 负责下单规则、库存校验、优惠券计算，DAO 负责落库。

3. Redis 缓存的使用与缓存击穿处理

热点商品详情、首页活动、用户会话等都适合放在 Redis 中，以降低数据库压力。对于热点 key 过期引发的缓存击穿，可使用互斥锁、逻辑过期、热点预热等手段。

在电商大促场景，某个爆款商品在瞬时流量下如果失效，会导致大量请求同时访问数据库。通过互斥锁可以确保只有一个线程回源构建缓存，其余线程等待或返回旧值。

4. Kafka 在订单事件驱动中的作用

Kafka 常用于解耦和削峰填谷。订单创建后可以发布订单事件，营销、积分、风控、通知等下游系统分别订阅处理。

其关键问题包括重复消费、消息顺序、消息堆积与幂等设计。实际工程中，消费端通常要根据业务主键做去重，并设计补偿机制保证最终一致性。

5. 支付与库存的一致性思路

支付成功后，库存扣减、订单状态更新、发货流程触发之间不能简单依赖单体事务。常见思路包括本地消息表、事务消息、TCC、Saga、可靠消息最终一致性等。

面试中如果说“直接一个事务包住所有系统”通常是不现实的，分布式环境下需要考虑幂等、补偿和超时重试。

6. Spring Security + JWT 的登录体系

JWT 适合无状态认证，服务端不需要保存 Session，便于横向扩容。Spring Security 负责过滤器链、权限校验与认证授权流程。

通常登录成功后签发 JWT，前端在请求头中携带，后端校验签名、有效期和权限声明。若涉及高安全场景，还要考虑 token 续期、黑名单、踢下线等问题。

7. RAG 在 AI 客服中的落地方式

RAG 即检索增强生成，核心是先检索再生成。对于“我的订单什么时候到”这类问题，可以先检索物流政策、常见问答、订单规则，再结合实时订单数据进行回答。

在企业客服场景里，RAG 能显著降低大模型胡编乱造的概率，但必须结合权限控制、数据脱敏、索引更新和召回质量优化。

8. Kubernetes 上的服务发布与健康检查

在 K8s 中常用滚动发布、探针检查、资源限制、自动扩缩容等能力。Spring Boot 服务一般要提供 readiness 和 liveness 探针，避免流量打到未就绪实例。

大促期间，合理配置 HPA 和副本数，可以帮助系统应对流量波峰。

9. 监控与链路追踪

Micrometer 可统一采集指标并接入 Prometheus，Grafana 用于展示图表；Jaeger 或 Zipkin 用于分布式链路追踪。排查超时问题时，指标、日志、链路三者要结合看。

如果接口延迟升高，可能是线程池耗尽、连接池不足、下游依赖慢、GC 抖动或日志过多引起的。

10. JVM 排查重点

面试中提到 Full GC 频繁，通常要从堆内存配置、对象生命周期、晋升失败、大对象、内存泄漏和 GC 日志几个方面分析。缓存失效、集合对象堆积、线程池队列无限增长都可能导致问题。

线上定位时，建议结合 jstat、jmap、GC 日志以及 APM 工具一起分析。

总结：本题的核心不是死记工具名，而是从业务场景出发，讲清楚“为什么这么选、怎么串起来、出问题怎么排”。

感谢阅读，希望这篇文章能帮助大家更好地准备 Java 面试，尤其是在大厂面试中把技术点和业务场景真正讲明白。