Java 大厂面试实录Spring Cloud Kafka Redis RAG 场景下燕双非的三轮过招场景一家互联网大厂的 Java 岗位面试现场业务方向是本地生活服务 AI 智能客服。面试官神情严肃候选人是外号“燕双非”的水货程序员。简单题能答答好了会被夸难题一来就开始含糊其辞。第一轮基础架构与服务治理面试官你们做本地生活服务时用户下单、商家接单、骑手配送这条链路为什么要拆成微服务燕双非因为业务比较多嘛拆开以后大家都能各干各的。比如订单服务、商家服务、配送服务、营销服务职责清晰改起来也方便出问题也容易定位。面试官说得还行。那服务之间通信你会怎么选Spring Cloud、OpenFeign、gRPC 这些你怎么考虑燕双非如果是普通业务接口我一般会用 OpenFeign配合 Spring Cloud 比较方便声明式调用开发效率高如果是内部高性能调用或者接口比较强约束的场景可能会考虑 gRPC。面试官那服务发现和配置中心呢如果你们还在用 Eureka有什么隐患燕双非Eureka 主要是服务注册发现能让服务自动上线下线感知。隐患嘛……我记得它偏 AP在网络抖动的时候可能会保留一段时间的脏实例消费者侧要有容错机制。面试官还可以。那你说说网关层为什么不能只做转发燕双非网关通常还要做鉴权、限流、黑白名单、灰度发布、统一日志、请求聚合有时候还能做协议转换。不能只是个“传话筒”。第二轮订单链路、缓存与消息队列面试官用户在高峰期同时抢购到店套餐Redis 你会怎么用燕双非Redis 可以做热点套餐库存、商家首页缓存、用户会话和验证码。抢购场景里可以用原子操作控制库存减少数据库压力。面试官那缓存一致性怎么处理比如用户下单后商家详情页缓存还是旧的。燕双非这个……一般先更新数据库再删除缓存。因为直接更新缓存容易有并发问题。删除后下次读再回源至于双写一致性得结合业务容忍度和最终一致性方案。面试官如果订单创建成功后要给商家、骑手、用户分别发通知你会怎么设计异步链路燕双非我会用 Kafka 之类的消息队列。订单服务发订单事件通知服务、配送服务、营销服务分别订阅。这样削峰填谷也避免主链路阻塞。面试官消息重复消费怎么解决燕双非要做幂等。比如订单状态机、唯一业务键、消费记录表、Redis 去重都可以。核心就是同一条消息重复来业务结果不能重复执行。面试官如果你要在订单创建时顺便触发风控校验Kafka 和同步调用怎么取舍燕双非风控如果是强实时强拦截就同步调用更稳妥如果只是辅助评分或后置审计可以异步消息。核心看这个动作是不是“必须立即阻断下单”。第三轮AI 客服、搜索与安全面试官现在我们做一个 AI 智能客服用户问“为什么我的订单一直没送到”你会怎么设计燕双非我会先让大模型接入业务知识库做 RAG。先从订单、物流、工单这些数据源里检索相关信息再把检索结果拼到提示词里让模型基于真实数据回答减少胡说八道。面试官那你说说 RAG 和纯大模型聊天的区别。燕双非纯聊天靠模型参数记忆容易过时也可能幻觉RAG 会先检索企业文档或业务数据再生成答案适合企业客服、知识库问答和复杂流程解释。面试官如果客服系统要支持“查订单、退改签、催单”工具调用怎么做燕双非可以把这些能力标准化成工具接口让 Agent 根据用户意图选择工具执行。比如查订单调用订单查询接口催单调用配送催单接口。这样模型负责理解系统负责执行。面试官很好。那这个系统怎么防止越权比如用户问别人的订单。燕双非要结合 Spring Security、JWT、OAuth2 做身份认证和授权订单接口必须做用户身份校验。AI 层也不能直接相信自然语言要把权限校验放在工具调用前后。面试官最后一个问题客服回答慢了怎么办燕双非可以做流式返回WebSocket 或类似的推送方式把生成结果逐步发给前端同时做缓存、降级、超时控制必要时走人工兜底。面试官嗯今天先到这里吧。你回去等通知。问题详解1. 为什么本地生活服务要拆微服务本地生活业务天然多域订单、商家、配送、营销、风控、客服彼此耦合度高拆分后可以让团队围绕业务域独立迭代。拆微服务的核心收益是解耦、独立部署、弹性扩缩容、故障隔离。比如大促时订单链路压力大可以单独扩容订单服务而不必把整套系统一起扩容。2. OpenFeign、gRPC 怎么选OpenFeign 更适合 Spring 体系下的业务接口调用声明式开发简单配合负载均衡、熔断限流容易落地。gRPC 更适合内部高性能、强类型、低延迟的服务间通信尤其是高频调用或跨语言场景。业务系统中常见做法是对外 REST对内高频链路 gRPC。3. Eureka 的特点与隐患Eureka 是典型的注册中心方案服务启动后注册自身信息调用方通过服务名发现实例。它偏向 AP在网络分区时更强调可用性因此可能短时间接受到不完全准确的实例列表。生产上要结合超时、重试、熔断、健康检查来兜底。4. 网关层为什么不能只做转发网关是系统入口除了路由转发还要承担鉴权、限流、灰度、统一审计、协议适配、Header 透传、IP 黑白名单等职责。对本地生活这类高并发平台网关还会承接营销活动的限流和防刷。5. Redis 在抢购和缓存场景中的作用Redis 适合高频读写、低延迟场景。库存扣减可借助原子指令或 Lua 保证一致性首页数据、商家详情、验证码、Session 也很常见。关键是要设计好过期策略、穿透、击穿、雪崩防护。6. 缓存一致性怎么做常见思路是先更新数据库再删除缓存让缓存失效后回源重建。对于更复杂场景可以结合消息通知、订阅 binlog、延迟双删、版本号控制等手段。需要明确的是缓存场景更多追求最终一致性而不是强一致。7. Kafka 适合什么场景Kafka 适合高吞吐、事件驱动、日志收集、异步解耦、削峰填谷。订单创建后把“订单已创建”“支付已完成”“骑手已接单”等事件发出来多个下游系统各自订阅能显著减少同步耦合。8. 消息重复消费如何处理消息队列通常至少一次投递重复消费是常态。解决方式包括业务幂等键、状态机校验、去重表、唯一索引、Redis 去重、消费位点控制等。比如订单状态从“已支付”再收到“已支付”事件系统应直接忽略。9. 风控为什么有时必须同步如果风控结论决定能不能下单、能不能支付那它就是强拦截链路必须同步否则等异步消息回来时坏单可能已经产生。若只是后置评分或画像更新就可以异步处理。10. RAG 为什么适合 AI 客服企业客服依赖实时业务数据和内部知识文档而大模型参数里不可能天然包含这些最新信息。RAG 的流程是文档加载、切分、向量化、存入向量数据库、语义检索、拼装上下文、生成回答。这样能显著降低幻觉让回答更贴近真实业务。11. Agent 和工具调用怎么理解Agent 可以理解为“会规划和执行的模型代理”。用户说一句自然语言Agent 判断是否需要查订单、查物流、发工单然后调用对应工具。工具调用标准化后模型专注理解意图系统专注执行业务这也是企业级 AI 系统的主流方向。12. 如何防止 AI 幻觉和越权防幻觉优先使用 RAG、检索结果约束、回答引用来源、模板化回复、置信度阈值、人工兜底。防越权认证授权必须放在工具层基于 JWT/OAuth2/Spring Security 做身份识别任何“查订单”都要先确认当前用户是否有权限访问该订单。13. 流式返回为什么重要AI 客服场景中用户最怕“卡住”。流式返回可以先输出思考结果或阶段性答案降低等待感。结合 WebSocket 或 SSE 等技术前端可以更快看到内容同时后端也便于做超时控制和中断处理。14. 这类系统的综合架构思路一个典型架构是网关层鉴权限流业务服务通过 Spring Cloud/OpenFeign 或 gRPC 协作缓存层用 Redis 抗热点消息链路用 Kafka 解耦客服 AI 层通过 RAG Agent 工具调用接入订单、物流、工单系统再通过权限控制与审计保证安全。感谢阅读希望这篇文章能帮助你更好地理解 Java 大厂面试中的高频问题也能帮助你在真实面试中更从容地应对业务场景与技术追问。