大厂Java面试实录：Spring Boot+Spring Cloud+Kafka+Redis+JVM调优 + Spring AI(RAG/向量库)一条链路问到底

场景：某互联网大厂电商业务（内容社区UGC + AIGC智能客服），候选人：小Y（自称“全栈”，实际水货但会背八股）。

第一轮：从“下单接口”切入（Spring Boot / MVC / ORM / 连接池 / Flyway）

面试官（严肃）：我们先从你最熟的开始。电商下单接口，你会怎么设计？

小Y（搞笑）：就……一个 POST /orders，然后 @RestController 接一下，进来就 orderService.create()，最后返回个 OK。稳。

面试官：稳不稳要看细节。第一个问题：

Q1. 订单创建接口在 Spring MVC 里怎么做参数校验与幂等？

小Y：校验我会，用 @Valid。幂等嘛……加个 synchronized？

面试官：synchronized 只能锁一台机器。继续。

Q2. 你用 MyBatis 还是 JPA？订单这种表怎么做“防超卖”的事务设计？

小Y：我都行。防超卖就……事务 @Transactional，然后更新库存。

面试官：事务只是基础，关键在并发控制。

Q3. HikariCP 为什么是默认连接池？你怎么排查连接池耗尽？

小Y：因为快。排查就看日志……或者重启。

面试官（微微皱眉）：重启是最后手段。

Q4. 数据库变更你用 Flyway 还是 Liquibase？怎么保证多环境一致？

小Y：都差不多吧，我一般让 DBA 直接改……

面试官：行，我们进入第二轮。

第二轮：订单量上来后的“微服务链路”（Spring Cloud / OpenFeign / Kafka / Redis / Resilience4j）

面试官：订单服务拆成：订单、库存、支付、优惠券。高峰期你怎么保证系统不被打爆？

小Y：加机器。再加。

面试官：加机器之前先把架构说清楚。

Q5. 订单调用库存用 OpenFeign，同步调用超时怎么办？你会怎么做熔断与重试？

小Y：超时就调大点。熔断我知道，Hystrix……（停顿）现在用 Resilience4j 对吧。

面试官：对。那重试会带来什么问题？

小Y：会……重试成功？

Q6. “下单成功发消息”你用 Kafka 还是 RabbitMQ？为什么？

小Y：Kafka 吧，大厂都用。RabbitMQ 也行。

面试官：那你说说至少三点差异。

小Y：Kafka 更快；Rabbit 更……不快。

面试官：……继续。

Q7. 订单查询为什么要上 Redis？缓存一致性怎么处理？

小Y：因为快。一致性就设置过期时间，五分钟一过期就一致了。

面试官：过期不是一致性方案。

Q8. 你怎么给“下单链路”做观测？Prometheus/Grafana/ELK/Jaeger 你怎么选？

小Y：都装上。

面试官：装上只是开始，指标/日志/链路要有方法。

第三轮：加上“AIGC智能客服/企业知识库”（Spring AI / RAG / 向量库 / 幻觉治理 / 工具调用）

面试官：我们有内容社区UGC，商家和用户会问：\“为什么我的订单被取消？\” 传统客服成本太高，所以要做 AIGC 智能客服。你怎么落地？

小Y：接个大模型 API，让它回答就行。

面试官：那幻觉怎么办？

Q9. RAG 的核心链路是什么？“检索”和“生成”分别解决什么问题？

小Y：RAG 就是……先查一下再回答。查完就更准。

面试官：方向对，细节呢？

Q10. 向量化（Embedding）怎么做？向量库选 Milvus/Chroma/Redis 的考虑是什么？

小Y：Embedding 就是把文字变成数字。向量库……我觉得 Redis 就行，大家都装了。

面试官：Redis 不是不能用，但要说清边界。

Q11. 你如何设计“工具执行框架/Agent”，让客服机器人能查订单、查物流，而不是胡说？

小Y：让模型自己想办法查？它挺聪明的。

面试官：不，它需要受控的工具调用。

Q12. 生产环境怎么做“对话记忆”和“权限控制”？（JWT/OAuth2/Keycloak）

小Y：记忆就存在内存里，权限用 JWT。

面试官（终于露出一点笑意）：你至少知道 JWT。好了，今天先到这。

面试结束

面试官：整体来看，你对基础概念有一些了解，但在分布式一致性、消息语义、可观测性以及 RAG 工程化上还需要补齐。你先回去等通知，有结果我们 HR 会联系。

小Y：好的好的，我回去就把 Kafka 和 RAG 都“再熟悉一下”。

题目参考答案（含业务场景与技术点，小白可直接学）

下面把每道题按“业务目标 → 关键技术点 → 可落地做法/示例”讲清楚。

A1. Spring MVC 参数校验与幂等

业务场景：用户可能重复点击“提交订单”，或客户端重试导致同一请求多次到达；需要防止创建多个订单。

关键技术点：

  • 参数校验：javax/jakarta.validation（@Valid、@NotNull、@Size）+ @ControllerAdvice 统一错误返回
  • 幂等：
    • 幂等键（Idempotency-Key）：客户端生成（或服务端下发），服务端基于 Redis/DB 唯一约束保证只处理一次
    • 分布式锁仅作为辅助手段（Redisson），但要考虑锁超时与续租

落地做法：

  1. 请求头带 Idempotency-Key（或 body 里带 requestId）。
  2. 服务端在 Redis SET key value NX EX 60 成功才继续；失败直接返回上次结果（可把结果也缓存）。
  3. DB 层加唯一约束：unique(user_id, request_id) 双保险。

A2. MyBatis/JPA 选择与防超卖事务设计

业务场景：秒杀/大促时库存并发扣减，避免卖超。

关键技术点：

  • 并发控制常见手段：
    • 乐观锁：版本号 version 或条件更新
    • 悲观锁：select ... for update
    • 原子扣减：update stock set available=available-? where sku_id=? and available>=?
  • 事务边界：订单创建、库存扣减、支付是跨服务的，需要最终一致性（Outbox / 事务消息 / Saga）

推荐实现（高并发常用）：

  • 库存扣减用单条 SQL： 
    update sku_stock
set available = available - 1
where sku_id = ? and available >= 1;

    返回 1 行表示成功，否则库存不足。

  • 订单服务本地事务只保证：订单落库 + 写出“订单已创建事件”（见 A6 Outbox）。

MyBatis 更适合复杂 SQL/可控性强；JPA 适合快速 CRUD，但要避免 N+1、注意 flush 时机。

A3. HikariCP 为何快 & 连接池耗尽排查

业务场景：高峰期接口卡住，线程堆积，最终大量超时。

关键技术点：

  • HikariCP 设计目标：低开销、少锁、快速获取连接
  • 连接池耗尽常见原因：
    1. SQL 慢/未命中索引
    2. 连接泄漏（未关闭 ResultSet/Statement/Connection）
    3. 池子配置不合理（maxPool 太小/线程太多）

排查手段：

  • 开启 Hikari 指标（Micrometer）观察：hikaricp_connections_active/pending/idle
  • 配置 leakDetectionThreshold（慎用，定位泄漏）
  • 结合数据库 slow log 与应用 APM（New Relic/Jaeger）找慢点

A4. Flyway vs Liquibase，多环境一致性

业务场景：开发/测试/预发/生产多套环境，必须确保 schema 演进可追溯、可回放。

关键技术点：

  • Flyway：SQL migration 为主，简单直接
  • Liquibase：支持 XML/YAML/JSON changeSet，表达力强
  • 核心是：迁移脚本进入版本控制（Git），由 CI/CD 自动执行

落地建议：

  • 每次发版自动跑 migration（Jenkins/GitLab CI）
  • 生产禁止手工改表；紧急修复也要补 migration

A5. Feign 超时、熔断、重试与副作用

业务场景：订单调用库存，库存偶发抖动；不能把订单线程一直挂死。

关键技术点：

  • 超时：连接超时/读超时
  • Resilience4j：
    • CircuitBreaker（熔断）
    • TimeLimiter（超时）
    • Bulkhead（隔离）
    • Retry（重试）

重试的坑：

  • 可能导致重复扣库存/重复扣款（非幂等接口）

正确做法：

  • 对“查询类”接口可重试；对“写入类”接口必须先做幂等（A1）再谨慎重试
  • 熔断后走降级：如返回“系统繁忙，请稍后重试”，或进入排队/异步化

A6. Kafka vs RabbitMQ：怎么选

业务场景：下单后通知：支付、风控、推荐、积分都要消费。

关键技术点（典型差异）：

  1. 模型：Kafka 更像分布式日志（可回放）；RabbitMQ 是传统消息队列（路由灵活）
  2. 吞吐：Kafka 擅长高吞吐顺序写；RabbitMQ 延迟更低、路由更丰富
  3. 消费语义：两者都常见 at-least-once，需要业务幂等；Kafka offset 可控、便于回溯
  4. 生态：Kafka 与大数据（Flink/Spark）天然联动

电商事件流常用：Kafka（订单事件、埋点日志）；需要复杂路由/延迟队列可选 RabbitMQ。

可靠落地（Outbox 模式）：

  • 本地事务内写 order + outbox_event
  • 异步投递器把 outbox 推到 Kafka，成功后标记已投递
  • 避免“数据库提交了但消息没发出去”的双写问题

A7. Redis 缓存与一致性

业务场景：订单详情查询 QPS 极高，直接打 DB 成本大。

关键技术点：

  • Cache-Aside（旁路缓存）模式：
    • 读：先 Redis，miss 再查 DB 回填
    • 写：先写 DB，再删缓存（或更新缓存）
  • 防穿透：布隆过滤器/空值缓存
  • 防击穿：热点 key 互斥锁 + 逻辑过期
  • 防雪崩：过期时间加随机抖动、多级缓存（Caffeine+Redis）

一致性推荐策略：

  • 写路径：事务提交后删除缓存（可用事务同步回调/消息通知）
  • 对强一致要求高的字段（如支付状态），可短时间直查 DB 或使用订阅 binlog/消息驱动更新

A8. 可观测性：Prometheus/Grafana/ELK/Jaeger 怎么用

业务场景：用户说“下单很慢”，你要快速定位是哪个环节慢。

关键技术点：

  • 指标 Metrics：Prometheus + Grafana（看容量、错误率、延迟 P99）
  • 日志 Logs：ELK（按 traceId 检索）
  • 链路 Traces：Jaeger/Zipkin（定位跨服务耗时）
  • Java 统一埋点：Micrometer + OpenTelemetry

落地建议：

  • 统一 traceId（log pattern 输出）
  • 三个黄金指标：Latency/Traffic/Errors（再加 Saturation）
  • 为下单链路建立 Dashboard：下单成功率、库存失败率、支付超时率、Kafka 堆积等

A9. RAG 核心链路与价值

业务场景：客服要基于“真实订单规则、退款政策、用户订单信息”回答，不能编。

关键技术点：

  • RAG = Retrieval（检索）+ Augmented（增强）+ Generation（生成）
  • 检索解决：把正确资料找出来（企业知识库、FAQ、规则、工单）
  • 生成解决：把资料组织成自然语言答案（并可附引用）

标准链路：

  1. 文档加载（PDF/网页/数据库）→ 分段（chunk）
  2. Embedding 向量化 → 写入向量库
  3. 用户问题 → 向量检索（topK）+ 关键词/过滤（如按业务线、权限）
  4. 把检索结果作为上下文塞入 Prompt（提示填充）
  5. LLM 生成答案 + 引用来源

A10. Embedding 与向量库选型（Milvus/Chroma/Redis）

业务场景：知识库规模从 1 万段增长到 1000 万段，查询还要快。

关键技术点：

  • Embedding 模型：OpenAI / 本地 Ollama 等
  • 向量库核心能力：近似最近邻 ANN、索引（HNSW/IVF）、过滤、扩容、持久化

选型建议：

  • Chroma：轻量/原型快，适合小规模或本地实验
  • Redis Vector：运维简单（已有 Redis），适合中小规模、对过滤要求一般的场景
  • Milvus：更偏专业向量数据库，适合大规模、多索引、多租户与更复杂检索

结论：不是“都用 Redis”，而是按规模与运维能力取舍。

A11. Agent/工具调用：让机器人“会查系统”而不是瞎编

业务场景：用户问“我订单为什么取消”，答案必须来自订单状态机/风控结果，而不是模型猜。

关键技术点：

  • 工具调用标准化（Tool Calling）：把可执行能力以函数/HTTP API 暴露
  • Agent 工作流：
    • 识别意图 → 选择工具 → 调用工具 → 将结果写回上下文 → 生成回答
  • 关键是：受控（白名单工具、参数校验、超时、审计）

落地做法：

  • 定义工具：getOrderStatus(orderId), getLogistics(trackingNo), searchPolicy(keyword)
  • Agent 只允许调用这些工具；每次调用记录审计日志
  • 结合 RAG：先检索政策，再查订单数据，最后合成回答

A12. 会话记忆与权限控制（JWT/OAuth2/Keycloak）

业务场景：客服系统面向 C 端用户与商家；不同人能看到的数据不同；多轮对话要记住上下文。

关键技术点：

  • 会话记忆（Chat Memory）：
    • 短期：最近 N 轮对话（可存在 Redis）
    • 长期：用户偏好/历史问题（需要脱敏与合规）
  • 权限控制：
    • OAuth2/OIDC（Keycloak）统一身份
    • JWT 携带用户身份与 scope；服务端做资源鉴权

推荐落地：

  • 网关层校验 JWT（Spring Security Resource Server）
  • 工具调用时做二次鉴权：确保 orderId 属于该用户
  • 对话内容持久化需脱敏（手机号、地址）并设置保留周期

以上答案如果你能在项目里真正落地，面试官问到第三轮通常不会让你“回去等通知”。

Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

亲测10款降AIGC工具，这款神器让你论文告别机翻感

avatar AtomGit开源社区
cover

亲测10款降AIGC工具，这款神器让你论文告别机翻感

avatar AtomGit开源社区
cover

你可能还不知道，「测试用例」竟是AI时代提升效率的关键

avatar AtomGit开源社区