ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

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

2026/9/4 17:55:02 拓冰建站 浏览量
Java 大厂面试实录:Spring Boot + Kafka + Redis + OAuth2 下的燕双非逆袭问答 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. 消息重复消费如何处理分布式环境中重复消费不可避免因此消费者必须具备幂等性。常见做法包括以业务唯一键建唯一索引重复插入时直接失败。在数据库记录处理状态消费前检查状态。使用