Java 大厂面试实录Spring Boot Kafka Redis Spring Security RAG 的全链路深挖场景互联网大厂 Java 求职面试业务背景一个“电商 AIGC”融合平台需要支持商品推荐、智能客服、订单事件驱动、用户登录鉴权、缓存加速、异步消息解耦以及基于知识库的问答能力。第一轮基础能力与业务理解面试官先说说你们这个电商平台为什么选 Spring Boot而不是传统的 Spring MVCXML 配置燕双非因为……Spring Boot 比较快开箱即用少写很多配置。对吧启动类一跑很多东西就自动装上了。面试官嗯至少方向对了。那如果下单接口很频繁你会怎么做一个基础的接口分层燕双非Controller、Service、DAO 三层嘛。Controller 接收参数Service 放业务DAO 负责查库。订单这种场景一般还会加个 DTO 和 VO不然代码会比较乱。面试官不错。那如果商品详情页的访问量很大数据库扛不住你会先考虑什么燕双非先上 Redis 缓存热点商品详情可以缓存起来。还可以设置过期时间避免缓存一直不更新。面试官如果缓存失效那一刻很多请求同时打到数据库你怎么处理燕双非这个……可以加锁吧或者做热点预热避免一起穿透到数据库。还有就是别让大家都在同一秒失效。面试官思路可以说明你至少见过线上问题。第二轮异步化、鉴权与风控面试官现在订单创建成功后要给用户发短信、发站内信、更新积分、触发推荐系统你会怎么设计燕双非我会用 Kafka。下单成功后发一个订单事件其他系统订阅这个消息各做各的互不影响。面试官那 Kafka 的消息会不会重复消费燕双非会的吧。那就得做幂等比如用订单号做唯一标识消费前先查一下是否处理过。面试官如果你要保证支付回调和库存扣减不出错幂等之外还要注意什么燕双非嗯……事务一致性吧。可以用本地消息表或者最终一致性方案。支付成功后不要直接乱改库存要有补偿机制。面试官那用户登录怎么设计我们这里有 JWT 和 Spring Security。燕双非登录后签发 JWT前端带着 token 请求接口。Spring Security 负责拦截和鉴权token 里放用户身份信息后端校验签名和过期时间。面试官如果你的平台还有 AI 客服用户可以用自然语言问“我的订单什么时候到”你怎么把订单服务和知识问答打通燕双非这个可以做 RAG。先把订单规则、物流说明、客服知识库做向量化用户提问后先检索再把相关内容给大模型生成回答。如果涉及实时订单就再调订单接口补数据。面试官不错已经开始有业务联动意识了。第三轮高并发、可观测与云原生落地面试官如果这个平台要上 KubernetesSpring 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 BootSpring 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 可统一采集指标并接入 PrometheusGrafana 用于展示图表Jaeger 或 Zipkin 用于分布式链路追踪。排查超时问题时指标、日志、链路三者要结合看。如果接口延迟升高可能是线程池耗尽、连接池不足、下游依赖慢、GC 抖动或日志过多引起的。10. JVM 排查重点面试中提到 Full GC 频繁通常要从堆内存配置、对象生命周期、晋升失败、大对象、内存泄漏和 GC 日志几个方面分析。缓存失效、集合对象堆积、线程池队列无限增长都可能导致问题。线上定位时建议结合 jstat、jmap、GC 日志以及 APM 工具一起分析。总结本题的核心不是死记工具名而是从业务场景出发讲清楚“为什么这么选、怎么串起来、出问题怎么排”。感谢阅读希望这篇文章能帮助大家更好地准备 Java 面试尤其是在大厂面试中把技术点和业务场景真正讲明白。