从秒杀电商到AI 智能客服：一场互联网大厂 Java 面试的翻车与进阶（含Spring全家桶 + 微服务 + MQ + 缓存 + RAG）

---

一、面试开场：大厂电商+AI中台岗位

场景：某互联网大厂，招聘“电商&本地生活 + AI 智能客服”方向 Java 高级工程师。面试官老Z严肃冷静，应聘者小Y略显紧张且嘴碎，偶尔还很抽象。

---

二、第一轮：电商秒杀 + 缓存 + 消息队列

业务场景：

做一个支持本地生活团购、秒杀的电商系统，高峰期有直播带货导流，用户量巨大；后续要对接 AI 智能客服做订单咨询。

1.1 面试问答（Round 1，共5问）

面试官： 我们先从基础电商场景开始。假设你要用 Spring Boot + Spring MVC 做一个“本地生活秒杀”服务，对外提供下单接口 /seckill/order。

问题1： 你整体选型和架构会怎么设计？涉及：

• Web 框架
• 数据库和 ORM
• 缓存
• 消息队列
• 日志与监控

---

小Y：

这个……那肯定用 Spring Boot 呀，然后 Controller 一写，Service 一写，Repository 一写，就差不多能跑起来了。数据库就 MySQL 再加个 MyBatis，缓存肯定是 Redis 嘛。消息队列用个 Kafka。日志就 Logback。监控的话……到时候再加？

面试官：

嗯，方向基本对，但如果这是大厂高并发电商、还要对接 AI 服务，你需要更系统一点，细节我等会儿再追问。

---

面试官：

问题2： 秒杀接口在高并发场景下，如何避免 超卖？请结合 Redis、消息队列（Kafka/RabbitMQ）、数据库事务 说说思路。

小Y：

这个我熟！用 Redis 的 DECR 啊，先把库存放 Redis，然后每次请求 DECR，小于 0 就说明没货了。然后下单就写数据库咯。消息队列的话……可以异步减库存？或者异步发个消息通知库存？反正用上了就很高并发了。

面试官：

大致方向是对的，但你说“异步减库存”就有问题了，应该反过来。等会儿我具体拆一下。

---

面试官：

问题3： 如何用 Kafka 或 RabbitMQ 做削峰？秒杀请求进来后，你会怎么设计消息的生产、消费与幂等？

小Y：

这个我也知道！用户一来我就往 Kafka 里塞一条消息，比如 order_create，然后后台有个消费者慢慢消费，就不怕打爆数据库了。幂等的话……搞个去重表，插入失败就说明重复了？或者搞个 Redis set 存一下？

面试官：

有一些典型思路了，不过在幂等、失败重试以及顺序性上你说得还比较粗。

---

面试官：

问题4： 缓存这块，如果你要用 Redis + Spring Cache + 本地 Caffeine 做多级缓存，避免数据库被打穿，你会怎么规划？

小Y：

多级缓存嘛，我就本地先查一下 Caffeine，查不到就查 Redis，还查不到就查数据库，然后回填。Spring Cache 直接打注解就好。至于一致性嘛……一般也不会太不一致吧，差一点问题不大。

面试官：

“差一点问题不大”适合做个人博客，做支付或者库存就不行了（笑）。

---

面试官：

问题5： 我们要把这套服务上线 Kubernetes，配合 Prometheus + Grafana + ELK + Micrometer 监控。你能说说日志和指标埋点怎么做吗？

小Y：

日志我用 SLF4J + Logback，配置个 JSON 输出，然后 Filebeat 或者 Logstash 收集到 ELK。指标的话 Spring Boot Actuator 自带了嘛，Prometheus 去 scrape，然后 Grafana 画图。具体哪些指标……HTTP QPS、RT、错误率？

面试官：

这块还不错，实践经验看着是有的。

---

三、第二轮：AI 智能客服 + RAG + 微服务

业务场景：

在电商系统之上，搭建一套 AI 智能客服系统，支持订单咨询、售后、以及本地生活服务问答。要用到 RAG、向量数据库、Agent 工作流等，并能安全地调用订单、支付、物流等微服务。

2.1 面试问答（Round 2，共5问）

面试官：

问题6： 你如何用 Spring Cloud + Spring AI 搭一套“订单问答 + 物流进度查询”的 AI 智能客服？从微服务拆分、网关、服务间调用说起。

小Y：

微服务我就拆成：用户服务、订单服务、商品服务、客服服务……然后用 Spring Cloud Gateway 做网关，服务注册用 Eureka 或者 Nacos，调用用 OpenFeign。Spring AI 的话就……写个接口调大模型，把用户问题丢给模型，模型再回答就行了。智能客服嘛，大模型很聪明的。

面试官：

你这个更多是“聊天机器人”，还不算“业务型智能客服”，需要结合 工具调用 和 RAG 才行。

---

面试官：

问题7： 需要做 订单问答 + 企业文档问答。我们会把“退款政策、物流规则、商家准入规范”等放到向量数据库（如 Milvus/Chroma/Redis）里，通过 RAG（检索增强生成） 给出更可信的答案。你能说下技术流程吗？

小Y：

RAG 我大概知道，就是先用 Embedding 把文档向量化，然后存到 Milvus 或者 Redis 的向量库里。用户提问的时候也做一次向量化，然后做语义检索，找几段文档丢给大模型，让它参考着回答，这样就不乱编了，减少那个……幻觉，对吧？流程就这样。

面试官：

整体上是对的，但在“文档分片、向量维度选择、召回+重排”这些细节上你就没怎么讲了。

---

面试官：

问题8： 我们要做 Agentic RAG + 工具调用。例如用户问：“帮我查一下昨天那单本地团购的退款进度”。模型要先调用“订单查询工具”，再调用“退款服务工具”，还要从文档库里查“退款 SLA”。你如何设计 工具执行框架 和 调用标准？

小Y：

Agent 嘛，就是给模型一堆工具，然后它自己想办法调用。我会定义一堆 HTTP API，比如 /api/orders/{id}、/api/refunds/{id}，然后告诉模型这些文档就好了。调用标准的话……可以用 JSON Schema？然后模型按这个格式返回一个 JSON，我再去调用。框架就……Spring Boot 写一层中台，转发一下。

面试官：

概念上已经碰到点边了，但你明显没实际搞过，到底谁负责“流程编排、重试、回滚、长对话记忆”你说得比较虚。

---

面试官：

问题9： 聊到 会话内存。智能客服需要记住用户之前问过的问题，比如先问“我昨天那单没收到货”，后面又说“那就给我退款吧”，需要在多轮中理解上下文。你怎么实现 聊天会话内存？

小Y：

会话内存嘛，我就把前几轮聊天记录都拼到 Prompt 里，发给模型就好了。用 Redis 存一下 history，比如按 sessionId 存 JSON 数组。多轮对话就读出来，截断一下。这样就有记忆了。

面试官：

这个方案是最常见的起点，但在上下文长度、成本、摘要策略上要更细致一些。

---

面试官：

问题10： 安全这块，智能客服要查订单、退款，涉及隐私数据。你会如何利用 JWT/OAuth2 + Spring Security + 权限控制 来保证：

• 用户只能查自己的订单
• Agent 调用微服务必须鉴权

小Y：

安全……JWT 肯定要的。用户登录以后发个 JWT，里面带上 userId。智能客服在调用订单服务时，把 userId 传过去，订单服务校验一下。Spring Security 我就配个过滤器，验证 JWT。至于 OAuth2……可以配 Keycloak 做统一认证？

面试官：

核心思路有，但你没讲清楚“Agent 代表谁”“服务之间如何信任”等问题。

---

四、第三轮：搜索、风控、CI/CD 与观测

业务场景：

电商+本地生活平台扩展了：搜索推荐、广告投放、风控拦截，支撑大规模用户和高并发。要求具备从开发到上线、再到观测与调优的完整能力。

3.1 面试问答（Round 3，共5问）

面试官：

问题11： 我们要做“附近好店 + 秒杀商品”的搜索，使用 Elasticsearch + Spring Data。需要支持：关键词搜索、地理位置搜索、以及基于评分的排序。你会怎么设计索引结构和查询？

小Y：

Elasticsearch 就建个 index，比如 shop_item。字段就：title、description、price、location、score，然后用 match 查标题，用 geo_distance 查附近，用个 sort 按 score 排序。Spring Data Elasticsearch 里写个 Repository 接口，方法名一写就行，比如 findByTitle。

面试官：

基础搜索还行，但对分页、排序组合、查询性能和分词细节你还说得比较笼统。

---

面试官：

问题12： 大促期间，我们要防止恶意刷单、薅羊毛，需要做 风控系统。比如：同一设备、同一 IP、相似账号频繁下单。你会怎么用 Redis、Kafka、Flink/Spark、规则引擎 做实时风控？

小Y：

风控系统就先在下单的时候打点，把订单事件写到 Kafka 里，然后用 Flink 来做实时计算，比如按 IP 做窗口统计，看一分钟内下单多少次。Redis 可以存一些黑名单、白名单。规则的话……可以放在数据库，然后在 Flink 里读出来判断？或者搞个 Drools 之类的规则引擎？

面试官：

整体方案还算像个样子，不过你没聊“特征计算、特征存储、离线+实时融合”等。

---

面试官：

问题13： 说说你的 CI/CD 流水线。我们在 GitLab 上开发，用 GitLab CI / Jenkins + Docker + Kubernetes。从代码提交到上线，整个流程你如何设计？

小Y：

流程就是：

1. 开发提交代码到 GitLab；
2. GitLab CI 或 Jenkins 触发构建，先跑 Maven 测试（JUnit、Mockito）；
3. 构建 Docker 镜像，推到 Harbor 或 GitLab Registry；
4. 用 kubectl 或 Helm 部署到 Kubernetes；
5. 有问题就回滚上一版镜像。流水线脚本就 .gitlab-ci.yml 里写几个 stage：build、test、deploy。

面试官：

这块还行，有基础实践。

---

面试官：

问题14： 在观测方面，我们要做到 全链路追踪 + 指标 + 日志，用于分析调用链路、慢请求、错误根因。你会如何用 Micrometer + Prometheus + Grafana + Jaeger/Zipkin + ELK 做全链路观测？

小Y：

全链路嘛，Spring Cloud Sleuth 以前可以，现在用 Micrometer Tracing，也能打 traceId、spanId。日志输出 traceId，ELK 里就能按链路搜。Prometheus 采集服务的指标，Grafana 画出响应时间、QPS、错误率。Jaeger 或 Zipkin 收集 trace，这样一个请求从网关到订单服务到支付服务都能看到。整体就这样。

面试官：

概念比较清楚，但你没有提到采样策略、标签规范化这些更工程化的内容。

---

面试官：

问题15： 最后一个综合问题。假设线上出现“下单慢、支付失败率升高”的告警，你作为后端负责人，会如何排查？请结合我们前面提到的：日志、指标、链路追踪、消息队列、数据库与缓存。

小Y：

首先看看 Grafana，有没有某个接口 RT 飙升，错误率升高。如果是下单接口，就去看链接的链路 trace，看是卡在订单服务，还是库存服务，还是支付网关。日志里搜一下异常。然后看看 Redis、数据库是不是 QPS 或连接数满了。消息队列看一下堆积。大概就这样，一顿排查下来，肯定能发现点问题。

面试官：

思路是对的，但回答偏“嘴上排查”，缺少具体指标和操作细节。

---

五、面试结束语

面试官：

今天就聊到这吧。整体来看，你在 Spring Boot、电商基础、部分中间件使用上有实战基础；但在 微服务治理、AI Agentic RAG、安全、观测和工程化细节 上还比较浅。

我们会综合评估后，回去等通知。

小Y尴尬又不失礼貌地点点头，起身离开面试间。

---

六、详细解析：把刚才的面试聊清楚（给小白看的部分）

下面按主题，把上面的问题拆开详细讲一遍，帮助你从零理一套“大厂电商 + AI 智能客服”技术图谱。

---

6.1 电商秒杀：从接口到高并发架构

6.1.1 选型与整体架构（对应问题1）

目标： 做一个本地生活+电商秒杀服务，支持高并发、易扩展。

核心选型：

• 语言 & 平台：Java 11/17 + Spring Boot + JVM
• Web 框架：Spring MVC（同步接口）
• 持久化：
  • MySQL 作为主数据库
  • ORM：MyBatis 或 JPA（Hibernate），大厂电商多用 MyBatis 便于写复杂 SQL
  • 连接池：HikariCP
  • 数据库版本管理：Flyway 或 Liquibase
• 缓存：
  • Redis 作为分布式缓存
  • 本地缓存：Caffeine / Ehcache
  • Spring Cache 做统一抽象
• 消息队列：Kafka 或 RabbitMQ（大流量建议 Kafka）
• 日志：SLF4J + Logback 或 Log4j2
• 监控：Micrometer + Prometheus + Grafana
• 部署：Docker + Kubernetes

一个典型架构：

• 前端/网关：Nginx / Spring Cloud Gateway
• 秒杀服务：Spring Boot，负责接收请求、校验参数、防重、写消息队列
• 订单服务：从消息队列消费消息，落库、减库存
• 缓存层：Redis 管理商品库存和热点数据
• 数据库：MySQL 分库分表（后期）

6.1.2 防止超卖：Redis + MQ + DB（对应问题2）

1）典型错误思路：

• 直接在数据库 UPDATE stock = stock - 1 WHERE stock > 0，在高并发下容易锁冲突、性能差。

2）常见正确方案：

• 步骤A：预热库存到 Redis

  • 活动开始前，把商品库存写入 Redis，例如 stock:skuId -> 1000

• 步骤B：请求进来先在 Redis 预减库存

  stock = DECR "stock:skuId"
  if stock < 0:
      // 回滚 Redis 库存 + 拒绝请求
      INCR "stock:skuId"
      返回 “已售罄”
  else:
      // 写入消息队列，后续异步下单
      send MQ(orderRequest)
  

  Redis 单线程 + 原子操作，性能高且避免了多线程竞争导致的超卖。

• 步骤C：消息队列异步处理订单

  • 消费者从 Kafka/RabbitMQ 中读取订单消息
  • 在数据库中：
    • 验证库存（可加乐观锁或防止异常数据）
    • 创建订单记录

• 保证一致性：

  • 核心：Redis 预减只作为“资格预判”，真正库存还是以数据库为准
  • 针对失败订单可以在后续做“补库存队列”或定时任务回滚

优点：

• 限流：Redis 限制了进入 MQ 的请求数量
• 削峰：MQ 平滑流量，保护 DB

6.1.3 消息队列削峰与幂等（对应问题3）

削峰思路：

1. 所有秒杀请求不直接操作数据库，而是 写入 MQ（Kafka Topic：seckill_orders）
2. 消费者根据自身能力设置消费速率，批量处理或单条处理
3. 当 MQ 堆积时，说明系统压力大，可以临时限流或扩容消费者

幂等处理：

问题：

• 消息可能 重复投递（网络抖动、重试）
• 如何避免重复创建订单？

常用做法：

1. 业务幂等键：
   • 例如 userId + skuId + activityId 作为唯一键
   • 在订单表上加唯一索引，重复插入会失败
2. 幂等表 / Redis 标记：
   • 下单前在 Redis 里 SETNX order:token -> processing，如果已存在则认为重复
3. MQ 消息唯一 ID + 消费记录：
   • Kafka 的 offset 管理 + 消费端做到“处理成功才 commit offset”

6.1.4 多级缓存与缓存一致性（对应问题4）

多级缓存结构：

1. 本地缓存（Caffeine）：
   • 访问速度最快，避免每次都访问 Redis
2. 分布式缓存（Redis）：
   • 多实例之间共享数据

读流程：

1. 先查 Caffeine
2. 未命中，再查 Redis
3. 还未命中，查数据库并回填 Redis 和 Caffeine

缓存一致性常见策略：

1. Cache-Aside（旁路缓存）模式：
   • 读：先读缓存，缓存 miss 再读 DB
   • 写：
     • 先写 DB
     • 再删缓存（而不是更新缓存，避免次序问题）
2. 消息通知：
   • 更新数据后，发一条 MQ 通知，其他服务/节点订阅消息，做缓存失效
3. 热点 Key 保护：
   • 本地加互斥锁，避免海量请求同时穿透到 DB

6.1.5 日志与监控（对应问题5）

日志：

• 统一使用 SLF4J 接口 + Logback 实现
• 输出 JSON 格式日志，包含：
  • traceId/spanId
  • userId
  • requestId
  • 业务关键字段（orderId、skuId）
• 通过 Filebeat/Logstash 收集到 Elasticsearch，Kibana 查询

指标（Metric）：

• 使用 Micrometer + Prometheus
• 关键监控：
  • HTTP 请求 QPS、RT、错误率
  • Redis QPS、命中率
  • Kafka 消费堆积量
  • DB 连接数、慢查询
• Grafana 统一展示

---

6.2 AI 智能客服与 RAG：从聊天到具备业务能力的 Agent

6.2.1 智能客服整体架构（对应问题6）

目标：

• 支持“订单咨询、物流查询、退款进度、政策解释”等
• 用户通过 App/H5/小程序接入

微服务拆分：

• 用户服务（User Service）
• 订单服务（Order Service）
• 支付服务（Payment Service）
• 物流服务（Logistics Service）
• 客服服务（Customer Service）
• AI 中台服务（AI Service）：
  • 封装 Spring AI / OpenAI / Ollama
  • 统一管理 Prompt、模型、RAG、工具调用

请求链路：

1. 用户在前端输入问题→ 网关（Spring Cloud Gateway）
2. 网关路由到 AI Service
3. AI Service：
   • 解析意图（订单问题、物流问题、政策问答等）
   • 需要实时数据（订单、物流）→ 调用对应微服务
   • 需要知识问答（退款政策、服务规则）→ 走 RAG
   • 把结果组合后让大模型生成自然语言回答

6.2.2 RAG 技术流程（对应问题7）

RAG（Retrieval-Augmented Generation）核心是：

“先检索，再生成”，让模型 参考内部文档 回答问题，减少胡编乱造（Hallucination）。

步骤1：文档处理与向量化

1. 收集文档：
   • 退款政策、物流条款、商家规则、用户协议等
2. 文档分片（chunking）：
   • 按自然段、标题，加上一定重叠，如每 300~500 字为一片
3. 向量化：
   • 使用 Embedding 模型（OpenAI、Ollama）将每个分片转为向量
   • 向量维度 384 / 768 / 1536 等
4. 存储到向量数据库：
   • Milvus / Chroma / Redis Search
   • 记录：向量 + 原文片段 + 元数据（文档类型、时间、业务线）

步骤2：在线查询

1. 用户提问：
   • “本地生活团购退款多久到账？”
2. 提问向量化：
   • 用同一个 Embedding 模型将问题转为向量
3. 语义检索：
   • 在向量库中做 KNN 搜索，取 Top-K 片段
   • 可以结合传统关键词过滤 + 语义召回
4. 重排（可选）：
   • 对候选片段进一步排序

步骤3：生成答案

• 构建 Prompt：

  你是电商平台智能客服。下面是与“退款政策”相关的内部文档片段：
  [DOC1] ...
  [DOC2] ...
  根据这些文档，用简明语言回答用户问题。如果文档中没有的信息，明确说“文档中没有相关说明”。
  用户问题：{user_question}
  

• 交给大模型生成答案

优势：

• 可以保障回答和企业真实规则一致
• 新政策只需更新文档和向量库，不用重训模型

6.2.3 Agentic RAG 与工具调用（对应问题8）

在基础 RAG 之上，Agent 让模型可以“调用工具”，比如：

• 查订单详情
• 查物流轨迹
• 创建售后工单

关键点：工具规范化与调度框架

1. 工具描述标准：

   • 使用 JSON Schema 或 OpenAPI 描述每个工具：
     • 名称：get_order_by_id
     • 入参：orderId（string）
     • 出参：订单详情 JSON

2. Agent 调用流程：

   • 模型先根据用户问题，输出需要调用的工具及参数（按约定 JSON 格式）
   • 后端解析 JSON，调用真实微服务 API
   • 把结果再作为上下文喂给模型，让它生成最终答案

3. 工具执行框架要处理：

   • 多工具顺序 / 并行执行
   • 失败重试 / 回退策略
   • 超时与取消
   • 长流程（如退款审批）需要状态管理

4. Agentic RAG 的组合：

   • 既能调用工具查实时数据，又能检索文档解释规则

6.2.4 会话内存设计（对应问题9）

简单做法：

• 每轮对话存一条记录到 Redis 或数据库：
  • sessionId、用户问题、模型回答、时间戳
• 新问题来时，取最近 N 轮（如 5 轮）拼接成 Prompt

问题：

• 对话长了会超出模型上下文长度（Token 限制）
• 成本高（更多 Token）

优化策略：

1. 分层记忆：
   • 近期对话：原文保存
   • 历史对话：压缩为“摘要”，如每 10 轮做一份总结
2. 检索式记忆：
   • 对历史对话内容做向量化，存向量库
   • 新问题时按语义检索相关对话片段

6.2.5 安全与权限控制（对应问题10）

问题一：用户身份认证

• 用户登录后，授权服务器（如 Keycloak）颁发 JWT
• JWT 中包含：
  • sub（userId）、roles、exp 等
• 前端每次请求带上 Authorization: Bearer <token>

问题二：智能客服调用微服务时的权限

• AI Service 在网关后面，需要：
  • 代表当前用户调用订单服务、支付服务
• 常见方案：
  1. 网关验证 JWT，解析出 userId
  2. 将 userId 写入请求头，如 X-User-Id
  3. 后端所有服务统一在 Spring Security 过滤器里从 Header 中取 userId
  4. 订单服务在查询时校验 order.userId == X-User-Id

问题三：Agent 调用工具时的“身份”

• Agent 实质上是 以用户身份在行动：
  • 不应该查别人的订单
  • 不应该执行用户没有权限的操作
• 解决：
  • 工具调用时必须附带用户身份信息（userId / JWT）
  • 工具在服务端做权限校验

---

6.3 搜索、风控、CI/CD 与全链路观测

6.3.1 Elasticsearch 搜索（对应问题11）

索引设计：

• Index：shop_item
• 字段示例：
  • id: keyword
  • title: text（带中文分词器）
  • description: text
  • price: double
  • location: geo_point（经纬度）
  • score: double（综合评分）
  • tags: keyword（美食、团购、本地生活）

查询示例：

• 查询“附近 5km 内评分最高的火锅店”：

{
  "query": {
    "bool": {
      "must": [
        {"match": {"title": "火锅"}}
      ],
      "filter": [
        {
          "geo_distance": {
            "distance": "5km",
            "location": {
              "lat": 31.23,
              "lon": 121.47
            }
          }
        }
      ]
    }
  },
  "sort": [
    {"score": "desc"}
  ],
  "from": 0,
  "size": 20
}

Spring Data Elasticsearch 可以定义 Repository 或使用 ElasticsearchRestTemplate 构造查询。

6.3.2 实时风控系统（对应问题12）

目标：

• 检测恶意刷单、羊毛党、机器人行为

数据管道：

1. 下单服务将订单事件写入 Kafka Topic：order_events
2. 风控计算：Flink Job 消费 order_events
   • 按用户、IP、设备 ID 做滑动窗口统计
   • 特征示例：
     • 5 分钟内下单次数
     • 不同收货地址数量
     • 相似支付账号数量
3. 结果写入：
   • Redis（实时风控结果，黑/白名单标记）
   • Elasticsearch（用于离线分析）

决策方式：

1. 规则引擎：
   • 简单规则：
     • 单 IP + 单设备 1 分钟内下单 > N，标记为风险
   • 可用 Drools 等规则引擎管理规则
2. 机器学习模型（进阶）：
   • 特征工程 + 模型训练
   • 在线推断时根据特征打分

6.3.3 CI/CD 流水线（对应问题13）

一个标准流水线：

1. 代码提交：
   • feature 分支提交到 GitLab
2. CI：构建与测试
   • 触发 GitLab CI / Jenkins Pipeline
   • 步骤：
     1. mvn clean test（JUnit 5、Mockito、集成测试）
     2. 代码扫描（SonarQube）
     3. 构建 jar 包，并打 Docker 镜像
     4. 推送镜像到镜像仓库（Harbor / GitLab Registry）
3. CD：部署到 Kubernetes
   • 使用 Helm 或 Kustomize 管理应用配置
   • GitLab CI 中执行 helm upgrade --install
   • 支持蓝绿发布 / 灰度发布
4. 回滚机制：
   • 记录每次部署使用的镜像版本
   • 一键回滚到上一版本

6.3.4 全链路观测（对应问题14）

1）Tracing：

• 使用 Micrometer Tracing + OpenTelemetry + Jaeger/Zipkin
• 在网关层创建 traceId，自动在服务间传递
• 每个服务记录 span（开始时间、结束时间、标签）
• 在 Jaeger UI 中查看某个请求从入口到各服务的调用链

2）Metrics：

• Micrometer 输出 Prometheus 格式指标
• 统一命名规范：
  • http_server_requests_seconds、kafka_consumer_records_lag
• Grafana 仪表盘显示：
  • 服务 RT、错误率
  • JVM 内存、GC、线程

3）Logs：

• 日志中带 traceId，用于和 tracing 关联
• ELK 中可以按 traceId 搜索某条请求的日志

4）告警：

• Prometheus Alertmanager 根据指标规则触发
• 常见规则：
  • 错误率 > 1%
  • 订单创建接口 95 线延迟 > 200ms

6.3.5 故障排查思路（对应问题15）

假设场景：“下单慢、支付失败率升高”。排查步骤：

1. 从告警入手：
   • 哪个接口错误率升高？是订单接口还是支付接口？
2. 看指标：
   • 订单服务 CPU/内存、线程数
   • 数据库连接数是否打满
   • Redis/Kafka 延迟是否上升
3. 看链路 Trace：
   • 在 Jaeger 上找到一个慢请求
   • 看是卡在订单服务处理、库存服务、还是调用支付网关
4. 看日志：
   • 根据 traceId 查订单服务、支付服务日志
   • 是否有超时、连接失败、第三方报错
5. 快速止血：
   • 启用限流 / 降级策略
   • 比如暂时关闭非核心功能（优惠券、推荐）
6. 定位根因：
   • 可能是：
     • 新版本引入的慢 SQL
     • Redis 短暂抖动
     • 第三方支付接口超时

---

七、总结

通过这场“略显翻车”的大厂面试，我们串起了：

• 电商秒杀与高并发：Redis、MQ、缓存、数据库、监控
• AI 智能客服：Spring AI、RAG、Agent、向量数据库、会话内存
• 搜索与风控：Elasticsearch、Flink/Kafka、Redis
• 工程化能力：CI/CD、Kubernetes 部署、全链路观测

把这些问题真正吃透，你在互联网大厂 Java 岗位的面试里，就不会像小Y那样“有点会、又没完全会”，而是能用 系统化的架构思维 与 落地细节 赢得面试官的认可。