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客户端在后续请求中携带 tokenSpring 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 的核心流程是将商品信息、活动规则、FAQ、售后政策等文档加载进知识库。对文本进行切片与向量化存入向量数据库如 Milvus、Chroma 或 Redis 向量能力。用户提问时先做语义检索找到最相关的知识片段。把检索结果与提示词一起送给大模型生成回答。这种方式能显著降低 AI 幻觉让模型“有据可依”。对于企业场景关键不是让模型“什么都知道”而是让它“只基于可信知识回答”。Agent、工具调用标准化、复杂工作流、聊天会话内存等能力可以进一步支持查订单、查物流、改地址等自动化业务。8. 总结这套面试题从单体下单、缓存与安全、再到微服务与 AI 增强基本覆盖了互联网大厂常见的 Java 面试深挖路径。回答时最重要的不是背概念而是要能把技术和业务场景连接起来讲清楚为什么这么设计、有什么收益、有哪些坑。感谢阅读希望这篇文章能帮助到正在准备 Java 面试的你祝你面试顺利拿到理想的 offer Java 面试实战：Spring Boot + Kafka + Redis + MyBatis + Spring Security 高并发电商场景深挖
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客户端在后续请求中携带 tokenSpring 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 的核心流程是将商品信息、活动规则、FAQ、售后政策等文档加载进知识库。对文本进行切片与向量化存入向量数据库如 Milvus、Chroma 或 Redis 向量能力。用户提问时先做语义检索找到最相关的知识片段。把检索结果与提示词一起送给大模型生成回答。这种方式能显著降低 AI 幻觉让模型“有据可依”。对于企业场景关键不是让模型“什么都知道”而是让它“只基于可信知识回答”。Agent、工具调用标准化、复杂工作流、聊天会话内存等能力可以进一步支持查订单、查物流、改地址等自动化业务。8. 总结这套面试题从单体下单、缓存与安全、再到微服务与 AI 增强基本覆盖了互联网大厂常见的 Java 面试深挖路径。回答时最重要的不是背概念而是要能把技术和业务场景连接起来讲清楚为什么这么设计、有什么收益、有哪些坑。感谢阅读希望这篇文章能帮助到正在准备 Java 面试的你祝你面试顺利拿到理想的 offer