大厂Java面试实录：Spring Boot/Cloud、Kafka、Redis、K8s 与 Spring AI（RAG/Agent）三轮连环问

大厂Java面试实录：Spring Boot/Cloud、Kafka、Redis、MySQL、K8s 与 Spring AI(RAG/Agent) 连环问

故事背景

你面前坐着两个人：

• 面试官（严肃版）：互联网大厂内容社区 + 音视频 AIGC 平台的后端负责人。
• 小Y（搞笑版水货程序员）：自称“全栈微服务架构师”，简历上写满 Spring 全家桶、Kafka、K8s、Spring AI。

业务场景：公司做一个内容社区 + UGC 短视频平台，新增AIGC 智能创作/智能客服能力。你（小Y）应聘 Java 后端。

第一轮（基础到进阶）：从单体到微服务的落地

Q1：如果用 Spring Boot 做内容发布服务，你会怎么拆模块？

面试官：内容发布（图文/视频）、审核、推荐、用户关系、通知，这些怎么拆？

小Y：呃……就按“一个功能一个服务”拆嘛。比如发帖一个服务，点赞一个服务……拆得越细越好，微服务就是要“微”。

面试官：你这说法有点危险。继续。

Q2：内容发布写 MySQL，如何保证“写入成功但消息没发出去”的一致性？

面试官：发布成功要通知粉丝、触发审核、写 ES 索引。你怎么保证不丢？

小Y：用事务啊！MySQL 事务提交就说明都成功了……消息队列也放事务里提交就行。

面试官（眉毛动了一下）：队列事务你具体怎么做？

小Y：Kafka……它不是有事务吗？反正配一下就好了。

Q3：你会用 Redis 做什么？怎么避免缓存穿透/击穿/雪崩？

面试官：热点视频详情、评论数、点赞状态。

小Y：Redis 就是缓存嘛。穿透的话……加个布隆过滤器？击穿就加锁，雪崩就随机过期时间。

面试官（点头）：这题回答不错，能落地。

Q4：连接池为什么大厂普遍用 HikariCP？C3P0 为什么不推荐？

小Y：HikariCP 快，C3P0 慢……大概是这样。

面试官：还有呢？

小Y：嗯……Hikari 名字比较酷。

面试官（忍住笑）：行，先过。

第二轮（分布式与可观测性）：微服务上线后的“挨打”问题

Q1：Kafka 用在“发布事件流”里，你怎么设计 Topic、分区、消费组？

面试官：发布事件要保证同一内容的事件顺序。

小Y：Topic 就叫content_publish，分区越多越好，消费组随便起，保证顺序的话……Kafka 天生有序吧？

面试官：你确定“天生有序”？

小Y：至少……听起来有序。

Q2：微服务调用链路很长，怎么做超时、重试、熔断、限流？

面试官：OpenFeign + Resilience4j 你会怎么配？

小Y：超时就……配个超时。重试就多试几次，熔断就是断掉，限流就是限一下。

面试官：有没有更具体的策略？例如幂等、退避、隔离？

小Y：幂等就是“不要重复”，退避就是“慢一点”，隔离就是“分开”。

面试官（沉默两秒）：……

Q3：你们用 K8s 部署 Spring Boot，如何优雅停机避免请求丢失？

小Y：K8s 会帮我们停的。要优雅就……kill -9不优雅，kill比较优雅？

面试官：你说的是进程信号，和 readiness/liveness、preStop、grace period 有关系。

小Y：对对对，就是那个……readiness读一读就好了。

Q4：监控怎么做？Micrometer + Prometheus + Grafana 你能讲一下链路吗？

小Y：Micrometer 采集指标，Prometheus 拉，Grafana 画。

面试官：哪些指标你会重点看？

小Y：CPU、内存、还有……幸福指数。

面试官（点头）：至少方向对。

第三轮（AI + 业务落地）：AIGC创作与智能客服

Q1：你要做“企业文档问答 + 客服”，RAG 的完整链路是什么？

面试官：从文档到回答，讲清楚。

小Y：RAG 就是“先查再答”。先把文档丢进去，然后大模型就会了。

面试官：向量化、切分、Embedding、向量库、召回、重排、提示填充、引用来源、会话内存呢？

小Y：这个……都可以用 Spring AI 一把梭，配置一下application.yml。

Q2：如何降低 AI 幻觉（Hallucination）？

小Y：让它别胡说。

面试官：技术手段？

小Y：给它加一个“请不要胡说”的提示词。

面试官：……

Q3：Agent（智能代理）和传统 RAG 有什么区别？什么时候用 Agentic RAG？

小Y：Agent 就是更智能的 RAG，能自己想办法。什么时候用……想用的时候用。

面试官：如果要“查订单状态 + 退款规则 + 触发工单”，你会怎么编排工具？

小Y：用一个超级方法doAll()。

Q4：AI 服务如何做权限与审计？OAuth2/JWT/Keycloak 怎么选？

小Y：JWT 就是 token，OAuth2 就是登录，Keycloak 是个 UI……都可以用。

面试官：那审计怎么落日志？脱敏怎么做？

小Y：打日志的时候……把密码打成***。

结束语

面试官：今天先到这里。你回去等通知吧，我们 HR 会联系。

小Y：好的好的，我等“热通知”，最好带高薪那种。

面试题详细答案与小白学习版解析（按业务链路串起来）

下面把每一轮的问题，按“内容社区 + 音视频 + AIGC”的业务链路，补齐标准答案与可落地做法。

第一轮答案：服务拆分、数据一致性、缓存、连接池

1）内容发布服务怎么拆？（Spring Boot + Spring Cloud 常见边界）

业务目标：发布内容会触发审核、分发、推荐、通知、索引等。

建议拆分思路（不是越细越好，而是围绕边界与团队协作）：

• 内容域 Content Service：内容元数据（标题、正文、作者、可见性、状态）、发布/下架。
• 媒体域 Media Service：视频转码、封面截图、音视频存储地址、CDN 分发。
• 审核域 Audit Service：机审/人审状态流转。
• 互动域 Interaction Service：点赞/收藏/评论计数与明细。
• 关系域 Relation Service：关注/粉丝。
• 通知域 Notify Service：站内信/推送。
• 搜索域 Search Service：ES 索引构建与查询。
• 推荐域 Recommend Service：召回/排序/策略。

落地原则：

• 先从“模块化单体”或“少量粗粒度服务”起步，再按瓶颈拆。
• 以数据所有权划分：一个服务拥有自己的库表（Database per service），避免跨服务写。
• 以变更频率与扩展性划分：视频转码、推荐通常独立扩缩容。

2）MySQL 写成功但消息没发出去：如何保证一致性？

问题本质：本地事务（MySQL）与外部系统（Kafka/ES/通知）之间的分布式一致性。

常见可落地方案：

1. Outbox Pattern（推荐）

   • 同一个 MySQL 事务里：
     • 写业务表（content）
     • 写 outbox 表（event_outbox，记录事件 payload、状态）
   • 事务提交后，由异步任务/CDC（如 Debezium）把 outbox 事件投递到 Kafka。
   • 投递成功后更新 outbox 状态。

2. Kafka 事务（可用但要谨慎）

   • Kafka 事务解决的是Kafka 生产者多分区/消费-生产的 exactly-once 语义。
   • 但它不能把 MySQL 本地事务纳入同一分布式事务。
   • 因此仍需要 Outbox/补偿机制。

3. 最终一致性 + 幂等消费

   • 允许短时间不一致，但下游必须可重试、可补偿。
   • 消费端以业务 key（contentId + eventId）做幂等（Redis/DB 去重表）。

3）Redis 缓存怎么用？穿透/击穿/雪崩怎么防？

业务例子：视频详情页 QPS 高，MySQL 扛不住。

• 缓存穿透（请求不存在的数据，绕过缓存直击 DB）

  • 布隆过滤器（Bloom Filter）：先判断 key 可能存在再查缓存/DB。
  • 缓存空对象：对不存在的 ID 缓存短 TTL 的空值。

• 缓存击穿（热点 key 过期瞬间，大量请求打到 DB）

  • 互斥锁/单飞：用 RedisSETNX或本地锁，只有一个线程回源构建缓存。
  • 逻辑过期：缓存不过期，值里带过期时间，后台异步刷新。

• 缓存雪崩（大量 key 同时过期或 Redis 故障）

  • TTL 加随机抖动。
  • 多级缓存：Caffeine（本地）+ Redis（分布式）。
  • 限流/降级：例如只返回基础信息。

可配合Spring Cache：统一注解与缓存管理，但要自己设计 key、TTL、穿透策略。

4）HikariCP 为什么更常用？

关键点：

• 性能与稳定性：HikariCP 以轻量、高性能著称；C3P0 历史包袱较多。
• 更合理的超时控制：连接获取超时、连接泄漏检测（leakDetectionThreshold）。
• 与 Spring Boot 默认集成：Spring Boot 2+ 默认优先 HikariCP，运维经验丰富。

第二轮答案：Kafka 设计、韧性治理、K8s 优雅停机、可观测性

1）Kafka：Topic/分区/消费组怎么设计？如何保证“同一内容事件有序”？

核心结论：Kafka只保证“同一分区内有序”。

设计方法：

• Topic：content-events（按领域事件命名）。
• 分区数：根据吞吐预估与扩展选择（例如 12/24），并留余量。
• key 选择：用contentId作为消息 key，确保同一 contentId 的事件落到同一分区，从而保持顺序。
• 消费组：
  • 审核服务一个组（AuditGroup）
  • 索引服务一个组（SearchGroup）
  • 通知服务一个组（NotifyGroup） 这样每个下游都能独立消费一份。

幂等与重复消费：Kafka 至少一次语义下要考虑重复，消费端用 eventId 去重。

2）OpenFeign + Resilience4j：超时/重试/熔断/限流怎么配才“像大厂”？

原则：

• 先超时，再重试；重试要谨慎，否则放大雪崩。
• GET/查询类可重试；下单/扣款等写操作必须幂等（幂等键）。
• 重试用指数退避（Exponential Backoff）+ 抖动。
• 熔断（CircuitBreaker）：下游持续失败时快速失败，保护线程资源。
• 隔离：线程池/信号量隔离（Bulkhead），避免一个下游拖死全局。
• 限流：对外接口做 RateLimiter；对内关键资源也可限。

落地：

• Feign 设置连接/读超时。
• Resilience4j 在方法或 Feign Client 上挂装饰器：Retry + CircuitBreaker + TimeLimiter + Bulkhead。

3）K8s 部署 Spring Boot：如何优雅停机？

目标：Pod 下线时不丢请求、不产生半处理。

关键点：

• Spring Boot 开启graceful shutdown（Boot 2.3+）。
• K8s：
  • readinessProbe：收到 SIGTERM 前/后要快速变为 not ready，停止接新流量。
  • preStophook：给应用一点时间摘流。
  • terminationGracePeriodSeconds：给足优雅退出时间。
• 业务侧：
  • 消费者（Kafka/RabbitMQ）在 shutdown 时停止拉取并提交 offset。
  • 长事务/长请求设置上限。

4）Micrometer + Prometheus + Grafana：该看哪些指标？

建议按RED/USE方法：

• HTTP：
  • R（Rate）：QPS
  • E（Errors）：4xx/5xx 比例
  • D（Duration）：P95/P99 延迟
• JVM：堆内存、GC 次数/耗时、线程数、类加载。
• DB：连接池使用率、等待时间、慢 SQL。
• MQ：消费延迟（lag）、堆积量、失败率。

链路追踪：Zipkin/Jaeger；日志：ELK；指标：Prometheus。

第三轮答案：Spring AI、RAG、Agentic RAG、权限审计与反幻觉

1）RAG 完整链路（企业文档问答/客服）

业务目标：客服回答必须“有依据、可追溯”。

完整链路：

1. 文档加载：PDF/Word/网页/知识库（Spring AI DocumentLoader）。
2. 清洗与切分：按段落/标题切 chunk（控制长度，保留结构）。
3. 向量化（Embedding）：调用 OpenAI/Ollama 等 embedding 模型把 chunk 转成向量。
4. 写入向量数据库：Milvus/Chroma/Redis Vector 等，保存向量 + 元数据（来源、页码、权限标签）。
5. 查询时语义检索：用户问题 embedding → 向量召回 TopK。
6. （可选）重排 rerank：用交叉编码器或 LLM 重排提升相关度。
7. 提示填充（Prompt Template）：把“问题 + 召回片段 + 规则（必须引用来源/不确定就说不知道）”拼装。
8. 生成回答：LLM 输出。
9. 引用与可追溯：返回引用片段/文档链接。
10. 会话内存：保存上下文（但要防止把错误信息带入）。

2）降低 AI 幻觉（Hallucination）的工程手段

可落地组合拳：

• 基于检索的约束：回答必须基于检索片段；提示中强制“仅依据上下文”。
• 置信度门控：召回相似度低于阈值 → 直接拒答/转人工。
• 引用校验：要求模型输出引用编号；后处理校验引用是否存在。
• 结构化输出：用 JSON Schema/函数调用约束输出格式。
• 多模型或自检：让另一个模型进行事实一致性检查。
• 敏感场景（医疗/金融）必须加入：规则引擎、黑白名单、人工兜底。

3）Agent vs RAG：什么时候用 Agentic RAG？

• 传统 RAG：一次检索 + 一次生成，适合“问答”。
• Agent：能够规划步骤并调用工具（查库、查订单、发工单、调用搜索、二次检索）。

适用场景：

• 多步任务：
  • “查订单状态 → 判断是否可退 → 生成退款说明 → 创建工单 → 通知用户”
• 需要在多个系统之间编排：订单服务、工单系统、规则中心。

工程化要点：

• 工具调用标准化（函数签名/JSON Schema）。
• 权限控制：Agent 调用工具必须鉴权、审计。
• 失败回退：某一步失败要能停止并给出可解释反馈。

4）AI 服务权限与审计：OAuth2/JWT/Keycloak 怎么选？

• JWT：适合无状态鉴权与微服务间传递身份；注意过期、吊销策略。
• OAuth2/OIDC：标准授权框架，适合第三方登录/统一身份。
• Keycloak：成熟的 IAM（身份与访问管理）产品，提供 OAuth2/OIDC、用户/角色/租户管理、SSO。

审计与脱敏：

• 审计日志记录：谁（userId/tenant）在什么时间调用了哪个模型/工具，输入输出摘要，耗时与成本。
• PII 脱敏：手机号/身份证/地址在日志与向量库元数据中脱敏或加密。
• 加密：可用 Bouncy Castle 做加解密/签名能力扩展。

给小白的学习路线（按面试这套链路）

1. Spring Boot + MVC（能写出发布接口）
2. MySQL + 索引 + 事务 + Outbox 最终一致性
3. Redis 缓存策略（三大问题）
4. Kafka：分区有序、幂等、消费组
5. Spring Cloud/OpenFeign + Resilience4j（治理）
6. K8s 基础：readiness/liveness/优雅停机
7. 可观测性：Micrometer + Prometheus + Grafana + ELK/Jaeger
8. Spring AI：RAG 链路、向量库、反幻觉、Agent 工具编排