谢飞机面Java大厂：从Spring Boot到K8s的3轮爆笑面试实录（附全技术点解析）

面试官：严肃如JVM GC日志，谢飞机：糊弄如ThreadLocal内存泄漏……

---

🎬 第一轮：电商秒杀场景下的基础功底（Spring Boot + Redis + MySQL）

面试官（推了推眼镜）：谢同学，假设你负责一个双11秒杀系统，QPS预估5万。第一个问题：如何用Spring Boot快速搭建一个可监控、可灰度的秒杀API？

谢飞机：啊？这个…我用@RestController写个/seckill，加个@PostMapping，再return "success"…（挠头）

面试官（微笑）：不错，至少知道入口在哪。那第二个问题：库存扣减怎么防超卖？Redis和MySQL怎么协同？

谢飞机：呃…我用RedisTemplate.opsForValue().decrement()…然后查数据库？不对不对…（擦汗）是不是先Redis扣，再异步落库？

面试官（点头）：方向对了一半——但漏了原子性。第三个问题：如果Redis扣成功、DB落库失败，怎么回滚？

谢飞机：……（沉默5秒）那个…我加个@Transactional？

面试官（轻笑）：@Transactional管不了Redis哦。先记下，我们后面再展开。

---

🚀 第二轮：微服务治理与高可用（Spring Cloud + Resilience4j + Kafka）

面试官：现在秒杀服务拆成了seckill-service、inventory-service、order-service三个微服务。第四个问题：用户下单后，如何保证订单创建和库存扣减的最终一致性？

谢飞机：Kafka！发个OrderCreatedEvent，库存服务监听消费…

面试官（赞许）：很好！那第五个问题：如果库存服务宕机3分钟，消息堆积怎么办？消费者怎么避免重复消费？

谢飞机：啊？重试？我…加个@Retryable？

面试官：@Retryable是生产者重试，不是消费者幂等。第六个问题：用Resilience4j实现熔断降级，当inventory-service响应超时>200ms且错误率>50%，如何自动熔断并返回兜底库存？

谢飞机：（翻手机备忘录）…好像是配个CircuitBreakerConfig？然后…decorateSupplier？（声音渐弱）

面试官（温和）：思路有，细节待补。我们进第三轮。

---

☁️ 第三轮：云原生可观测与安全加固（K8s + Prometheus + Spring Security OAuth2）

面试官：服务已上K8s。第七个问题：如何用Prometheus+Micrometer暴露秒杀QPS、平均延迟、熔断触发次数这3个核心指标？

谢飞机：加micrometer-registry-prometheus依赖…然后MeterRegistry注入…（突然抬头）啊！还要配/actuator/prometheus端点！

面试官（首次露出笑容）：完全正确！加分！第八个问题：现在要对接微信小程序登录，用OAuth2授权码模式，seckill-service作为资源服务器，如何校验JWT中的scope=seckill:write？

谢飞机：@EnableResourceServer…（卡住）那个…JwtAuthenticationConverter？

面试官：接近了，但Spring Boot 3.x已废弃该注解，改用jwtDecoder() Bean + SecurityFilterChain配置。第九个问题：若某次发布后，秒杀接口P99延迟从80ms飙升至1.2s，你如何用ELK+Jaeger快速定位是DB慢SQL、Redis阻塞还是线程池打满？

谢飞机：（深呼吸）查traceId…看Jaeger链路…再grep日志…（小声）应该…不是我的锅…

面试官（合上笔记本）：谢同学，今天就到这里。你对主流技术栈有基本认知，也展现出不错的学习意愿和临场反应。回去可以重点补一补分布式事务、云原生可观测性链路和OAuth2演进实践。我们HR会在5个工作日内通知结果。

---

✅ 全技术点详解（小白友好版）

🔹 场景锚定：电商秒杀（高并发、强一致性、低延迟）

• 为什么选它？ 覆盖Java全技术栈高频考点：Web层（Spring Boot）、缓存（Redis）、DB（MySQL+分库分表）、异步（Kafka）、容错（Resilience4j）、部署（K8s）、监控（Prometheus）、安全（OAuth2）。

🔹 问题1-3：Spring Boot + Redis + MySQL 防超卖

• 技术点：@RestController是Spring MVC标准入口；Redis atomic decrement保障扣减原子性；但Redis与MySQL数据不一致风险必须通过可靠消息+本地事务表或Seata AT模式解决——@Transactional只管DB，Redis需手动补偿（如TCC模式）。

🔹 问题4-6：Kafka最终一致性 + Resilience4j熔断

• 关键设计：订单服务发Kafka消息 → 库存服务消费 → 成功则ACK，失败则进DLQ；幂等性靠业务主键（如order_id）+ DB唯一索引；Resilience4j需配置slidingWindowType = COUNT_BASED + failureRateThreshold = 50 + waitDurationInOpenState = 60s。

🔹 问题7-9：云原生可观测性 + OAuth2演进

• Prometheus指标：Counter记录QPS（seckill_requests_total），Timer记录延迟（seckill_latency_seconds），Gauge记录熔断状态（resilience4j_circuitbreaker_state）；
• Spring Security 6+ OAuth2：弃用@EnableResourceServer，改用http.oauth2ResourceServer(OAuth2ResourceServerConfigurer::jwt) + 自定义JwtDecoder校验scope；
• 性能定位三板斧： 1️⃣ Jaeger查/seckill链路，看哪个Span耗时突增； 2️⃣ ELK中grep traceId | grep "slow"找慢SQL日志； 3️⃣ kubectl top pods查CPU/MEM，jstack <pid>看线程堆栈是否BLOCKED。

💡 小白行动清单：

• 本周：手写Redis+MySQL库存扣减补偿逻辑（含重试+死信）
• 下周：用K8s部署Spring Boot+Prometheus+Grafana看板
• 下月：用Spring Authorization Server搭建OAuth2认证中心

---

本文基于真实大厂面试题提炼，覆盖Java后端18类技术栈，建议收藏反复研读。