Java 大厂面试实录Spring Boot Kafka Redis OpenFeign 在电商秒杀场景中的 3 轮高频追问场景某互联网大厂 Java 面试业务方向为电商秒杀、订单履约与风控。第一轮基础与入口设计面试官先聊聊秒杀活动的接口设计。Spring Boot 启动后你怎么设计一个下单接口才能让它既容易扩展又能扛住高并发燕双非这个我会先用 Spring Boot 做 REST 接口前面加个网关限流再加 Redis 做库存预扣接口尽量无状态方便水平扩容。面试官思路是对的。那如果你要做接口幂等怎么避免重复下单燕双非嗯……可以用 JWT 里带个唯一 token提交一次后删掉后端再配合 Redis 的 setnx 或者数据库唯一索引。大概就是这样。面试官还不错至少知道幂等要前后端配合。继续说说库存校验放 Redis 里数据库最后落单为什么不直接查数据库燕双非因为数据库扛不住啊秒杀流量一上来直接查库就是“我太难了”。Redis 先挡一层数据库做最终一致性。面试官回答得比较到位继续保持。第二轮中间件与分布式协同面试官订单创建成功后你会怎么通知库存、积分、营销系统燕双非我会用 Kafka 发订单事件库存系统、积分系统、优惠券系统都去订阅。这样解耦峰值也能削平。面试官那 Kafka 消息重复消费怎么办燕双非嗯……消费者侧做幂等比如订单号做唯一键或者写消费日志表。反正消息来了别当成第一次就行。面试官可以。那订单服务调用库存服务、用户服务你会怎么控制超时和熔断燕双非用 OpenFeign 发起远程调用再配 Resilience4j 做超时、限流、熔断、降级。比如库存服务抖动时直接返回“活动火爆请稍后再试”。面试官很好这就是大厂里常见的容错思路。再往下支付回调进来后怎么保证状态流转正确燕双非支付回调先验签再查订单状态只有“待支付”才能改成“已支付”。如果 Kafka 里还有后续事件也得按状态机推进不能乱跳。面试官状态机意识不错说明你不是只会背 API。第三轮监控、排障与演进面试官如果秒杀活动上线后订单成功率突然下降你怎么排查燕双非先看 Prometheus 和 Grafana 的指标比如接口耗时、错误率、Kafka 积压、Redis 命中率再结合日志和链路追踪定位是网关、服务还是下游慢。面试官链路追踪你会怎么接燕双非可以接 Micrometer 打点结合 Jaeger 或 Zipkin 看 trace日志用 SLF4J 配 Logback统一 traceId方便串起来。面试官如果要把商品详情和推荐能力做得更智能一点你会怎么升级燕双非可以接 Spring AI给商品、评论、FAQ 做向量化放到 Milvus 或 Redis Vector 里做语义检索再用 RAG 做问答比如“这个商品适合什么人群”。面试官嗯已经开始像样了。那如果活动临近大促想减少人工运营配置你有什么想法燕双非可以做一个 Agent支持工具调用标准化自动去查库存、查活动、生成文案、回复客服不过得防止 AI 幻觉不然客服会把优惠券说飞了。面试官思路可以但细节还差火候。今天先到这儿你回去等通知吧。问题详解结合电商秒杀场景理解核心技术1. Spring Boot 秒杀接口为什么强调无状态无状态意味着实例之间不依赖本地会话方便通过 Kubernetes、Docker 或普通负载均衡做水平扩容。秒杀场景下请求量大、峰值集中服务最好做到“多开几台就能顶上去”。真正的状态应该放在 Redis、数据库或消息队列中。2. 幂等如何落地常见做法包括前端一次性 token、Redis setnx、数据库唯一索引、业务状态机校验、消费端去重表。比如订单号唯一重复请求再次进入时直接识别为重复提交并返回已有结果。3. 为什么先 Redis 再数据库Redis 适合高并发读写、低延迟库存预扣数据库负责最终持久化与强一致校验。秒杀的核心不是“每次都查到最准确库存”而是“先快速挡住大部分请求再由数据库兜底”。4. Kafka 在电商中的典型用途Kafka 常用于订单创建事件、库存扣减通知、营销积分发放、搜索索引更新、审计日志等。它的价值在于削峰填谷、解耦系统、便于异步扩展。但要注意重复消费、顺序性、消息积压和死信处理。5. 重复消费如何处理消费者端必须设计幂等。可以用业务主键做唯一约束或者用消费记录表标记某条消息是否已经处理。只要幂等做好Kafka 的“至少一次”语义通常可以被业务接受。6. OpenFeign Resilience4j 的意义OpenFeign 简化服务调用适合声明式远程访问Resilience4j 负责容错包括超时、限流、熔断、降级、重试等。大促时下游可能抖动容错组件能把故障控制在局部避免雪崩。7. 支付回调为何要先验签支付回调属于外部可信边界必须先验签防篡改再校验订单号、金额、商户号和当前状态。只有状态合法时才能推进到下一步避免重复回调导致多次发货。8. 监 Java 大厂面试实录：Spring Boot + Kafka + Redis + OpenFeign 在电商秒杀场景中的 3 轮高频追问
Java 大厂面试实录Spring Boot Kafka Redis OpenFeign 在电商秒杀场景中的 3 轮高频追问场景某互联网大厂 Java 面试业务方向为电商秒杀、订单履约与风控。第一轮基础与入口设计面试官先聊聊秒杀活动的接口设计。Spring Boot 启动后你怎么设计一个下单接口才能让它既容易扩展又能扛住高并发燕双非这个我会先用 Spring Boot 做 REST 接口前面加个网关限流再加 Redis 做库存预扣接口尽量无状态方便水平扩容。面试官思路是对的。那如果你要做接口幂等怎么避免重复下单燕双非嗯……可以用 JWT 里带个唯一 token提交一次后删掉后端再配合 Redis 的 setnx 或者数据库唯一索引。大概就是这样。面试官还不错至少知道幂等要前后端配合。继续说说库存校验放 Redis 里数据库最后落单为什么不直接查数据库燕双非因为数据库扛不住啊秒杀流量一上来直接查库就是“我太难了”。Redis 先挡一层数据库做最终一致性。面试官回答得比较到位继续保持。第二轮中间件与分布式协同面试官订单创建成功后你会怎么通知库存、积分、营销系统燕双非我会用 Kafka 发订单事件库存系统、积分系统、优惠券系统都去订阅。这样解耦峰值也能削平。面试官那 Kafka 消息重复消费怎么办燕双非嗯……消费者侧做幂等比如订单号做唯一键或者写消费日志表。反正消息来了别当成第一次就行。面试官可以。那订单服务调用库存服务、用户服务你会怎么控制超时和熔断燕双非用 OpenFeign 发起远程调用再配 Resilience4j 做超时、限流、熔断、降级。比如库存服务抖动时直接返回“活动火爆请稍后再试”。面试官很好这就是大厂里常见的容错思路。再往下支付回调进来后怎么保证状态流转正确燕双非支付回调先验签再查订单状态只有“待支付”才能改成“已支付”。如果 Kafka 里还有后续事件也得按状态机推进不能乱跳。面试官状态机意识不错说明你不是只会背 API。第三轮监控、排障与演进面试官如果秒杀活动上线后订单成功率突然下降你怎么排查燕双非先看 Prometheus 和 Grafana 的指标比如接口耗时、错误率、Kafka 积压、Redis 命中率再结合日志和链路追踪定位是网关、服务还是下游慢。面试官链路追踪你会怎么接燕双非可以接 Micrometer 打点结合 Jaeger 或 Zipkin 看 trace日志用 SLF4J 配 Logback统一 traceId方便串起来。面试官如果要把商品详情和推荐能力做得更智能一点你会怎么升级燕双非可以接 Spring AI给商品、评论、FAQ 做向量化放到 Milvus 或 Redis Vector 里做语义检索再用 RAG 做问答比如“这个商品适合什么人群”。面试官嗯已经开始像样了。那如果活动临近大促想减少人工运营配置你有什么想法燕双非可以做一个 Agent支持工具调用标准化自动去查库存、查活动、生成文案、回复客服不过得防止 AI 幻觉不然客服会把优惠券说飞了。面试官思路可以但细节还差火候。今天先到这儿你回去等通知吧。问题详解结合电商秒杀场景理解核心技术1. Spring Boot 秒杀接口为什么强调无状态无状态意味着实例之间不依赖本地会话方便通过 Kubernetes、Docker 或普通负载均衡做水平扩容。秒杀场景下请求量大、峰值集中服务最好做到“多开几台就能顶上去”。真正的状态应该放在 Redis、数据库或消息队列中。2. 幂等如何落地常见做法包括前端一次性 token、Redis setnx、数据库唯一索引、业务状态机校验、消费端去重表。比如订单号唯一重复请求再次进入时直接识别为重复提交并返回已有结果。3. 为什么先 Redis 再数据库Redis 适合高并发读写、低延迟库存预扣数据库负责最终持久化与强一致校验。秒杀的核心不是“每次都查到最准确库存”而是“先快速挡住大部分请求再由数据库兜底”。4. Kafka 在电商中的典型用途Kafka 常用于订单创建事件、库存扣减通知、营销积分发放、搜索索引更新、审计日志等。它的价值在于削峰填谷、解耦系统、便于异步扩展。但要注意重复消费、顺序性、消息积压和死信处理。5. 重复消费如何处理消费者端必须设计幂等。可以用业务主键做唯一约束或者用消费记录表标记某条消息是否已经处理。只要幂等做好Kafka 的“至少一次”语义通常可以被业务接受。6. OpenFeign Resilience4j 的意义OpenFeign 简化服务调用适合声明式远程访问Resilience4j 负责容错包括超时、限流、熔断、降级、重试等。大促时下游可能抖动容错组件能把故障控制在局部避免雪崩。7. 支付回调为何要先验签支付回调属于外部可信边界必须先验签防篡改再校验订单号、金额、商户号和当前状态。只有状态合法时才能推进到下一步避免重复回调导致多次发货。8. 监