Java 面试实战：Spring Boot + Kafka + Redis + MyBatis + Spring Security 高并发电商场景深挖

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

人物：严肃面试官 vs 搞笑的水货程序员「燕双非」

第一轮：订单链路基础与并发控制

面试官：你先说说，一个电商下单接口用 Spring Boot 落地时，最基础的分层设计怎么做？

燕双非：Controller 接请求，Service 写业务，Mapper 负责查库。再配个 DTO、VO，差不多就稳了。

面试官：回答得不错，先把职责分开是对的。那如果是秒杀活动，下单接口怎么避免超卖？

燕双非：我一般先在 Redis 里预扣库存，扣成功再发消息到 Kafka，让异步订单服务慢慢落库。数据库那边再加乐观锁兜底，应该……就不太会超卖了。

面试官：思路基本正确。那你说说 MyBatis 在这种场景下，库存扣减 SQL 该怎么写更安全？

燕双非：大概就是 update stock = stock - 1 where id = ? and stock > 0，这样更新返回 1 才算成功，不然就是没库存了。

面试官：嗯，这个点很关键。最后一个问题，如果接口突然被大量重复提交，你怎么处理？

燕双非：加个幂等 token，前端提交一次，后端 Redis 校验一次，消费 Kafka 的时候再按订单号去重。

第二轮：安全、缓存与可观测性

面试官：如果这个电商系统接入登录和支付，你会怎么设计 Spring Security 和 JWT 的配合？

燕双非：登录成功后签一个 JWT，客户端带着 token 访问接口，Spring Security 里写个过滤器解析 token，然后把用户信息放进上下文。

面试官：不错。那如果 token 被盗了，或者想主动失效，怎么办？

燕双非：这个……可以加黑名单，或者把 JWT 的过期时间设短一点，再配合刷新 token。要是更严格，还能结合 Redis 存一个 jti 状态。

面试官：可以。现在系统有热点商品缓存，Redis 命中率很高，但偶发缓存击穿，你怎么分析和解决？

燕双非：热点 key 过期瞬间大量请求打到数据库，可以加互斥锁、防止并发重建；也可以逻辑过期，后台异步刷新。

面试官：那你会怎么监控这套链路的性能？

燕双非：用 Micrometer 打指标，接 Prometheus 和 Grafana 看 QPS、延迟、错误率；日志再进 ELK，链路追踪可以用 Zipkin 或 Jaeger。

面试官：说得还行。最后，如果订单接口偶发变慢，你第一步怎么看？

燕双非：先看接口耗时分布，再看数据库慢查询、Redis 延迟、Kafka 堆积和线程池饱和情况，别一上来就甩锅 JVM。

第三轮：微服务、云原生与面试加压

面试官：如果订单服务要拆成微服务，你会怎么用 OpenFeign、Kafka 和 Resilience4j 组织链路？

燕双非：同步查用户和商品信息可以用 OpenFeign，创建订单后发 Kafka 事件给库存和积分服务，远程调用加超时、重试和熔断，Resilience4j 负责兜底。

面试官：那服务发现和配置中心你倾向怎么选？

燕双非：如果是 Spring Cloud 体系，常见会接 Nacos、Consul 或 Eureka；配置可以统一管理，避免每个服务自己改一份。

面试官：好。现在你把系统部署到 Kubernetes，上线后发现消费 Kafka 的 Pod 经常水平扩容，你怎么保证稳定性？

燕双非：我会看消费者分区数和实例数是否匹配，保证单分区同一时刻只有一个消费者处理；扩容时注意 rebalance 影响，必要时调优批量拉取和并发度。

面试官：最后一个压轴题：如果要给这个电商系统加一个“商品智能推荐助手”，你怎么理解 Spring AI、RAG 和向量检索的结合？

燕双非：大概就是把商品、FAQ、活动规则做文档加载和向量化，放到向量数据库里；用户提问时先语义检索，再把检索结果拼进提示词交给模型生成答案。要减少幻觉，最好只让它基于企业知识库回答。

面试官：这题答得比前面成熟多了，说明你还是有一定底子的。不过还有些细节需要继续打磨。

面试官：今天先到这里，你回家等通知吧。

面试问题详细解析

1. Spring Boot 分层设计与电商下单链路

在电商系统中，Controller 负责接收请求并做参数校验，Service 承载核心业务规则，Mapper/Repository 负责持久化。DTO/VO 的引入可以让接口模型和内部模型解耦，避免实体对象直接暴露到前端。

对于秒杀场景，核心难点是并发与一致性。常见做法是：

• Redis 预扣库存，快速拦截超卖请求。
• Kafka 异步削峰，把下单事件推送给订单、库存、积分等下游服务。
• 数据库层使用乐观锁或条件更新兜底，确保最终一致。

MyBatis 的条件更新 SQL 是经典方案：update sku_stock set stock = stock - 1 where sku_id = ? and stock > 0。如果更新行数为 1，说明扣减成功；如果为 0，说明库存不足。

幂等控制也非常关键。常见做法包括幂等 token、业务唯一键、Redis 去重、消息消费去重表等。

2. Spring Security + JWT 的认证与失效控制

JWT 的优点是无状态，适合分布式系统。典型流程是：用户登录后由认证服务签发 JWT，客户端在后续请求中携带 token，Spring Security 的过滤器负责解析、验证并构建认证信息。

JWT 的缺点是签发后不易主动失效，因此通常要结合：

• 较短的 access token 有效期。
• refresh token 用于续期。
• Redis 黑名单或 jti 状态表实现主动失效。

如果业务对安全要求更高，可以结合 OAuth2、Keycloak 或更严格的会话管理策略。

3. Redis 缓存击穿与热点保护

缓存击穿通常发生在热点 key 失效瞬间，大量并发同时回源数据库。应对策略包括：

• 互斥锁：只有一个线程重建缓存，其余线程等待。
• 逻辑过期：缓存不过期，后台异步刷新。
• 热点 key 永不过期或延长过期时间。
• 热点隔离：将极热数据与普通数据分层处理。

在电商场景中，商品详情、秒杀库存、营销活动配置都属于高频热点数据，缓存策略设计得好不好，直接影响系统稳定性。

4. Micrometer、Prometheus、Grafana 与日志/链路追踪

Micrometer 是 Java 生态常见的指标门面层，可以统一采集 QPS、耗时、错误数、JVM 指标等。Prometheus 负责抓取并存储时序指标，Grafana 负责可视化。

日志通常用 SLF4J 作为门面，底层接 Logback 或 Log4j2，并汇聚到 ELK 平台。链路追踪则常配合 Zipkin、Jaeger，用于定位一次请求在多个微服务中的耗时分布。

当订单接口变慢时，排查顺序通常是：接口层 → 服务层 → DB → 缓存 → MQ → 外部依赖 → JVM/线程池。

5. OpenFeign、Kafka 与 Resilience4j 的微服务链路

在微服务拆分后，同步调用适合查询类、强实时类场景，例如用户信息、商品详情。OpenFeign 可以简化 HTTP 调用。

对于订单创建后的异步处理，比如扣库存、发优惠券、发短信，Kafka 非常适合做事件驱动架构。这样可以降低主链路响应时间，并且提高系统可扩展性。

Resilience4j 则用于保护下游服务，常见能力包括：

• 超时控制
• 限流
• 熔断
• 隔离
• 重试

但重试不能滥用，否则可能放大流量风暴。

6. Kubernetes 下的 Kafka 消费者扩容与稳定性

Kafka 的消费能力与分区数、消费者实例数、处理耗时相关。扩容 Pod 后，若消费者组发生频繁 rebalance，可能会造成消费抖动。

实践中需要关注：

• 分区数是否足够支撑并发扩展。
• 单条消息处理时间是否过长。
• 批量拉取参数是否合理。
• 幂等消费是否完善。
• Pod 的资源限制与 JVM 参数是否匹配。

如果是订单、库存这类强业务链路，最好设计成可重复消费、可补偿、可追踪。

7. Spring AI、RAG 与向量检索在电商智能助手中的应用

在智能客服或商品推荐助手中，RAG 的核心流程是：

1. 将商品信息、活动规则、FAQ、售后政策等文档加载进知识库。
2. 对文本进行切片与向量化，存入向量数据库，如 Milvus、Chroma 或 Redis 向量能力。
3. 用户提问时先做语义检索，找到最相关的知识片段。
4. 把检索结果与提示词一起送给大模型生成回答。

这种方式能显著降低 AI 幻觉，让模型“有据可依”。对于企业场景，关键不是让模型“什么都知道”，而是让它“只基于可信知识回答”。

Agent、工具调用标准化、复杂工作流、聊天会话内存等能力，可以进一步支持查订单、查物流、改地址等自动化业务。

8. 总结

这套面试题从单体下单、缓存与安全、再到微服务与 AI 增强，基本覆盖了互联网大厂常见的 Java 面试深挖路径。回答时最重要的不是背概念，而是要能把技术和业务场景连接起来，讲清楚为什么这么设计、有什么收益、有哪些坑。

感谢阅读，希望这篇文章能帮助到正在准备 Java 面试的你，祝你面试顺利，拿到理想的 offer！