大厂Java面试实战：Spring Boot/WebFlux、Redis+Kafka、K8s可观测性与Spring AI RAG/Agent三轮连环问

场景：某互联网大厂电商内容社区（UGC）+AIGC 生成内容，存在"发布-审核-推荐-搜索-风控"的链路。你（候选人）来面 Java 后端。

角色：

面试官（严肃）：追求"可落地、可观测、可扩展"。
小Y（搞笑水货程序员）：简单题能答，复杂题开始"嗯...我感觉...应该..."。

第一轮：从单体到基础服务（Java/JVM + Spring Boot + 数据访问）

Q1（业务起点）

面试官：电商社区里，用户发一条图文/短视频UGC，服务端第一步你会怎么设计接口？Spring MVC 还是 WebFlux？

小Y ：嗯...发帖嘛，就一个 POST /posts。我一般用 Spring MVC，WebFlux...我知道是响应式的，挺新潮，但我们用 MVC 就够了。

面试官：回答合格。能说出选型依据就更好：吞吐、线程模型、上下游是否响应式。

Q2（Java基础 + 并发与资源）

面试官：上传视频会占用大量 IO，JVM 里你最担心什么？怎么在 Java 8/11 里定位 OOM 或 Full GC？

小Y：我担心内存爆炸...OOM 就看日志，Full GC 就...加大内存？

面试官：你知道"看日志"是方向，但要具体到工具链：GC 日志、jcmd/jmap、JFR。继续。

Q3（数据库/ORM + 连接池）

面试官：帖子表、用户表、审核表，读多写多？你会选 MyBatis 还是 JPA/Hibernate？连接池用 HikariCP 的理由？

小Y：我用 MyBatis，SQL 看得见。HikariCP...听说快。

面试官：不错，SQL 可控是 MyBatis 优点。HikariCP 快不是口号，它的实现细节和监控友好性都能讲。

Q4（数据库版本管理）

面试官：如果今天要加"帖子风险分"字段并灰度上线，Flyway/Liquibase 怎么配合 CI/CD？

小Y：我一般直接改表...Flyway 就跑一下脚本？CI 里加一步执行？

面试官：方向对，但要提到版本号、幂等、回滚策略、灰度/双写兼容。

第二轮：微服务链路（Kafka/Redis/Resilience4j/可观测性）

链路升级：发帖成功后需要：

进入审核队列；2) 审核通过后进推荐与搜索；3) 反作弊与风控异步评分；4) 首页 feed 高并发读。

Q1（异步解耦：Kafka vs RabbitMQ）

面试官：审核与风控都异步，你会选 Kafka 还是 RabbitMQ？分别适合什么？

小Y：Kafka 很大数据，RabbitMQ 很消息。我们用 Kafka 吧，听起来更大厂。

面试官：别"听起来"。需要基于吞吐、顺序、重放、消费模型、延迟、运维成本来选。

Q2（缓存：热点feed + 一致性）

面试官：首页 feed 读多写少，你用 Redis 怎么设计 Key？如何处理缓存穿透/击穿/雪崩？

小Y ：Key 就 feed:userId。穿透就加布隆过滤器？击穿就加锁？雪崩就...多加点机器。

面试官：回答不错，有条理。能进一步把"过期策略 + 随机抖动 + 热点保护 + 多级缓存(Caffeine+Redis)"串起来更佳。

Q3（微服务调用治理：OpenFeign + Resilience4j）

面试官：审核通过后要调用"推荐服务""搜索服务"，你用 OpenFeign，如何做超时、重试、熔断、限流？

小Y：Feign 就是调接口嘛。超时我配大点，重试也配大点，熔断...好像有个 Hystrix？

面试官：Hystrix 退休了。现在常用 Resilience4j。重试"配大点"会把下游打死。

Q4（可观测性：Micrometer + Prometheus + Jaeger）

面试官：用户说"发布后审核慢"，你怎么用指标/链路追踪定位是 Kafka 堵了还是审核服务慢？

小Y：我先看日志...ELK 搜一下，然后再看 Prometheus 上 CPU？Jaeger 我知道是链路。

面试官：可以，至少知道工具。关键是要定义：端到端 latency、队列堆积 lag、消费速率、下游 span。

第三轮：AIGC内容审核 + RAG/Agent（Spring AI、向量检索、工具调用）

新需求：平台允许商家用 AIGC 生成商品文案/短视频脚本。为了降低违规与"AI幻觉"，需要：

生成前：基于企业规则库/法律条款做检索；

生成后：二次审核与事实核验；

支持客服问答：查企业知识库，要求可追溯引用。

Q1（RAG 基本链路）

面试官：解释一下 RAG 的链路。你会怎么做文档加载、分段、向量化、检索、提示填充？

小Y：RAG 就是先搜再问。把文档丢进去，向量化一下，然后模型就更准。

面试官：概念对，但缺"可操作细节"：chunk、overlap、embedding 选择、topK、重排、引用返回。

Q2（向量库选型：Milvus/Chroma/Redis Vector）

面试官：向量数据库你怎么选？Milvus、Chroma、Redis 各有什么 trade-off？

小Y：Milvus 专业，Chroma 轻量，Redis 我们本来就有...所以用 Redis？

面试官：能说出方向，但还要结合规模（百万/千万向量）、一致性、运维、延迟、过滤能力。

Q3（Agent + MCP/工具调用标准化）

面试官：客服"退货运费怎么算"这种问题，Agent 要调用订单/物流/规则服务。你如何设计工具执行框架？MCP/Google A2A 能解决什么？

小Y：Agent 就让模型自己决定调用哪个接口...MCP 我听过，是一种协议？A2A...是模型之间聊天？

面试官：你这就"水货"了。要讲工具注册、参数 schema、鉴权、限流、观测、失败回退，以及协议标准化的价值。

Q4（AI 幻觉与可追溯）

面试官：怎么降低幻觉？如何让答案可追溯、可审计？

小Y：让它别乱说...提示词写严格一点，或者温度调低。

面试官：这只是皮毛。需要：引用证据、拒答策略、事实核验工具、输出约束、评测与回归测试。

面试收尾

面试官 ：整体基础还行，缓存和基础链路不错，但微服务治理和 AI 工具化落地还需要补齐。今天先到这里，你回去等通知，有结果 HR 会联系你。

小Y：好的好的，我回去就"深入学习一下"......（打开收藏夹，默默点开《Resilience4j 入门》）

题目标准答案与场景拆解（小白可直接背）

以下按三轮问题逐个给出"面试官期待答案"。

第一轮答案（接口/JVM/ORM/Schema）

A1：Spring MVC vs WebFlux 如何选

Spring MVC（Servlet 线程模型）：适合传统同步调用，团队熟悉；对"CPU 密集/一般 IO"场景很稳。
Spring WebFlux（Reactive） ：适合高并发 IO 密集、上下游也是响应式（例如 Reactive DB、Reactive HTTP client）或网关层；通过少量 event-loop 线程承载更多连接。
本题落地建议 ：
- "发帖+上传"通常会走对象存储（S3/OSS/COS）直传或分片上传；业务服务更多是元数据写入，MVC 足够。
- 若你负责聚合层/网关，并要扛大量长连接（SSE/WebSocket）或高并发回源，可考虑 WebFlux。

A2：上传/IO 场景下 JVM 风险与排查

风险点：
- 堆内存暴涨：把大文件读到 byte[]/内存缓存。
- 直接内存(Direct Memory) ：NIO/Netty/缓冲区导致 OutOfMemoryError: Direct buffer memory。
- 频繁 Full GC：对象分配过快、老年代膨胀、元空间压力。
排查手段（Java 8/11 常用）：
- 开启 GC 日志：-Xlog:gc*(11+) 或 -XX:+PrintGCDetails ...(8)
- 运行时诊断：jcmd <pid> GC.heap_info、jcmd <pid> VM.native_memory summary
- Dump：jmap -dump:format=b,file=heap.hprof <pid>，用 MAT/YourKit 分析
- Java 11+：JFR（低开销采样）定位热点分配与停顿
工程实践：上传走流式处理（InputStream -> OSS SDK），避免全量入堆；限制单请求体积；网关层做限流。

A3：MyBatis vs JPA/Hibernate；为什么 HikariCP

选型：
- MyBatis：SQL 可控、复杂查询/性能调优直观；大厂常见。
- JPA/Hibernate：领域模型友好，CRUD 快；但复杂查询、N+1、懒加载踩坑需要经验。
连接池 HikariCP 优点：
- 轻量高性能，减少不必要的同步与管理开销
- 连接泄漏检测（leakDetectionThreshold）
- 与 Micrometer/Actuator 集成易监控（活跃连接、等待线程等）
配置要点：最大连接数与数据库能力匹配；超时要合理（connectionTimeout）；配合慢 SQL 监控。

A4：Flyway/Liquibase + 灰度的正确姿势

迁移脚本：
- Flyway：V2026.04.15__add_risk_score.sql 版本化、按序执行
- Liquibase：XML/YAML changelog，支持更丰富的变更描述
兼容性发布 ：
1. 先加字段（允许 null 或默认值）
2. 应用版本 A 读旧字段仍可工作
3. 灰度应用版本 B 开始写新字段（必要时双写）
4. 数据回填任务
5. 全量切换后再做约束收紧/删旧字段
CI/CD：在部署阶段跑 migration；保证幂等与失败可回滚（至少可重试、可人工修复）。

第二轮答案（MQ/缓存/治理/可观测）

A1：Kafka vs RabbitMQ 怎么选

Kafka ：高吞吐、分区扩展、可重放（offset）、适合事件流/日志/埋点/异步流水线；延迟相对高但吞吐强。
RabbitMQ：协议丰富（AMQP）、路由灵活、延迟低、适合业务消息、需要多种交换器路由；吞吐一般不如 Kafka。
本场景建议：
- "发帖->审核->风控->推荐更新"更像事件流，Kafka更合适。
- 若有强路由/延迟敏感小消息，也可 RabbitMQ。

A2：Redis 设计 feed 缓存与三大问题

Key 设计：
- feed:{userId} 存储 feed id 列表（ZSET/列表）
- post:{postId} 存帖子详情（HASH/String）
缓存穿透：请求不存在的 key
- 布隆过滤器/RedisBloom
- 空值缓存（短 TTL）
缓存击穿：热点 key 过期瞬间大量并发打 DB
- 互斥锁（setnx）/单飞（singleflight）
- 逻辑过期（后台异步刷新）
缓存雪崩：大量 key 同时过期
- TTL 随机抖动
- 分批过期/预热
- 多级缓存：本地 Caffeine + Redis

A3：OpenFeign + Resilience4j 的正确治理

超时：区分连接超时/读超时；不要无限大。
重试：
- 只对幂等请求（GET/幂等 POST）重试
- 指数退避+抖动；限制最大重试次数
熔断（CircuitBreaker）：下游错误率/慢调用超阈值打开，快速失败，防止级联。
限流（RateLimiter/Bulkhead）：隔离线程/并发，避免把连接池打满。
兜底：fallback 返回降级数据（如"推荐稍后生成"）。

A4：Prometheus/Jaeger/ELK 联动定位"审核慢"

关键指标：
- API P95/P99：发帖接口耗时、审核接口耗时
- Kafka：consumer lag（积压）、消费速率、rebalance 次数
- 数据库：慢 SQL、连接池等待时间
链路追踪：
- 在"发帖->发消息->审核消费->写库->回写状态"打 span
- Jaeger/Zipkin 看哪一段耗时最大
日志：ELK 定位异常堆栈、超时、重试风暴。

第三轮答案（Spring AI/RAG/Agent/MCP/反幻觉）

A1：RAG 全链路（可落地版）

文档加载：企业规则、法律条款、商品禁限售清单（PDF/HTML/DB）。
分段（chunking）：按语义段落切；常见 300~800 tokens；设置 overlap（如 50~150）防止上下文断裂。
向量化（Embedding）：选 OpenAI/Ollama 等 embedding 模型；将 chunk -> 向量。
入库：Milvus/Chroma/Redis Vector；附带元数据（类目、版本、发布时间、适用地区）。
检索：topK + 元数据过滤（如"类目=保健品""地区=中国"）；必要时重排（rerank）。
提示填充（prompt stuffing） ：把检索到的片段作为"证据"塞进 prompt，要求模型仅基于证据回答并输出引用。
返回：答案 + 引用片段/链接，满足可追溯。

A2：Milvus/Chroma/Redis Vector 选型

Milvus：适合百万~亿级向量、分布式、性能与功能完整；运维成本较高。
Chroma：更偏轻量与本地/中小规模，开发体验好；大规模与高可用需要评估。
Redis Vector ：
- 优点：已有 Redis 体系、延迟低、运维统一、可与业务缓存结合
- 局限：超大规模、复杂检索能力可能不如专用向量库
本题建议：
- 早期/中小规模可 Redis Vector 或 Chroma 快速落地；
- 规则库/知识库增长到千万级且要强检索能力，再迁 Milvus。

A3：Agent 工具执行框架 + MCP/Google A2A 的价值

工具执行框架应具备：
- 工具注册：工具名称、描述、参数 schema（JSON Schema）
- 鉴权与审计：调用哪个业务接口、谁触发、参数与结果留痕
- 限流与预算：防止模型循环调用/刷接口
- 失败处理：超时、重试策略、回退到人工/规则答案
- 可观测性：每次 tool call 的耗时、成功率、错误码
MCP（模型上下文协议）：把"工具/资源/上下文"以标准方式暴露给模型客户端，降低不同模型/不同工具之间的耦合。
Google A2A：更偏多 Agent 协作通信的标准化，让多个 Agent 分工（检索Agent、核验Agent、订单Agent）协同。

A4：降低幻觉与可追溯（大厂常用组合拳）

证据优先：RAG 返回必须带引用；prompt 约束"无证据则拒答"。
拒答策略：缺少关键信息时引导用户补充，而不是编造。
事实核验工具：调用"规则查询/订单查询/商品信息服务"进行校验（工具调用）。
输出约束：结构化输出（JSON/Schema），避免自由发挥。
评测与回归：建立问答集与自动化测试（JUnit + 断言引用存在/敏感词不出现/一致性）。

到这里，小Y 起码知道自己"水"在哪了：微服务治理要会细节，AI 要会工具化与可追溯。