Java 面试实战：Spring Boot + Kafka + Redis + Kubernetes + Spring Security 的互联网大厂求职故事
文章简述：围绕互联网大厂 Java 面试场景，模拟严肃面试官与搞笑候选人燕双非的 3 轮递进式问答，覆盖 Spring Boot、Kafka、Redis、Kubernetes、Spring Security、MyBatis、Micrometer、RAG 等技术点，并在文末详细解析所有问题，帮助读者系统理解常见面试考点与业务落地思路。
第一轮：基础能力与业务理解
面试官：我们先从电商下单链路开始。你们系统为什么要选 Spring Boot？它在启动和配置上相比传统 Spring MVC 有什么优势？
燕双非：Spring Boot 好啊，开箱即用，少写很多 XML。它有自动配置和 Starter，启动一个项目不用到处配 bean，挺适合快速搭系统的。
面试官：嗯，方向是对的。那你再说说，电商下单时，库存扣减和订单创建怎么保证一致性？
燕双非：这个嘛，一般先创建订单，再扣库存，或者先扣库存再创建订单。要是失败了就……回滚一下？反正要保证别超卖。
面试官：思路有点模糊，但你提到了核心点：一致性和超卖。最后一个问题，Redis 在秒杀场景里怎么用？
燕双非：Redis 可以缓存库存，也可以做热点商品缓存，还能用分布式锁防止并发问题。哦对，队列也能先把请求挡住。
面试官：可以，至少你知道缓存、锁和削峰。继续保持。
第二轮：微服务、消息与安全
面试官：现在我们把系统拆成微服务，订单服务、库存服务、支付服务之间怎么通信？你会怎么选 Kafka、OpenFeign、gRPC？
燕双非：同步调用可以用 OpenFeign，简单直接；异步场景比如订单创建后发消息给库存和营销服务，可以用 Kafka。gRPC 适合内部高性能调用吧，接口强约束一些。
面试官：不错，这次答得比较完整。那如果 Kafka 消息重复消费了，你怎么处理？
燕双非：嗯……我会先做幂等。比如订单号做唯一键，消费前先查一下数据库有没有处理过，或者用 Redis 记录消费状态。重复了就直接跳过。
面试官：很好，这是常见工程手段。那再说说 Spring Security 在支付系统里怎么做权限控制？
燕双非：支付系统比较敏感，可以用 Spring Security + JWT，前端登录后拿 token，请求时带上。后端根据角色、权限、接口鉴权。涉及重要操作还可以加二次校验。
面试官：对，支付场景尤其要关注最小权限和敏感操作保护。最后，Kubernetes 在你这个系统里主要解决什么问题？
燕双非：主要是部署、弹性伸缩、服务发现，还有故障自动恢复。容器挂了它能拉起来，流量大时也能扩容。
面试官：回答得可以，说明你对云原生有基本理解。
第三轮：治理、监控与 AI 结合
面试官：如果我们要给这个电商系统加一个智能客服，结合 RAG 和 Agent，你会怎么设计？
燕双非：嗯，先把商品知识、售后政策、物流规则做文档加载，然后切分、向量化，存到向量数据库里。用户提问时先语义检索，再把相关内容喂给大模型生成答案。如果要自动查订单、查物流，就让 Agent 去调用工具。
面试官：这个方向不错。那你怎么减少 AI 幻觉？
燕双非：我觉得要让模型少瞎编，尽量让它只基于检索到的内容回答；同时给它约束提示词，必要时让它输出引用来源。对于不确定的问题，应该明确说不知道。
面试官：很好，至少你知道不能让模型自由发挥。再问一个监控问题，Micrometer、Prometheus、Grafana 在系统里怎么配合？
燕双非：Micrometer 负责埋点，把接口耗时、QPS、错误率之类的指标暴露出去；Prometheus 负责采集和存储；Grafana 负责看板展示。这样可以很快发现接口抖动、订单堆积这些问题。
面试官：说得不错。最后一个问题，如果支付链路里出现偶发超时，你会怎么排查？
燕双非：先看日志，再看链路追踪，比如 Jaeger 或 Zipkin，确认是网关慢、服务慢，还是数据库慢。然后看线程池、连接池、GC、下游依赖。要是 Kafka 堆积，也可能造成整体延迟。
面试官：嗯，思路基本完整。今天就到这里，你回家等通知吧。
问题详解：结合电商与支付场景深入理解
1. 为什么选择 Spring Boot
在电商、支付这类快速迭代的系统中，Spring Boot 的价值主要在于自动配置、Starter 依赖管理、内嵌容器和较低的上手成本。传统 Spring MVC 往往需要手工配置大量 bean、视图解析器、数据源、事务管理器等，而 Spring Boot 通过约定优于配置的方式，把高频场景的默认配置封装起来。
业务上，这意味着新建一个订单服务时，可以更快打通 Web 层、缓存层、消息队列层和数据库层，特别适合多团队并行开发。
2. 订单创建与库存扣减的一致性
电商场景的核心问题是防超卖、保一致、可恢复。常见方案包括：
- 本地事务 + 异步消息：订单服务落库成功后发送 Kafka 消息，由库存服务异步扣减库存。
- 最终一致性：允许短时间内状态不一致，但通过补偿任务或消息重试最终收敛。
- 幂等设计：订单号、业务流水号做唯一键，避免重复提交导致多次扣减。
在高并发秒杀中，往往先在 Redis 中预扣库存，再异步落库，以减轻数据库压力。
3. Redis 在秒杀中的作用
Redis 常用于：热点商品缓存、库存预热、令牌桶限流、分布式锁、消息缓冲、会话存储等。秒杀时，将商品信息和库存放入 Redis，可以显著减少数据库读压力。若要防止并发超卖，可使用 Lua 脚本保证库存扣减的原子
