Java 大厂面试实录：Spring Boot + MyBatis + Redis + Kafka + Spring Security + AI 场景深挖

Java 大厂面试实录Spring Boot MyBatis Redis Kafka Spring Security AI 场景深挖场景互联网大厂 Java 求职面试业务为“本地生活服务平台 AI 智能客服 订单与营销系统”第一轮下单链路与接口设计面试官你先说说本地生活平台里用户从浏览商家到下单后端接口一般怎么拆燕双非我一般会拆成商家列表、商详、购物车、提交订单、支付回调这几块。前端按页面调用后端按领域接口设计尽量让一个接口只做一件事。面试官不错先从业务切入口说结构思路是对的。那如果商家详情接口要聚合门店信息、活动信息、评价信息你会怎么做燕双非可以做一个聚合层调用多个下游服务然后组装成 DTO 返回。也可以用缓存先挡一层热点商家详情直接读 Redis。面试官嗯知道聚合和缓存基本功还行。那你说说 Spring Boot 里怎么避免接口慢是不是把所有调用都同步串行就行燕双非那肯定不行串行太慢了。可以并行调用比如用线程池或者 WebFlux 的方式并发拉取数据不过线程池得注意隔离和超时不然容易拖垮主流程。面试官好知道并发和超时控制说明不是纯水货。第二轮订单、缓存、消息与风控面试官订单创建时库存扣减、优惠券核销、支付冻结这几个动作怎么保证一致性燕双非这个一般不能全靠数据库事务硬扛跨服务就麻烦了。可以先落订单主记录再通过 Kafka 发消息做异步处理失败就重试或者补偿。重要的是要有幂等设计。面试官说得比刚才深入了。那幂等你怎么做燕双非可以用业务唯一号比如订单号、请求号做幂等键先查 Redis 或数据库有没有处理过或者在表里加唯一索引重复请求直接拦住。面试官可以幂等键和唯一索引都很常见。那 Redis 在这条链路里除了缓存商详还能干什么燕双非还能做分布式锁、限流、验证码、购物车、热点活动的库存预热。比如秒杀活动可以先把库存放 Redis再通过 Lua 脚本原子扣减。面试官答得不错已经接近实战了。那 Spring Security 和 JWT 在登录态里怎么配合燕双非用户登录后签发 JWT前端每次带 token 访问接口后端在过滤器里校验 token再把用户信息放到上下文。至于权限控制可以按角色和资源做鉴权。面试官还行。那如果是商家后台还要接入 OAuth2 单点登录你会怎么理解燕双非就是统一认证中心发令牌商家系统当客户端去拿授权。这个我理解是把登录和业务系统解耦方便多系统共享账号体系。第三轮AI 智能客服与可观测性面试官现在平台想做 AI 智能客服接入商品、退款、配送规则知识库。你会怎么设计燕双非我会先把文档切分后做向量化存到向量数据库里用户提问时先做语义检索再把检索结果拼到提示词里给大模型形成 RAG。这样比纯生成更靠谱。面试官这个方向对至少知道 RAG 的核心。那如果知识库更新很频繁怎么避免模型答非所问燕双非我觉得要控制文档加载和索引刷新频率必要时做增量更新另外提示词里要限制模型只能基于检索到的内容回答减少幻觉。面试官不错知道幻觉控制。那 AI 客服还要能调用订单查询、退款申请这些工具你怎么理解工具调用燕双非应该是把工具标准化成一组接口让 Agent 根据用户意图选择调用。比如先查订单再判断能不能退款最后再去执行动作这种就是有流程的智能代理。面试官回答得比前面完整了。最后一个问题系统上线后你怎么排查“客服回答慢、下单也慢”的问题燕双非我会先看链路监控和日志定位是接口慢、数据库慢还是消息堆积。再看 Prometheus、Grafana 指标配合链路追踪工具查耗时分布。数据库侧看连接池、慢 SQL、索引消息侧看消费积压AI 侧看检索耗时和模型响应时间。面试官思路比较完整今天先到这你回家等通知吧。问题详解1. 本地生活平台接口如何拆分与聚合本地生活类业务通常围绕“浏览—下单—支付—履约—评价”主链路展开。接口拆分时应遵循领域边界清晰、单一职责、便于缓存和并发优化的原则。商家列表、商家详情、优惠活动、评价信息等通常属于不同服务或不同数据源前端展示层可以通过聚合接口统一返回。聚合时要注意超时控制、降级策略和并行调用避免某个下游拖慢整体响应。对于热点详情页可使用 Redis 缓存加速并设置合理过期时间和主动失效策略。2. 并行调用与响应优化怎么做在 Java 生态中常见做法包括线程池并发、CompletableFuture、Spring WebFlux 非阻塞方式等。在线程池场景下要做好线程隔离、队列大小控制和超时回收避免高并发时线程资源耗尽。WebFlux 适合 I/O 密集型场景但要注意整个调用链是否都支持响应式否则收益有限。实际业务中选择哪种方式取决于系统改造成本、团队熟悉度和性能瓶颈所在。3. 订单一致性、幂等与消息驱动如何结合订单创建涉及库存、优惠券、支付等多个环节跨服务强一致通常成本高因此更常采用“本地事务 事件驱动 最终一致性”的方式。主订单先落库再通过 Kafka 等消息队列发送事件下游服务异步处理库存扣减、券核销等动作。为了应对消息重复投递、接口重试和用户重复点击必须设计幂等机制。常见方案包括业务唯一键、请求号去重、数据库唯一索引、Redis 去重标记等。补偿机制同样重要能在部分失败时通过重试或人工介入恢复状态。4. Redis 在业务中有哪些典型作用Redis 不只是缓存还常被用于分布式锁、限流、会话存储、验证码、计数器、热点数据预热等。对于秒杀或大促常用 Lua 脚本保证库存扣减原子性防止超卖。对于购物车、用户行为计数、活动状态也适合用 Redis 承载高频读写。使用时要注意缓存穿透、击穿、雪崩问题可以通过布隆过滤器、热点 key 保护、随机过期时间、互斥重建等方式缓解。5. Spring Security JWT OAuth2 的关系是什么Spring Security 负责认证授权框架能力JWT 常用于无状态令牌承载用户身份与权限信息OAuth2 则是统一授权协议适合第三方登录、单点登录和多系统访问授权。在前后端分离架构中用户登录后后端签发 JWT前端请求时携带 token后端通过过滤器或认证链校验。对于企业内部多系统场景可以引入 OAuth2/OIDC 统一身份中心实现账号体系统一管理。权限模型通常还需结合角色、资源、方法级鉴权不能只靠“是否登录”。6. AI 智能客服中的 RAG、Agent 与工具调用怎么落地AI 客服最怕“胡说八道”因此常用 RAG 方案先把企业文档切分、清洗、向量化存入向量数据库用户提问时先做语义检索取回相关片段再把片段连同问题一起交给大模型生成回答。这样能显著降低幻觉。若客服还需要执行查询订单、发起退款等动作就要引入 Agent 和工具调用机制模型先判断是否需要调用工具再按标准化接口调用后端服务得到结果后继续推理或直接回复。这里的关键是工具边界清晰、权限受控、流程可审计并对复杂工作流设置兜底策略。7. 如何排查“接口慢、消息慢、AI 慢”建议从“链路追踪 指标监控 日志分析”三层入手。链路追踪用于定位慢在调用链哪一环Prometheus/Grafana 可观察 QPS、延迟、错误率、GC、线程池、连接池、消费积压等指标日志用于复盘具体请求与异常栈。数据库侧重点看慢 SQL、索引、连接池耗尽消息侧关注堆积、消费失败和重试风暴AI 侧重点看检索耗时、向量召回质量、模型响应时间以及上下文长度是否过大。排查时要先定位瓶颈再做针对性优化避免盲目加机器。感谢阅读希望这篇面试实录能帮助大家更好地理解 Java 大厂面试中的真实业务问题与技术深挖点祝你们面试顺利、早日拿到满意的 offer。