从秒杀电商到AI客服：Java大厂面试三轮追问（Spring Boot, MySQL, Redis, Kafka, 微服务, RAG 实战）

从秒杀电商到AI客服：Java大厂面试三轮追问（Spring Boot, MySQL, Redis, Kafka, 微服务, RAG 实战）

场景：互联网大厂 Java 面试，业务方向：电商秒杀 + AI 智能客服。

人物：

• 面试官：技术很强、说话很直，但会适当引导。
• 小Y：简历写满技术栈的“水货程序员”，简单问题还能答上来，难一点就开始含糊其辞、胡乱发挥。

第一轮：电商秒杀基础与整体架构

Round 1 · Q1：电商秒杀整体技术架构怎么设计？

面试官：先从简单的来。我们有一个电商秒杀场景，双11抢购限量商品。你用 Java 技术栈，简单说一下整体架构怎么设计？

小Y：这个我熟！首先肯定是Spring Boot做 Web 服务嘛，然后前端发请求到后端接口，然后我们用MySQL存商品和订单，用Redis做一下缓存就行了。压力大的话，我们可以加几台机器，搞个Nginx负载均衡，差不多就稳了。

面试官：嗯，方向还行。那具体一点，比如防止超卖、扛高并发，你在架构上还会加什么？

小Y：啊……这个嘛……可以多多用 Redis 呀，然后……呃，也可以用一下Kafka，反正把请求先放到队列里面慢慢处理，这样就不会打挂 MySQL。然后如果再不行，就再加机器，扩容一下 Kubernetes 啊，嗯，大概就是这样一个分布式的……云原生架构。

面试官：嗯……“云原生架构”四个字说得很有精神，细节我们待会再聊。

Round 1 · Q2：如何防止超卖？（Redis + MySQL）

面试官：那我们就顺着超卖说。一个商品库存 100 件，10 万用户同时来抢，你怎么保证不会卖出 101 件？

小Y：这个很简单啊，我在 MySQL 里写个 update，就那种：

UPDATE item SET stock = stock - 1 WHERE id = ? AND stock > 0;

然后在 Java 里用Spring Data JPA调一下就可以了，更新不到就说明没库存了嘛。

面试官：那 10 万请求直接打到 MySQL，你觉得 MySQL 顶得住吗？

小Y：呃……那就再加一个Redis 缓存，先查 Redis 的库存，扣完了再扣数据库。Redis 很快的，内存操作嘛。

面试官：你说“扣完再扣数据库”的逻辑能再具体一点吗？比如并发安全怎么保证？

小Y：具体嘛……就是在 Redis 里减一下库存，然后如果减成功我就异步去扣数据库。并发安全的话，我可以用synchronized锁一下……或者用ReentrantLock？

面试官：你打算用 Java 锁住 10 万个分布式请求？

小Y：啊？那我就……上分布式锁！用Redisson啊，或者自己用 setnx。只要有锁就安全了。

面试官：嗯，锁确实是个词。

Round 1 · Q3：使用消息队列削峰填谷（Kafka/RabbitMQ）

面试官：刚才你提到 Kafka。那你具体怎么用消息队列来削峰？

小Y：嗯，就是用户点“立即抢购”时，我不会直接生成订单，我会先把“下单请求”发到Kafka的一个 topic。然后后端有一个消费者服务，慢慢去消费这些消息，按照顺序生成订单，这样就不会把数据库打爆了。

面试官：那如果 Kafka 里积压了很多消息，用户点了秒杀按钮但要等很久才知道抢到了没，这个体验你怎么设计？

小Y：体验嘛……可以做一个轮询接口啊，让用户一直刷新，然后前端定时查询，看订单生成了没。如果没生成，就告诉他“排队中”，生成了就告诉他“抢购成功”。

面试官：嗯，那消息的幂等性怎么保证？重复消费会不会多生成订单？

小Y：幂等是吧……我就给每个请求加个requestId，放到数据库某个字段，插入订单的时候建一个唯一索引，插入失败就表示已经处理过了。或者在 Redis 里记一下处理过的 requestId，这样就……差不多幂等了。

面试官：这个思路还可以，算是个可行方向。

Round 1 · Q4：技术选型：Spring Boot + Spring Cloud 还是 Jakarta EE？

面试官：整体微服务架构你用什么方案？是Spring Boot + Spring Cloud，还是 Jakarta EE，比如用JAX-RS, CDI之类的？

小Y：肯定 Spring Boot 啊，我简历上写了“精通 Spring 全家桶”——Spring Boot、Spring MVC、Spring Cloud、Spring Security、Spring Data……Jakarta EE 太古老了，现在都用 Spring Boot 做微服务，配上Spring Cloud Gateway、OpenFeign、Eureka这些，大厂标配。

面试官：你说 “Jakarta EE 太古老” 这句话，有点危险。那 Spring Boot 和 Jakarta EE 在开发模式上有什么关键差异？

小Y：差异嘛……Spring Boot 就是注解多一点，比如@SpringBootApplication这种，然后自动配置。Jakarta EE 就要自己配 XML，很繁琐。现在大家都讨厌 XML 了，所以都用 Spring Boot。

面试官：呃……你对 Jakarta EE 的了解主要来自哪个年代的资料？

小Y：可能……有点久远……但我主要是 Spring 方向的专家。

面试官：好，Spring 专家我们先记一下。

Round 1 · Q5：数据库与分库分表（MyBatis / JPA / 分布式 ID）

面试官：秒杀订单量大，你数据库怎么设计？用什么 ORM 框架？如果要分库分表，你怎么处理？

小Y：ORM 我一般用MyBatis，可控性强。复杂一点的也可以用Spring Data JPA，它比较自动化。分库分表的话，可以用ShardingSphere或者 MyCat 啊，然后我们可以按用户 ID 或订单 ID 做水平拆分。

面试官：分布式环境下，你订单 ID 怎么生成？用数据库自增 ID 可以吗？

小Y：自增 ID 不太行，会有单点瓶颈。可以用Snowflake 雪花算法，或者 Redis incr，或者用Leaf这样的 ID 生成系统。只要 ID 很长，很随机，就没问题。

面试官：……“很长，很随机” 不是分布式 ID 的核心设计目标。我们后面再补一下。

第二轮：微服务、事务与监控运维

Round 2 · Q1：微服务拆分与 Spring Cloud 技术栈

面试官：我们假设你的电商系统已经拆成微服务了。你大概怎么拆？以及用了哪些 Spring Cloud 组件？

小Y：拆分嘛，一般就这些：用户服务、商品服务、库存服务、订单服务、支付服务、优惠券服务啊。然后我们用 Spring Cloud 做服务治理：

• Eureka做注册中心，
• Spring Cloud Gateway做网关，
• OpenFeign做服务间调用，
• Resilience4j做熔断限流，
• 再加上Config Server做配置中心，
• 日志就Logback + ELK，监控就Prometheus + Grafana + Micrometer。

面试官：名词你是挺全的。那比如订单服务调用库存服务，你怎么保证如果库存扣减失败，订单也要回滚？你是用分布式事务（XA/Seata）还是最终一致性？

小Y：分布式事务……我一般会优先考虑最终一致性。可以用本地事务 + 消息队列，比如库存扣减成功之后发一条消息给订单服务，订单再更新状态；或者反过来。还可以用Seata做全局事务，TCC 之类的，只是我没怎么用过。

面试官：你刚才说“本地事务 + 消息队列”，能详细说一下一个下单流程的消息流转吗？

小Y：详细嘛……比如用户下单：

1. 订单服务先写订单，状态是“待支付”；
2. 然后发送一条消息到库存服务；
3. 库存服务消费消息扣减库存，如果成功就再发一个“库存成功”消息回来；
4. 订单服务收到就把订单状态改成“待发货”。

如果失败嘛……就再发一个“库存失败”消息，订单改成“已取消”。

面试官：那如果其中有一条消息丢了，或者消费失败呢？你怎么保证最终一致性？

小Y：这个……可以设置一下重试机制，然后 Kafka 本身就有持久化嘛，应该不会丢。实在不行，我们可以人工查一下日志……

面试官：“人工查一下” 是你们的核心高可用方案？

小Y：呃……也不是，就是作为一个兜底。

Round 2 · Q2：Spring Security 与 JWT 登录鉴权

面试官：用户登录这块你怎么做？用什么安全框架？

小Y：我肯定用Spring Security啊，它和 Spring Boot 整合很好。我会做一个登录接口，校验用户名密码后生成一个JWT，发给前端。后面所有请求都带上这个 token，后端用 Spring Security 过滤器解析 token，鉴权。

面试官：JWT 里会放哪些信息？如何防止被篡改？你怎么实现退出登录/踢人下线？

小Y：JWT 里会放用户 ID、用户名、角色之类的信息。防篡改的话，我们用一个secret做签名，后端验证签名就行了。退出登录嘛……JWT 一般是无状态的，不太好删，但我们可以在 Redis 里存一个黑名单，或者用短期 token，经常刷新，这样差不多就安全了。

面试官：这个回答可以，算比较实用。

Round 2 · Q3：Redis 缓存架构与热点 Key 问题

面试官：秒杀场景下，Redis 非常核心。你怎么设计缓存？比如如何避免缓存击穿、雪崩？

小Y：缓存击穿就是一个热点 Key 失效后，大量请求都打到数据库；雪崩就是很多 Key 同时失效。我们可以：

• 给热点 Key 设置较长 TTL，甚至不失效；
• 或者在失效前搞个异步预热；
• 加上互斥锁，只有一个线程去回源；
• 过期时间随机化，避免大量 Key 同一时间点失效；
• 再加限流，比如用 Redis + Lua 脚本做令牌桶。

面试官：那如果一个商品特别热门，单个 Key 被 QPS 10 万的访问，你怎么防止 Redis 本身被打挂？

小Y：Redis 也可以做集群啊，Redis Cluster，然后我们可以利用本地缓存，像Caffeine，和 Redis 双层缓存，这样就减轻 Redis 压力。要是再不行，就上多级缓存，甚至 CDN。

面试官：好，这块答得还比较完整。

Round 2 · Q4：日志与监控：Logback, ELK, Prometheus, Grafana, Jaeger

面试官：高并发系统，监控和日志很关键。你会怎么做？

小Y：日志我会用Logback配合SLF4J接口，然后输出到文件，收集到ELK（Elasticsearch + Logstash + Kibana）。监控指标用Micrometer+Prometheus，再用Grafana做可视化。链路追踪可以用Jaeger或Zipkin。这样我们就能看到 QPS、RT、错误率，还有调用链路。

面试官：那如果线上突然订单失败率暴涨，你从监控角度会怎么排查？

小Y：先看 Grafana 的总错误率和延迟，看是不是某个接口的 RT 抖了，再用 Jaeger 看是不是某个下游服务超时，然后去 ELK 搜关键字日志，看看有没有异常堆栈。找到了问题服务，就去重启一下。

面试官：……最后一步“重启一下”是你们的标配操作？

小Y：嗯，这个，在很多公司都挺有效的。

Round 2 · Q5：测试策略：JUnit5, Mockito, Selenium

面试官：你怎么保证这个系统质量？说说测试策略，包括单元测试、集成测试和端到端测试。

小Y：单元测试用JUnit 5，配合Mockito做依赖的 Mock。比如测试服务类的时候，把 Repository mock 掉。集成测试可以用Spring Boot Test，起一个@SpringBootTest，甚至结合Testcontainers启动 MySQL、Redis 容器。UI 层可以用Selenium或者Cucumber做端到端测试。

面试官：你现在项目里单元测试覆盖率大概多少？

小Y：我们比较注重质量，核心模块都写了，覆盖率大概……20% ？

面试官：……你对“注重质量”的理解很独特。

小Y：主要是业务太忙了，没时间写测试。

面试官：嗯，公司出问题时，时间就会腾出来的。

第三轮：AI 智能客服、RAG 与 Agent

第三轮场景切到：电商平台要做一个 AI 智能客服系统，支持订单咨询、物流查询、售后问题等，还要接入公司内部知识库。

Round 3 · Q1：AI 智能客服总体架构（Spring AI + RAG）

面试官：我们想在电商平台上做一个AI 智能客服，既能闲聊，又能回答订单和售后问题，还要用到公司内部文档。你会怎么设计后端架构？

小Y：这个我最近也在关注！可以用Spring Boot+Spring AI，然后调用大模型，比如 OpenAI 的 API 或者 Ollama 本地模型。要用内部文档，就搞一个RAG（检索增强生成）架构：

1. 文档先切片，做Embedding；
2. 存到一个向量数据库，比如 Milvus、Chroma 或 Redis；
3. 用户提问时，用同一个 Embedding 模型把问题向量化；
4. 拿这个向量去做语义检索，找相关文档；
5. 再把文档作为上下文，喂给大模型，让它生成回答。

面试官：说得不错。那你在 Java 里会用什么组件来做这些？

小Y：嗯，Spring AI 里自带一些客户端-服务器调用封装，像调用 OpenAI ChatCompletion 这种，然后我们可以把向量数据库当成一个工具服务，通过REST API调用。整体就是一个Agentic RAG，模型可以调用工具，比如“查询订单状态”、“查物流”、“检索文档”等。

面试官：你刚才提到 Agent。你能解释一下Agent 和普通 ChatCompletion 的区别吗？

小Y：区别嘛……普通 Chat 就是问一答一，Agent 就是更聪明，会自己规划任务、调用各种工具、分步骤解决问题，还能记住用户上下文。就像一个实习生和一个能自己干活的老员工的差别。

面试官：这个类比还挺形象。

Round 3 · Q2：RAG 细节：文档加载、切片与向量化

面试官：RAG 里面，文档加载和切片非常关键。你会怎么处理企业内部文档？比如 PDF、Word、网页、Markdown？

小Y：我会做一个离线的文档加载流水线：

1. 通过一些文档解析库：PDF 就用Apache PDFBox，Word 用POI，网页就用 Jsoup，
2. 把内容抽取出来，统一变成纯文本；
3. 然后按段落或固定字数做chunk切片，比如 500～1000 字一段；
4. 对每个 chunk 调用 Embedding 模型（OpenAI 或者本地模型）做向量化；
5. 把文本、向量、元数据（文档类型、时间、标签）存到向量数据库。

面试官：chunk 大小怎么选？会影响召回效果，你有什么考虑？

小Y：这个嘛……大一点就上下文更完整，小一点就更精准，但其实我也没太试过。感觉 512 字左右……或者 1024 字也行吧，反正差不多。

面试官：……你这个“差不多工程学”要谨慎一点。

小Y：主要是我还没上线过真正的大规模系统，理论上我都懂。

Round 3 · Q3：会话内存、工具调用和防止 AI 幻觉

面试官：AI 客服要具备会话内存，还能调用工具，比如“查订单”、“查物流”，同时要避免严重的AI 幻觉（胡编乱造）。你具体会怎么做？

小Y：会话内存可以有两层：

• 短期记忆：把最近几轮对话存在 Redis 或数据库，按对话 ID 聚合；
• 长期记忆：把一些重要对话摘要，做 Embedding 存到向量库，下次按语义检索。

工具调用的话，我们可以：

1. 把工具描述好，比如“查询订单状态(orderId)”、“查询物流(trackNo)”；
2. 根据工具调用标准化（像 OpenAI 工具调用、MCP 协议那种）让模型决定什么时候调用；
3. 后端收到调用指令，就去调内部微服务（订单、物流的 REST/gRPC），再把结果返回给模型。

防止幻觉的话，可以：

• 通过RAG 约束，只允许模型使用检索到的文档来回答，
• 在提示词中明确要求“不知道就说不知道”，
• 关键业务信息（比如订单金额）直接来自工具调用，不让模型自己编。

面试官：如果模型仍然幻觉，比如查一个不存在的订单，你会怎么处理？

小Y：我会在后端再做一层校验，工具返回“查无此订单”时，在提示里强制让模型复述这个结果，而不是自己编。实在不行，直接把工具输出拼成模板，不让模型发挥创造力。

面试官：“不让模型发挥创造力”，这个安全思路还可以。

Round 3 · Q4：复杂工作流与企业协同场景

面试官：AI 客服不仅回答问题，还要能发起复杂工作流，比如：申请退货退款 -> 走审批 -> 通知仓库拦截 -> 通知财务退款。你会怎么设计这个流程？

小Y：这个就有点像企业协同与 SaaS场景了。我会：

1. 用一个工作流引擎（比如 Camunda、Flowable）建好“退货退款”流程；
2. 每个节点对应一个微服务操作：审批服务、仓库服务、财务服务；
3. AI 只是一个入口，当用户说“我要退货”时，Agent 调用一个“创建退货流程”的工具；
4. 后面的状态变更通过消息队列（Kafka/RabbitMQ）异步通知，AI 客服可以随时查询进度。

面试官：那如果审批人、仓库、财务在不同子公司，权限模型比较复杂，你会怎么在 AI 这层做控制？

小Y：这个嘛……我们可以让 AI 带着用户的JWT或者 session 信息，任何工具调用都要在后端校验权限。AI 只负责生成意图，真正的操作必须通过Spring Security / OAuth2 / Keycloak做鉴权。

面试官：这一点思路还挺清晰。

Round 3 · Q5：从系统到生产：CI/CD 与稳定性

面试官：最后一个问题。这个“秒杀 + AI 客服”系统你要怎么上线和运维？说说你的CI/CD pipeline和一些“稳态运营”的东西。

小Y：CI/CD 我会用：

• GitLab CI 或 GitHub Actions做 pipeline，
• 每次提交自动跑Maven/Gradle 构建 + JUnit5 测试 + 代码扫描；
• 构建成Docker 镜像，推到镜像仓库；
• 用Kubernetes部署，配上 HPA 自动扩缩容；
• 用Jenkins做发布编排也行。

稳定性的话：

• 做金丝雀发布或蓝绿发布，先在小流量上验证；
• 配合Prometheus + Grafana做健康看板；
• 设置告警通知（钉钉/飞书），出现异常自动拉人；
• 关键组件（像 Kafka、Redis、数据库）都要有主从 + 高可用部署。

面试官：听起来你对名词很熟，实践上还需要深挖。好，今天先到这儿。

小Y：哦？那我通过了吗？

面试官：你回去等通知吧，我们会综合评估后给你结果。

小Y：啊，这句话……我好像在哪听过……

面试题详细解析（给学习用）

下面是对上面问题的标准思路+知识点整理，方便小白系统学习。

一、秒杀电商整体架构与关键技术

1. 微服务架构基础

典型拆分：

• 用户服务（User Service）
• 商品服务（Product Service）
• 库存服务（Inventory Service）
• 订单服务（Order Service）
• 支付服务（Payment Service）
• 优惠券/活动服务（Promotion Service）
• 网关服务（API Gateway）

技术栈：

• Spring Boot + Spring MVC/WebFlux：快速构建 REST API
• Spring Cloud：Eureka/Nacos、Gateway、OpenFeign、Config Server、Resilience4j 等
• 部署：Docker + Kubernetes，支持水平扩展

2. 秒杀防超卖与高并发

核心问题：大量并发请求、库存有限、需要强一致的库存扣减。

常见做法：

1. Redis 预减库存 + 异步下单

   • 秒杀开始前，把数据库库存同步到 Redis
   • 请求先在 Redis 做DECR或 Lua 脚本原子扣减
   • 扣减成功才有资格进入后面的下单流程
   • Redis 判断“是否卖完”的逻辑，减少数据库压力

2. 消息队列削峰填谷（Kafka / RabbitMQ / RocketMQ）

   • 接口快速返回“排队中”给前端
   • 把下单请求投递到 MQ，后端消费者异步创建订单
   • 控制订单创建速率，保护数据库

3. 数据库层防超卖

   • 类似 SQL：

     UPDATE item SET stock = stock - 1 WHERE id = ? AND stock > 0;

   • 利用行级锁 + 条件更新，确保不会出现负库存

4. 幂等性保证

   • 为下单请求分配requestId / 业务唯一键
   • 订单表对request_id建唯一索引
   • 消费者重复消费时插入会失败，从而保证幂等

3. 分库分表与分布式 ID

• 订单量大时，单库单表会成为瓶颈，常用按用户 ID / 时间 / 订单 ID进行水平拆分
• 中间件：ShardingSphere、MyCat等
• 分布式 ID 要求：
  • 全局唯一
  • 趋势递增（利于数据库索引）
  • 高可用高性能

常见方案：

• Snowflake（雪花算法）：基于时间戳 + 机器 ID + 序列号
• Segment/Leaf：通过数据库批量号段分配

二、微服务、事务与安全

1. 分布式事务常见方案

1. 强一致：XA/Seata AT 模式

   • 典型“两阶段提交”，对性能、耦合度影响大
   • 常用于对一致性要求极高、业务较简单的场景

2. 柔性事务：最终一致性

   • 思想：允许短时间内不一致，通过补偿/重试达到最终一致
   • 典型实现：
     • 本地事务 + 消息队列
     • TCC（Try-Confirm-Cancel）

示例：下单 + 扣库存

1. 订单服务本地事务：插入订单（待支付）
2. 发送“下单成功”消息
3. 库存服务消费消息，执行本地事务：扣减库存
4. 成功后发送“库存扣减成功”消息
5. 订单服务消费后更新订单状态

要解决的问题：

• 消息可靠投递：事务消息、Outbox pattern
• 消息幂等消费：业务唯一键 + 去重表

2. Spring Security + JWT

关键点：

1. 登录：

   • 校验用户名密码
   • 生成 JWT：包含sub(用户ID)、roles、过期时间(exp)
   • 使用对称加密签名（HMAC）或非对称（RSA）

2. 鉴权：

   • 前端在Authorization: Bearer <token>中携带
   • 自定义 Filter 验证签名、解析出用户信息
   • 将认证信息放入 SecurityContext

3. 退出登录/踢人：

   • 短期 JWT + 刷新 token
   • 或在 Redis 维护黑名单/版本号

3. Redis 缓存问题

• 缓存击穿：热点 Key 过期，大量请求同时穿透到 DB

  • 互斥锁 + 只允许一个请求回源
  • 永不过期 + 异步刷新

• 缓存雪崩：大量 Key 同时过期

  • 为 TTL 加随机值
  • 多级缓存（本地缓存 + Redis）

• 热点 Key 压垮 Redis：

  • 本地缓存（Caffeine）+ Redis
  • 使用 CDN 或边缘节点
  • 热点 Key 分片

4. 日志与监控

• 日志：Logback + SLF4J -> ELK
• 指标：Micrometer -> Prometheus -> Grafana
• 链路追踪：Jaeger / Zipkin（OpenTracing/OpenTelemetry）

排查思路：

1. 指标看整体健康：错误率、RT、QPS
2. 链路追踪定位哪个服务慢/错误
3. 日志查具体异常

三、AI 智能客服系统与 RAG 架构

1. RAG（检索增强生成）核心流程

1. 离线阶段：构建向量库

   • 文档加载：PDF/Word/网页/Markdown -> 纯文本
   • 切片（Chunking）：按段落/固定字数切分
   • 向量化：使用 Embedding 模型（OpenAI、Ollama、本地模型）
   • 存储：向量数据库（Milvus/Chroma/Redis-Search）

2. 在线问答阶段

   • 用户问题向量化
   • 在向量数据库中做语义检索（相似度搜索）
   • 取 Top K 文档片段作为上下文
   • 构造 Prompt（提示词 + 文档 + 问题），调用大模型
   • 模型基于检索到的“事实”生成答案

2. 会话内存与工具调用

• 会话内存：

  • 短期：最近几轮对话，以 JSON/文本形式存储
  • 长期：摘要后做向量化，存入向量库

• 工具调用（Tools / Functions）：

  • 定义工具的输入输出和用途
  • 模型根据上下文决定是否调用工具
  • 后端根据模型返回的工具调用指令执行真实业务逻辑
  • 常见工具：
    • 查询订单状态
    • 查询物流信息
    • 发起退货退款流程
    • 从内部知识库检索文档

3. 防止 AI 幻觉

手段：

1. 提示词约束：“只根据给定文档回答，不要编造。如果不知道就明确说明不知道。”
2. 敏感业务数据一律由工具返回，不允许模型自己编：
   • 金额、订单状态、时间等
3. 在业务层做二次校验：
   • 工具结果与模型输出保持一致
   • 不一致时，可以直接展示工具结果

4. Agent 与复杂工作流

• Agent：具备规划 + 调用工具 + 多轮执行能力的智能体
• 在“退货退款”场景：
  • Agent 解析用户意图 -> 决定调用“创建退货流程”的工具
  • 工作流引擎（Camunda/Flowable）负责执行多节点审批
  • Agent 根据流程状态回答用户“当前进度”

四、工程实践：测试、CI/CD 与稳定性

1. 测试策略

• 单元测试：JUnit5 + Mockito + AssertJ
• 集成测试：Spring Boot Test + Testcontainers
• E2E：Selenium/Cypress/Cucumber（BDD）
• 目标：核心业务模块覆盖率 >= 70%

2. CI/CD 与部署

流水线示例（GitLab CI / GitHub Actions）：

1. 代码提交触发 Pipeline
2. 编译：Maven/Gradle
3. 测试：运行单元测试和集成测试
4. 代码扫描：SonarQube
5. 构建 Docker 镜像并推送到仓库
6. 使用 Helm/Kustomize 部署到 Kubernetes
7. 金丝雀发布，灰度流量验证

3. 稳定性运营

• 多机房/多可用区部署
• 关键基础设施（Kafka、Redis、数据库）高可用集群
• 自动化告警 + 值班机制
• 演练：故障注入（Chaos Engineering）

总结

这篇故事里，小Y 把大部分名词都“听过”，但很多细节一问就含糊了。真正的大厂面试，更看重：

1. 场景化能力：能把技术点放进具体业务，比如秒杀、AI 客服、退货流程；
2. 系统化思维：从架构、存储、缓存、消息、监控、安全、运维全面考虑；
3. 深度细节：不仅知道“Redis 很快”“Kafka 削峰”，还能讲清楚怎么做、为什么安全。

建议你阅读本篇最后的解析部分，对照自己的项目，一项一项地补齐。下次再遇到类似问题，就不会像小Y 那样只会说：“差不多就行了。”