大厂Java面试实录：Spring Boot/Cloud、Kafka、Redis、K8s 可观测性 + RAG/Agent（小Y翻车版）

角色

面试官（M）：语气严肃，逻辑强，步步递进。
小Y（Y）：水货程序员但不完全菜；简单题能答，复杂题开始"宇宙级概念"。

业务背景（贯穿三轮）

你面试的岗位是内容社区 + UGC + 音视频平台的后端 Java 工程师。

用户发帖/发短视频 -> 审核/推荐 -> 播放/互动（点赞评论）
高并发读、多写少、强运营活动
微服务化，Kubernetes 部署
近期要做 AIGC/智能客服：基于企业知识库的问答（RAG），并支持工具调用（Agent）

第一轮（基础打底：JVM/并发/接口设计）

Q1：短视频发布接口怎么设计？如何保证幂等？

M ：用户点"发布"可能抖手点两次，你的 POST /videos 怎么防重复？

Y ：这个简单！加个......呃......videoId？或者前端防抖？

M：前端防抖不可靠。服务端呢？

Y ：那就用 Redis setnx！拿 userId+标题 当 key，锁住 3 秒？

M：方向对，但 key 设计要更严谨。不错，继续。

Q2：高并发下点赞计数怎么做？Redis 还是数据库？

M：点赞是典型高频写，你会怎么做？

Y：Redis 先加，定时写数据库。

M：如果 Redis 挂了呢？数据一致性怎么兜？

Y：呃......那就......再加个 MQ？

M：可以，用事件驱动。你还知道哪些计数方案？

Y：HyperLogLog？（小声）好像是算 UV 的。

M：对，点赞要精确计数。你知道边界，挺好。

Q3：JVM 里一次 Full GC 可能由什么触发？如何排查？

M：线上音视频服务偶发卡顿，监控看到 Full GC，怎么定位？

Y：Full GC 就是内存满了......看下堆大小？

M：具体怎么"看"？用什么工具？

Y ：用 jmap、jstack，然后......看 MAT？

M：至少知道工具链，不错。那哪些对象最容易导致？

Y：大对象，比如缓存、列表、还有......字符串？

M：可以。下一轮。

第二轮（架构进阶：Spring Cloud/Kafka/数据库/一致性）

Q1：视频发布后要触发"审核、转码、推荐入库"，你怎么拆？

M：发布成功后，不能同步等转码。你如何做链路？

Y：用 Kafka！发布服务发消息，审核服务、转码服务订阅。

M：消息幂等怎么保证？

Y：Kafka 本身就不丢吧......

M：不丢不等于不重。你怎么处理重复消费？

Y：那就......业务表加唯一索引？

M：对，这是最常用、最靠谱的兜底。继续。

Q2：MyBatis 和 JPA/Hibernate 你怎么选？为什么？

M：同样是视频元数据写入，你会用 MyBatis 还是 JPA？

Y：我都行。JPA 写得少，MyBatis 更可控。

M：在复杂查询、批量更新、性能可控性上怎么考虑？

Y：MyBatis SQL 自己写更清楚；JPA 适合简单 CRUD。

M：回答很务实。再问连接池呢？

Y：HikariCP！快。

M：好。

Q3：分库分表后分页和排序怎么做？

M ：视频列表按 hotScore 排序，分 32 张表，怎么分页？

Y：呃......每张表查一页然后合并？

M：复杂度很高，你还知道其他方案吗？

Y：用 ES？把热榜索引到 Elasticsearch。

M ：这就是业务常见解法：搜索/排序交给 ES，MySQL 做事实存储。不错，但你要讲清楚一致性和延迟。

Y：一致性......最终一致！延迟......几秒以内？

M：过。

Q4：OpenFeign 调用推荐服务超时，你如何做容错？

M：推荐服务偶发超时，接口不能拖垮发布链路。

Y：Resilience4j！加超时、重试、熔断、限流。

M：很好。重试有什么坑？

Y：会把流量打更高......还有非幂等请求不能重试。

M：对。

第三轮（综合：K8s 可观测性/安全/AIGC-RAG/Agent）

Q1：你如何做全链路追踪？如何在 K8s 中落地？

M：用户投诉"发视频卡在 60%"，你怎么定位是哪个服务慢？

Y：用 Zipkin 或 Jaeger，上报 trace。

M：怎么接入？

Y：Spring Boot 加依赖......Micrometer？

M：对。那 traceId 如何在 Kafka 消息里传递？

Y：放到 header 里？

M：可以，继续。

Q2：JWT + Spring Security 怎么做登录与鉴权？

M：社区接口要鉴权，移动端用 JWT。讲下流程。

Y ：登录成功签发 JWT，之后请求带 Authorization: Bearer，Spring Security 校验。

M：JWT 失效和踢人怎么做？

Y：呃......JWT 不可撤销......那就缩短过期时间？

M：还可以做 token 黑名单或使用 Keycloak 这类统一认证。你知道问题点，OK。

Q3：灰度发布怎么做？如何保证可回滚？

M：大促前上新推荐算法，需要灰度。你在 K8s + CI/CD 怎么搞？

Y：Jenkins 打包镜像，K8s 滚动更新，出事就回滚。

M：灰度依据呢？

Y：按......用户 ID？或者按地域？

M：常见方式：按 Header、按用户分桶、按流量比例。回滚要配合指标监控告警。

Y：对对对，Prometheus + Grafana。

Q4：公司要做"智能客服"：企业知识库问答（RAG）并支持工具调用（Agent）。你怎么设计？

M：用户问"视频审核不通过怎么办"，我们要从知识库检索并回答，还要能调用工单系统创建工单。你怎么做？

Y：这个我懂！RAG 就是把文档丢给大模型......然后它就会了。

M：检索在哪里做？向量怎么来？怎么减少幻觉？

Y：向量......用 Embedding 模型算一下，放 Redis？幻觉就......让它别胡说？

M：......你说说 Agent 工具调用怎么标准化？MCP/函数调用你了解吗？

Y：MCP 就是......模型上下文协议嘛，让模型能连工具......具体我回去再看文档。

M：行，思路有，但细节明显不熟。

面试收尾

M：今天先到这里。你基础还可以，工程化和 AI 落地细节需要再补。回去等通知，我们 HR 会联系你。

文末学习区：每题标准答案与场景拆解（小白可直接背/练）

下面按"业务场景 -> 技术点 -> 推荐做法"给出更完整答案。

第一轮答案

1）发布接口幂等

场景：用户重复点击发布/网络重试导致重复创建视频。
技术点：幂等键、去重、分布式锁、唯一约束。
推荐做法 ：
1. 客户端生成 Idempotency-Key（UUID），随请求提交；或服务端先发"创建草稿"拿到 videoId。
2. 服务端以 (userId, idempotencyKey) 作为唯一键：
  - Redis SET key value NX EX 600 做短期幂等窗口（10 分钟）。
  - 数据库落表时加唯一索引兜底（强一致防重复）。
3. 返回第一次创建的结果（查询已存在的记录）。

2）点赞计数

场景：点赞写入频繁，直接写 MySQL 容易打爆。
技术点：缓存写入、异步落库、消息队列、最终一致、幂等。
推荐做法 ：
- Redis 维护计数（INCR video:like:{id}），同时写入事件到 Kafka（like_event）。
- 消费端批量聚合（按视频维度 window 聚合），定时/按量写回 MySQL。
- 防重复 ：事件带 eventId，消费端用唯一索引或去重表防重。
- Redis 宕机：
  - 以 Kafka 事件为事实来源可回放重建；
  - 或使用双写（不推荐无事务保障），更推荐事件源。

3）Full GC 排查

场景：卡顿、RT 飙升、吞吐下降。
技术点：GC 日志、堆转储、对象泄漏分析、线程栈。
推荐做法 ：
- 打开 GC 日志（JDK11+：-Xlog:gc*；JDK8：-XX:+PrintGCDetails -Xloggc）。
- 观察 Full GC 频率/停顿时间/晋升失败。
- jcmd <pid> GC.heap_info / jstat -gcutil 观察。
- jmap -dump:format=b,file=heap.hprof <pid> 导出堆，用 MAT 看 dominator tree。
- 常见原因：
  - 大对象/缓存不受控（Caffeine/Guava Cache 未限制）；
  - 线程本地变量、静态集合导致泄漏；
  - 直接内存（Netty/ByteBuffer）压力传导到 GC；
  - 元空间膨胀（动态类生成）。

第二轮答案

1）Kafka 事件驱动拆分（审核/转码/推荐）

场景：发布链路不能被耗时任务阻塞。
技术点：异步解耦、消息可靠性、重复投递、幂等消费、Outbox。
推荐做法 ：
- 发布服务：写 MySQL（视频元数据）+ 写 Outbox 表（同事务）
- Outbox Relay 异步投递 Kafka，保证"写库与发消息"一致（避免本地事务+MQ 两阶段难题）。
- 下游服务消费：
  - 以 videoId 为幂等键，处理结果落库加唯一约束；
  - Kafka consumer 配置合理的 max.poll.interval.ms、手动提交 offset（视业务）。

2）MyBatis vs JPA/Hibernate 选择

场景：既有简单 CRUD，也有复杂报表/热榜查询。
技术点：ORM 复杂度、SQL 可控性、性能调优、批处理。
推荐原则 ：
- JPA/Hibernate：领域模型清晰、CRUD 为主、希望减少样板代码。
- MyBatis：复杂 SQL、多表 join/窗口函数、极致性能与可控性。
- 混用：核心链路 MyBatis，后台管理/简单表 JPA。
- 连接池优先 HikariCP，配合正确的超时与最大连接数。

3）分库分表的分页排序

场景：全局热榜需要按分数排序分页。
技术点：全局排序、查询下推、索引系统、最终一致。
推荐做法 ：
- 将 hotScore/标签/时间等检索字段写入 Elasticsearch 建索引；
- ES 承担排序分页 + 条件过滤；
- MySQL 存权威数据，列表页可用 ES 返回的 videoId 再批量回表补全。
- 一致性：索引异步更新，允许秒级延迟；关键状态（下架）可做强制过滤/补偿。

4）OpenFeign + Resilience4j 容错

场景：推荐服务抖动不能影响发布核心路径。
技术点：超时、重试、熔断、隔离、降级。
推荐做法 ：
- 超时：连接超时/读超时分开设置。
- 重试：只对幂等请求；指数退避 + 上限。
- 熔断：错误率/慢调用阈值触发，快速失败。
- 降级：返回默认推荐/空列表；埋点打标进入异步补偿。

第三轮答案

1）可观测性：Micrometer + Prometheus/Grafana + Jaeger/Zipkin

场景：发视频卡顿定位瓶颈。
技术点：指标/日志/链路三件套，Trace 传播。
推荐做法 ：
- 指标：Micrometer 暴露到 Prometheus，Grafana 看 QPS/RT/错误率。
- 链路：OpenTelemetry 或 Spring Micrometer Tracing 接入 Jaeger/Zipkin。
- Kafka 传播：把 traceparent/traceId 放到 message header；消费端继续 span。
- 日志：Logback + JSON 格式，traceId 注入 MDC，接 ELK。

2）JWT + Spring Security 鉴权

流程：
1. 登录校验成功 -> 签发 JWT（含 userId、过期时间、权限 scope）。
2. 客户端每次请求带 Authorization: Bearer <token>。
3. Spring Security Filter 校验签名与过期，解析 claim -> 设置 Authentication。
踢人/撤销 ：
- 短过期 + Refresh Token；
- Redis 黑名单（tokenId/jti），登出加入黑名单直到过期；
- 或用 Keycloak/OAuth2 做集中会话与权限管理。

3）K8s 灰度发布与回滚

场景：大促前上新算法，必须可控。
技术点：CI/CD、滚动更新、金丝雀、指标驱动回滚。
推荐做法 ：
- Jenkins/GitLab CI 构建镜像 -> 推镜像仓库 -> 部署到 K8s。
- 灰度策略：
  - 按比例（10%->30%->100%）；
  - 按用户分桶（userId hash）；
  - 按 Header/地域。
- 回滚：
  - K8s Deployment rollout undo；
  - 结合 Prometheus 告警（错误率、P95 延迟）自动触发回滚（可用 Argo Rollouts）。

4）RAG + Agent（含 MCP）落地设计

场景：智能客服/企业文档问答 + 能创建工单。
技术点：文档加载、向量化、向量库、语义检索、提示填充、工具调用、会话记忆、幻觉治理。
推荐架构 ：
1. 离线/准实时索引 ：
  - 文档加载（PDF/网页/工单知识库）-> 分段（chunk）-> Embedding 模型生成向量。
  - 向量存储：Milvus/Chroma/Redis Vector。
2. 在线问答（RAG） ：
  - 用户问题 -> embedding -> 向量检索 topK -> 取回片段（带来源）
  - Prompt 填充：把检索片段作为"上下文"，要求模型"仅基于上下文回答，给出引用"。
3. 减少幻觉 ：
  - 设定回答约束（无依据则说不知道）；
  - 返回引用来源；
  - 置信度阈值：低于阈值走人工/工单；
  - 对关键问题做结构化输出校验（JSON schema / 函数调用）。
4. Agent 工具调用 ：
  - 工具清单：createTicket、queryOrder、getAuditPolicy 等。
  - 通过函数调用/工具执行框架让模型输出结构化参数。
  - MCP（模型上下文协议）：将工具/资源以标准方式暴露给模型（客户端-服务器架构），便于扩展与治理。
5. 会话内存 ：
  - 短期：把最近 N 轮对话放上下文；
  - 长期：对话摘要 + 向量化存储，支持语义回忆。
6. Spring AI ：
  - 作为 Java 侧集成框架，连接 Embedding/VectorStore/ChatModel，快速搭建 RAG 与工具调用。

文章小结

这场面试的套路是：从接口幂等与缓存计数 切入，再到Kafka 事件驱动与数据库/ES 的职责划分 ，最后落到K8s 可观测性与安全 ，并尝试把 RAG/Agent 接进企业业务。小Y能答"是什么"，但在"怎么做得稳、怎么落地可运维"上就开始露馅------这恰好是大厂最看重的部分。