互联网大厂 Java 面试实录：Spring Boot + Kafka + Redis + Spring AI 的电商与 AIGC 场景

互联网大厂 Java 面试实录：Spring Boot + Kafka + Redis + Spring AI 的电商与 AIGC 场景

场景：一家互联网大厂的电商增长与智能客服团队，正在招聘一名 Java 后端工程师。面试官严肃冷静，候选人是外号“燕双非”的水货程序员，平时嘴上很会，真正上手就有点飘。

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

面试官：我们先从电商秒杀说起。下单接口要扛住高并发，你会怎么设计？

燕双非：这个简单，前端先做个按钮防抖，后端再加个 Redis 缓存，应该就差不多了。

面试官：按钮防抖只能减少误点，真正的问题是库存一致性、幂等、限流和削峰。你再说说？

燕双非：嗯……可以先把库存预热到 Redis，然后用 Kafka 做异步下单，用户先收到“排队中”，等消息消费成功再落库。幂等的话，用订单号或者 token 校验一下。

面试官：思路比刚才完整了。那你会怎么避免超卖？

燕双非：可以用 Redis Lua 脚本原子扣减库存，扣成功再发 Kafka 消息。数据库里再加乐观锁兜底。

面试官：可以，至少说明你知道“先快后稳”的设计。

面试官：Spring Boot 项目里，Redis 你会怎么接入？缓存和会话要注意什么？

燕双非：Spring Cache 配 Redis，注解一打就能用。会话的话可以放 Redis，集群里大家都能读。

面试官：不错，但要补充失效策略、序列化方式和缓存穿透。继续。

面试官：如果用 Kafka 做订单事件，你怎么保证消费者不重复处理？

燕双非：保存消息 offset……然后消费完成再提交。业务上再用订单唯一键做幂等。

面试官：这部分回答得还算稳。

第二轮：智能客服与 AI 能力接入

面试官：现在我们把电商扩展成智能客服系统。用户会问“我的订单为什么还没到”，你怎么设计一个基于 Spring AI 的问答链路？

燕双非：直接把用户问题发给大模型，让它自己想。

面试官：这就是典型的“AI 幻觉”风险。你再具体一点。

燕双非：哦，那就先做文档加载，把订单规则、物流说明、售后政策导入向量数据库，比如 Milvus。用户提问后先语义检索，再把检索结果拼进提示词，最后交给大模型生成回答。

面试官：这已经接近 RAG 了。那 Agent 和工具调用在这里怎么用？

燕双非：可以让 AI 先判断是查订单、查物流还是查退款，然后通过标准化工具调用去访问订单服务、物流服务、客服工单系统。这个……有点像智能代理。

面试官：对，这样就不是纯聊天，而是可执行的业务助手。那你怎么控制它乱调用？

燕双非：要做权限校验、工具白名单，还有提示词约束。对敏感信息要脱敏，不能让模型直接看到所有字段。

面试官：很好。那如果在线客服系统要支持多轮对话，你怎么处理上下文？

燕双非：聊天会话内存可以保留最近几轮内容，但不能无限堆，不然 token 太贵。要做摘要压缩，必要时只保留关键状态。

面试官：这就像真正做过产品的人。

面试官：如果知识库里的内容更新了，向量库怎么同步？

燕双非：重新分段、重新 embedding、重建索引。增量更新最好带版本号，不然旧答案会混进来。

面试官：答得不错，说明你知道企业文档问答不是“接个大模型就完事”。

第三轮：稳定性、可观测性与工程落地

面试官：假设这个系统上线后，电商大促期间客服 QPS 暴涨，你怎么做稳定性治理？

燕双非：先限流，再降级，再熔断。Spring Cloud 里可以配 Resilience4j，保护核心链路。

面试官：不错。那链路追踪和监控怎么做？

燕双非：Micrometer 打点，Prometheus 拉指标，Grafana 看大盘。请求链路用 Jaeger 或 Zipkin，方便定位慢接口。

面试官：很好。异常多的时候，怎么快速判断是模型慢、检索慢，还是下游慢？

燕双非：给 RAG 的每一段都打埋点，分开统计召回耗时、Prompt 构造耗时、模型推理耗时，还有工具调用耗时。这样一眼就能看出卡在哪。

面试官：这才是工程化思维。

面试官：最后一个问题：如果要把这套系统做成可持续交付的 Java 服务，你会怎么组织项目？

燕双非：Spring Boot 做主框架，Maven 管依赖，JUnit 5 和 Mockito 做单测，GitHub Actions 或 Jenkins 做 CI/CD，Docker 打包，Kubernetes 部署。日志用 SLF4J + Logback，数据库迁移用 Flyway。

面试官：回答得还可以，至少工程链路是通的。

面试官：今天就先到这里，你回去等通知吧。

面试问题详细解答

1. 秒杀系统如何设计？
核心是“削峰、限流、异步、幂等、最终一致性”。常见做法是：库存预热到 Redis，使用 Lua 脚本做原子扣减，成功后发送 Kafka 消息异步创建订单，数据库层面通过唯一键或乐观锁做兜底。这样能把高并发压力从数据库转移到缓存和消息队列，同时避免超卖。

2. Redis 在电商系统中的价值是什么？
Redis 常用于缓存商品详情、库存、用户会话、验证码、热点榜单等。接入 Spring Boot 时常配合 Spring Cache。需要关注缓存穿透、击穿、雪崩，以及序列化方式、过期策略和热点 key 保护。

3. Kafka 为什么适合订单事件？
Kafka 擅长高吞吐、可扩展的事件流处理，适合订单创建、库存扣减、物流通知等场景。消费端需处理重复消费和消息顺序问题，通常通过业务幂等键、事务消息或去重表保证一致性。

4. Spring AI 在智能客服中的作用是什么？
Spring AI 提供与大模型、向量检索、工具调用等能力的统一接入。企业客服场景通常不会直接让模型“自由发挥”，而是结合 RAG：先检索企业知识，再让模型基于检索结果回答，降低幻觉风险。

5. 什么是 RAG，为什么适合企业文档问答？
RAG 即检索增强生成。先把文档切分、向量化并存入向量数据库，用户提问后做语义检索，找到相关片段再拼接到 Prompt 中。它适合政策、售后、产品说明、SOP 等知识稳定、更新频繁的企业场景。

6. Agent 和工具调用如何落地？
Agent 不是单纯聊天，而是“思考 + 调用工具 + 获取结果 + 再推理”的执行模式。比如客服机器人识别出“查物流”后，调用订单查询、物流查询 API，再生成自然语言回复。关键是工具白名单、权限控制、参数校验和审计日志。

7. 聊天会话内存要注意什么？
多轮对话需要保留上下文，但不能无限增长。通常会保留最近几轮对话，或将历史对话摘要压缩后保存。重点是控制 token 成本、避免上下文污染，并让系统记住关键业务状态。

8. 如何做可观测性？
Micrometer 负责统一指标采集，Prometheus 负责拉取与存储，Grafana 做可视化。Jaeger 或 Zipkin 用于分布式链路追踪。对于 AI 系统，还应对检索耗时、Prompt 构造耗时、模型推理耗时、工具调用耗时分别打点。

9. 如何做稳定性治理？
可以通过限流、降级、熔断、隔离线程池、缓存兜底来保护核心服务。Spring Cloud 生态中常结合 Resilience4j 实现这些能力。大促期间尤其要优先保障核心交易链路，而不是所有功能都全量开放。

10. 一套企业级 Java 服务如何持续交付？
通常使用 Spring Boot 作为基础框架，Maven 管理依赖，JUnit 5 和 Mockito 进行测试，GitHub Actions 或 Jenkins 完成 CI/CD，Docker 负责容器化，Kubernetes 负责部署与弹性伸缩。数据库变更建议用 Flyway 或 Liquibase 管理，保证环境一致性。

感谢阅读，希望这篇文章能帮助大家更好地准备 Java 面试，也希望能对你的业务设计、AI 落地和工程实践有所启发。