场景互联网大厂 Java 面试面试官神情严肃候选人燕双非一脸自信地坐下。面试官今天我们不聊虚的直接上业务和技术。你如果真懂就把问题讲透如果只是会背就很快会露馅。燕双非放心吧老师我这个人最大的优点就是懂一点敢说两句。第一轮电商秒杀链路与系统基础面试官我们先聊一个电商大促场景。Spring Boot 在你搭建秒杀服务时为什么比传统 Spring MVC XML 更适合快速迭代燕双非因为 Spring Boot 开箱即用内嵌 Tomcat少配置启动快适合快速上线。我们做秒杀接口的时候可以直接按约定开发少写很多样板代码。面试官说得不错至少方向对。那如果 QPS 突然冲到十万级你会怎么保护库存接口燕双非先限流再缓存再异步削峰。热点商品可以放 Redis 预热库存扣减先走 Lua 脚本保证原子性失败了再做补偿。面试官继续Redis 里你会怎么设计库存预扣和回补燕双非我会把库存数和订单占用数分开预扣成功后写入待支付状态。如果超时未支付通过消息队列或者延迟任务回补库存。面试官不错已经能把链路串起来了。那这一层为什么还要 Kafka而不是直接同步调库存服务燕双非同步调用太慢也容易把下游压垮。Kafka 可以做削峰填谷把下单结果异步通知库存、支付、风控等服务主链路更稳。第二轮支付、鉴权与消息可靠性面试官现在进入支付场景。订单创建后如何用 Spring Security JWT 做用户鉴权燕双非登录后签发 JWT前端带着 token 调接口。Spring Security 拦截请求解析 token校验签名、过期时间和权限。面试官如果是多端登录和 token 续期你怎么处理燕双非可以做 refresh token 机制短 token 长 token 组合。敏感操作再加二次校验比如短信或设备校验。面试官很好。那 Kafka 消息在支付回调里可能重复投递你如何保证幂等燕双非我会用订单号做幂等键数据库加唯一索引消费时先查状态再更新。消息消费成功后再提交 offset避免重复处理。面试官假如库存、订单、支付分别在不同服务你怎么处理分布式一致性问题燕双非能用最终一致性就别硬刚强一致。一般用 Saga 或本地消息表先落库再发消息失败重试配合补偿任务。面试官那你觉得 HikariCP 相比 C3P0 的价值是什么燕双非HikariCP 性能更好连接池更轻量延迟更低适合高并发场景。面试官回答到位。说明你至少知道为什么线上系统会偏向 HikariCP。第三轮AI 导购与云原生演进面试官假设我们把电商搜索升级成 AI 导购用户可以直接问“帮我找适合跑步的轻量跑鞋”你会怎么设计基于 Spring AI RAG 的方案燕双非先把商品、评论、FAQ、退换货政策做文档加载和切片然后向量化存到向量数据库里。用户提问后做语义检索把相关上下文拼进提示词再交给大模型生成回答。面试官很好。那 Agent 在这个场景里能做什么燕双非Agent 可以把“查库存、比价格、看尺码、查物流”这些动作串起来自动决定调用哪个工具。这样就不只是回答问题还能完成任务。面试官如果大模型出现幻觉推荐了不存在的商品怎么办燕双非要做检索增强回答必须基于召回结果同时对生成内容做校验必要时只输出结构化结果不让模型自由发挥太多。面试官最后一个问题随着业务增长你怎么把这个系统部署到 Kubernetes 上并保证可观测性燕双非服务容器化后部署到 Kubernetes配合 Prometheus、Grafana 和 Micrometer 做监控日志走 ELK链路追踪可以接 Jaeger 或 Zipkin。出问题时能快速定位。面试官行今天先到这里。整体来看你有些点答得还可以但也有些地方比较飘。你回去等通知吧。问题详解与知识总结1. Spring Boot 为什么适合秒杀系统在电商大促中Spring Boot 的优势不只是“启动快”更关键的是它能帮助团队快速构建稳定可演进的服务。它提供自动配置、内嵌容器、统一的依赖管理便于把秒杀、订单、支付等服务快速拆分为独立微服务。在高并发场景下快速迭代和统一治理比传统 XML 配置更重要。2. 库存预扣与 Redis 原子操作秒杀常用“预扣库存 异步确认”模型。Redis 可以作为高性能缓存和计数器借助 Lua 脚本实现检查和扣减的原子性避免超卖。预扣成功后订单进入待支付状态若超时未支付再通过延迟消息或定时任务回补库存形成闭环。3. Kafka 在削峰填谷中的作用Kafka 适合承接大流量异步事件比如下单成功、支付成功、库存回补等。主链路只负责快速响应耗时操作全部异步化。这样既能降低接口 RT也能让库存、物流、营销等下游服务按自身能力消费消息避免级联故障。4. Spring Security JWT 的典型实践JWT 适合无状态鉴权服务端无需保存 session扩展性更好。常见做法是 access token 短有效期、refresh token 长有效期配合设备指纹、黑名单、敏感操作二次验证兼顾安全与体验。Spring Security 负责统一拦截和权限控制。5. 消息幂等与分布式一致性消息队列天然可能重复投递因此消费者必须 Java面试实录：Spring Boot + Kafka + Redis + MCP 的大厂求职三轮过招
场景互联网大厂 Java 面试面试官神情严肃候选人燕双非一脸自信地坐下。面试官今天我们不聊虚的直接上业务和技术。你如果真懂就把问题讲透如果只是会背就很快会露馅。燕双非放心吧老师我这个人最大的优点就是懂一点敢说两句。第一轮电商秒杀链路与系统基础面试官我们先聊一个电商大促场景。Spring Boot 在你搭建秒杀服务时为什么比传统 Spring MVC XML 更适合快速迭代燕双非因为 Spring Boot 开箱即用内嵌 Tomcat少配置启动快适合快速上线。我们做秒杀接口的时候可以直接按约定开发少写很多样板代码。面试官说得不错至少方向对。那如果 QPS 突然冲到十万级你会怎么保护库存接口燕双非先限流再缓存再异步削峰。热点商品可以放 Redis 预热库存扣减先走 Lua 脚本保证原子性失败了再做补偿。面试官继续Redis 里你会怎么设计库存预扣和回补燕双非我会把库存数和订单占用数分开预扣成功后写入待支付状态。如果超时未支付通过消息队列或者延迟任务回补库存。面试官不错已经能把链路串起来了。那这一层为什么还要 Kafka而不是直接同步调库存服务燕双非同步调用太慢也容易把下游压垮。Kafka 可以做削峰填谷把下单结果异步通知库存、支付、风控等服务主链路更稳。第二轮支付、鉴权与消息可靠性面试官现在进入支付场景。订单创建后如何用 Spring Security JWT 做用户鉴权燕双非登录后签发 JWT前端带着 token 调接口。Spring Security 拦截请求解析 token校验签名、过期时间和权限。面试官如果是多端登录和 token 续期你怎么处理燕双非可以做 refresh token 机制短 token 长 token 组合。敏感操作再加二次校验比如短信或设备校验。面试官很好。那 Kafka 消息在支付回调里可能重复投递你如何保证幂等燕双非我会用订单号做幂等键数据库加唯一索引消费时先查状态再更新。消息消费成功后再提交 offset避免重复处理。面试官假如库存、订单、支付分别在不同服务你怎么处理分布式一致性问题燕双非能用最终一致性就别硬刚强一致。一般用 Saga 或本地消息表先落库再发消息失败重试配合补偿任务。面试官那你觉得 HikariCP 相比 C3P0 的价值是什么燕双非HikariCP 性能更好连接池更轻量延迟更低适合高并发场景。面试官回答到位。说明你至少知道为什么线上系统会偏向 HikariCP。第三轮AI 导购与云原生演进面试官假设我们把电商搜索升级成 AI 导购用户可以直接问“帮我找适合跑步的轻量跑鞋”你会怎么设计基于 Spring AI RAG 的方案燕双非先把商品、评论、FAQ、退换货政策做文档加载和切片然后向量化存到向量数据库里。用户提问后做语义检索把相关上下文拼进提示词再交给大模型生成回答。面试官很好。那 Agent 在这个场景里能做什么燕双非Agent 可以把“查库存、比价格、看尺码、查物流”这些动作串起来自动决定调用哪个工具。这样就不只是回答问题还能完成任务。面试官如果大模型出现幻觉推荐了不存在的商品怎么办燕双非要做检索增强回答必须基于召回结果同时对生成内容做校验必要时只输出结构化结果不让模型自由发挥太多。面试官最后一个问题随着业务增长你怎么把这个系统部署到 Kubernetes 上并保证可观测性燕双非服务容器化后部署到 Kubernetes配合 Prometheus、Grafana 和 Micrometer 做监控日志走 ELK链路追踪可以接 Jaeger 或 Zipkin。出问题时能快速定位。面试官行今天先到这里。整体来看你有些点答得还可以但也有些地方比较飘。你回去等通知吧。问题详解与知识总结1. Spring Boot 为什么适合秒杀系统在电商大促中Spring Boot 的优势不只是“启动快”更关键的是它能帮助团队快速构建稳定可演进的服务。它提供自动配置、内嵌容器、统一的依赖管理便于把秒杀、订单、支付等服务快速拆分为独立微服务。在高并发场景下快速迭代和统一治理比传统 XML 配置更重要。2. 库存预扣与 Redis 原子操作秒杀常用“预扣库存 异步确认”模型。Redis 可以作为高性能缓存和计数器借助 Lua 脚本实现检查和扣减的原子性避免超卖。预扣成功后订单进入待支付状态若超时未支付再通过延迟消息或定时任务回补库存形成闭环。3. Kafka 在削峰填谷中的作用Kafka 适合承接大流量异步事件比如下单成功、支付成功、库存回补等。主链路只负责快速响应耗时操作全部异步化。这样既能降低接口 RT也能让库存、物流、营销等下游服务按自身能力消费消息避免级联故障。4. Spring Security JWT 的典型实践JWT 适合无状态鉴权服务端无需保存 session扩展性更好。常见做法是 access token 短有效期、refresh token 长有效期配合设备指纹、黑名单、敏感操作二次验证兼顾安全与体验。Spring Security 负责统一拦截和权限控制。5. 消息幂等与分布式一致性消息队列天然可能重复投递因此消费者必须 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
