企业官网建设流程全解析

Java 大厂面试实录：Spring Boot + Kafka + Redis + OAuth2 下的燕双非逆袭问答

场景：某互联网大厂 Java 岗位面试现场。

面试官：技术一把手，表情严肃，问题刁钻但有逻辑。

候选人：燕双非，外号“水货程序员”，擅长在简单题上侃侃而谈，遇到复杂问题开始含糊其辞。

第一轮：电商活动与订单链路

面试官：我们先聊一个活动场景。双十一秒杀页面由 Spring Boot 提供接口，你会怎么设计下单接口的基本结构，避免接口太重？

燕双非：这个简单，我一般会把接口拆成查询活动、校验库存、创建订单三个步骤，Controller 只负责接收参数，真正的业务放到 Service 里。还可以用 DTO 做参数隔离，避免前后端字段乱飞。

面试官：不错，至少知道分层。那如果活动流量大，你会怎么减少重复请求？

燕双非：嗯……可以用 Redis 做个幂等标记，比如用户点过一次就写个 key，过期时间设短一点。再配合前端按钮置灰，应该就差不多了。

面试官：思路基本对，能把业务和技术结合起来。那库存扣减放 Redis 还是数据库？为什么？

燕双非：库存嘛，当然先放 Redis，快。数据库最后再落。我觉得高并发先扛住再说，至于一致性……可以靠定时任务慢慢对一下。

面试官：好的，进入下一轮。

第二轮：订单消息化与安全接入

面试官：订单创建成功后，你希望通知库存、积分、物流三个系统，Kafka 和 RabbitMQ 你会怎么选？

燕双非：如果是这种解耦场景，我会倾向 Kafka，因为吞吐高，适合订单这种大流量业务。库存、积分、物流都订阅订单事件，各自消费自己的消息。

面试官：可以，能说出核心原因。那消息重复消费怎么办？

燕双非：这个……消费者那边做幂等呗，比如用订单号做唯一键，插库前先查一下有没有处理过。或者 Redis 也能记一下。反正核心就是别重复扣库存。

面试官：继续。用户登录态准备接 OAuth2，订单系统要给 App 提供授权访问，你怎么理解 JWT 和 OAuth2 的关系？

燕双非：OAuth2 是授权协议，JWT 是一种 token 格式。OAuth2 可以用 JWT 来做 access token，这样服务端少查数据库。用户拿 token 调接口，资源服务器验签就行。

面试官：回答得不错。那如果 token 被盗了，怎么降低风险？

燕双非：这个我觉得可以缩短 access token 有效期，再配 refresh token。再加上设备绑定、黑名单之类的……应该就比较稳了。

面试官：行，第三轮我们聊深入一点。

第三轮：可观测性、AI 与架构演进

面试官：现在公司想在订单客服里接入 AI 智能助手，支持用户用自然语言查订单、查退款、查物流。你会怎么做一个 RAG 系统？

燕双非：先把订单、售后、物流文档做文档加载，然后切分成 chunk，向量化后存进向量数据库，比如 Milvus 或 Redis。用户提问时先做语义检索，再把检索结果拼到提示词里交给大模型生成回答。

面试官：不错，已经能讲到 Agent 和 RAG 结合了。那如果用户问的问题很复杂，比如“上周五买的那单为什么退款失败”，你怎么保证答案可靠？

燕双非：那就不能只靠大模型胡说了，得让 Agent 调用订单查询、退款状态、风控结果这些工具，拿到真实业务数据后再回答。还能加一个提示填充模板，把角色、约束、事实来源都写清楚，减少幻觉。

面试官：好，说明你至少知道 AI 不是纯聊天。最后一个问题，怎么监控这条链路的性能？

燕双非：接口层可以用 Micrometer 打点，Prometheus 抓指标，Grafana 看图。消息链路还可以加 traceId，配合 Jaeger 或 Zipkin 跟踪。要是线上慢了，就能定位是接口、缓存还是 Kafka 消费慢。

面试官：说得还算完整。今天就到这里，你回家等通知吧。

所有面试题详细解答

1. Spring Boot 下如何设计高并发活动接口

在电商秒杀、抢券、限时活动中，接口设计的关键是轻量化和可扩展。Controller 只做参数接收和返回，核心业务进入 Service。查询、库存校验、创建订单可以拆分为独立方法，便于后续做限流、熔断、降级和异步化。

业务上应优先减少同步链路耗时，例如将风控校验、积分发放等非核心动作拆到异步消息中。对于热点接口，可结合缓存、预热、静态化页面等手段降低后端压力。

2. Redis 幂等与库存预扣减

对于重复点击、网络重试等场景，Redis 非常适合做幂等标记。可以使用用户 ID、活动 ID、商品 ID 组合成唯一键，首次请求写入成功后，后续请求直接拒绝。

库存扣减通常有两类思路：一种是直接在数据库中事务扣减，简单但抗压差；另一种是 Redis 预扣减，先在缓存中原子减少库存，订单成功后异步落库。后者适合高并发，但必须处理缓存与数据库的一致性、补偿机制和异常恢复。

3. Kafka 适合什么样的业务事件

Kafka 适合高吞吐、可堆积、可回放的事件流场景，比如订单创建、支付成功、用户行为埋点、日志采集等。订单系统创建成功后发布订单事件，库存、积分、物流等服务各自消费，能有效解耦。

需要注意的是，Kafka 更偏向日志流和事件流，不适合强事务、超低延迟、严格顺序的复杂业务控制。实际项目中通常会结合幂等、重试、死信处理、补偿任务一起使用。

4. 消息重复消费如何处理

分布式环境中重复消费不可避免，因此消费者必须具备幂等性。常见做法包括：

• 以业务唯一键建唯一索引，重复插入时直接失败。
• 在数据库记录处理状态，消费前检查状态。
• 使用