互联网大厂 Java 面试实录Spring Boot Kafka Redis RAG 的业务追问燕双非翻车现场场景互联网大厂 Java 求职者面试业务方向为本地生活服务 智能客服系统 AIGC候选人燕双非风格能答简单题复杂题开始含糊其辞。第一轮基础架构与业务落地面试官你先介绍一下你做过的本地生活项目技术栈怎么选的燕双非我们主要用 Spring Boot 做接口层MyBatis 访问数据库Redis 做缓存Kafka 做订单异步消息整体就是“快、稳、省”。面试官为什么订单创建后要发 Kafka而不是直接写库后同步通知商家燕双非嗯……同步的话会阻塞用户下单Kafka 可以削峰填谷而且商家通知、优惠券发放、积分累加都可以拆成异步消费者。面试官不错说明你有分布式解耦意识。那你说说 Redis 缓存下商家首页推荐列表怎么避免缓存击穿燕双非可以用互斥锁或者逻辑过期。热点商家数据提前预热过期后由后台线程异步刷新避免很多请求同时打到数据库。面试官可以至少不是只会说“加缓存”。那如果促销活动开始首页流量暴涨你怎么做限流燕双非网关层限流按用户、IP、接口维度做令牌桶或者漏桶必要时结合熔断降级先保证核心下单链路可用。第二轮微服务、消息一致性与搜索面试官那我们继续商家服务、订单服务、优惠券服务拆成微服务后服务注册和调用怎么做燕双非可以用 Spring Cloud OpenFeign。服务发现用注册中心调用方通过接口声明式调用配置超时和重试。面试官重试是好事但你知道哪些场景不能盲目重试吗燕双非嗯……幂等没做好就不能乱重试比如扣库存、扣余额这种。如果重复请求会造成多扣就得先设计幂等键或者状态机。面试官说得还行。现在业务要做“附近美食自然语言搜索”你会怎么设计燕双非可以先用 Elasticsearch 做商家和菜品索引再结合自然语言语义搜索。对用户搜索词做分词、召回、排序。面试官如果产品说“我想搜‘适合带娃、离地铁近、评价高的川菜馆’”传统关键词检索不够你怎么补燕双非可以引入向量化和语义检索把商家介绍、评论、标签做 Embedding存到向量数据库里结合 RAG 做检索增强再让 AI 生成更贴近意图的推荐结果。面试官那 AI 生成内容怎么避免幻觉燕双非额……要控制提示词给模型加检索上下文限定只能基于检索结果回答对关键结论做规则校验必要时人工兜底。面试官可以至少知道幻觉不是“鬼故事”。第三轮稳定性、观测性与交付面试官线上出问题时你怎么定位一个支付成功但订单没落库的故障燕双非先看链路日志和监控指标结合 TraceId 串起支付、消息、订单三个服务如果是异步链路查 Kafka 消费是否积压、是否重复消费、数据库是否有唯一键冲突。面试官那监控体系你会怎么搭燕双非Micrometer 打点Prometheus 抓指标Grafana 看面板链路追踪可以用 Jaeger 或 Zipkin日志统一用 SLF4J Logback方便排障。面试官很好。最后一个问题容器化部署后灰度发布和回滚你怎么做燕双非用 Docker 打包Kubernetes 做滚动发布灰度可以按版本标签或流量比例切分发现异常立即回滚到上一版本同时保留数据库变更的回退方案比如 Flyway/Liquibase 的版本管理。面试官嗯整体还行不过你对复杂问题有些地方还是比较飘。今天先到这儿你回家等通知吧。问题详解结合本地生活服务 智能客服系统深入理解1. Spring Boot MyBatis Redis Kafka 的订单链路在本地生活场景中用户下单通常需要经过提交订单、校验库存/优惠券、落库、发消息通知商家、发放积分或券。Spring Boot 负责快速搭建服务MyBatis 适合高可控 SQL 场景Redis 用于热点信息缓存与限流计数Kafka 用于异步解耦。核心目标是高并发下保持用户体验。同步链路要尽量短长耗时任务交给消息队列处理。为了避免消息丢失应采用“本地事务 消息表”或事务消息的方案确保订单落库与消息发送最终一致。2. 缓存击穿、限流与热点保护商家首页、爆款团购、热门餐厅属于典型热点数据。常用方案包括互斥锁只有一个线程回源数据库其他线程等待或返回旧值。逻辑过期缓存值不立即失效后台异步刷新适合极热点场景。限流网关层按接口、用户、IP 控制 QPS防止活动流量打穿系统。在大促或节假日这些策略往往需要组合使用优先保证下单、支付等核心链路。3. 微服务拆分与幂等设计当商家、订单、优惠券、支付独立成服务后Spring Cloud OpenFeign 可用于服务发现与调用。此时最重要的是幂等性。因为网络超时、消息重试、用户重复点击都可能导致重复请求。常见幂等实现业务唯一键如订单号、支付流水号。状态机控制只允许从“待支付”流转到“已支付”。去重表/幂等表记录已处理请求。对于扣库存、扣余额、发券等操作一定要先设计幂等再考虑重试。4. 自然语言搜索、向量检索与 RAG“适合带娃、离地铁近、评价高的川菜馆”不是简单关键词能解决的。此时可以采用Elasticsearch 向量数据库的混合检索方案ES 负责结构化字段地铁距离、评分、品类、营业状态。向量库负责语义相似度评论文本、商家介绍、用户意图。RAG 负责把检索结果作为上下文交给大模型生成最终推荐。为了降低 AI 幻觉应让模型“只基于检索内容回答”并加入规则约束、置信度阈值和人工兜底。5. 观测性、链路追踪与故障定位在线上系统里支付成功但订单未落库这类问题非常典型。排查思路通常是先看监控指标QPS、错误率、Kafka 堆积、数据库连接池情况。再看链路追踪通过 TraceId 关联支付、消息、订单服务。最后看日志确认是否存在消息重复消费、唯一键冲突或事务回滚。Micrometer Prometheus Grafana 是常见组合Jaeger/Zipkin 用于链路追踪SLF4J Logback 统一日志输出。6. 容器化、灰度发布与数据库版本管理Docker 和 Kubernetes 可以帮助快速交付和弹性扩容。灰度发布通常通过流量比例、版本标签或独立命名空间实现。若发现异常应迅速回滚服务版本同时注意数据库变更是否可回退。Flyway 或 Liquibase 适合管理数据库脚本版本。上线前应评估新增字段是否兼容旧版本代码、是否可回滚、是否需要双写过渡。对于互联网大厂发布策略不是“能发就行”而是“可控、可观测、可回退”。7. 面试中的回答策略简单题要明确、干净、能落地复杂题要先讲思路再讲边界条件再讲故障场景。像燕双非这种候选人能把 Spring Boot、Redis、Kafka、微服务、RAG 这些词串起来已经不错但要真正拿高分还得把一致性、幂等性、可观测性、降级和回滚讲透。感谢阅读希望这篇文章能帮助你在 Java 面试中更从容地理解业务与技术的结合少走弯路顺利拿到心仪的 offer。