Java 互联网大厂面试实录：Spring Cloud、Kafka、Redis 与 AI RAG 的 9 轮攻防-二趣网

Java 互联网大厂面试实录：Spring Cloud、Kafka、Redis 与 AI RAG 的 9 轮攻防

场景：互联网大厂 Java 求职者面试

人物：严肃面试官 vs 搞笑水货程序员燕双非

第一轮：电商秒杀与订单链路

面试官：我们先从电商秒杀场景开始。一个商品在大促时被几十万人同时抢购，你会怎么设计下单链路？

燕双非：先用 Redis 做库存预扣，前端点一下先排队，后端收到请求后异步发 Kafka 消息，再由订单服务慢慢落库。这样能先把流量拦住，别把数据库冲垮。

面试官：思路是对的。那如果库存预扣成功了，消息却丢了，怎么保证最终一致性？

燕双非：嗯……可以靠重试吧。或者记录一个状态表，定时扫一下没完成的单子，再补发消息。大概就是“丢了我也能捞回来”。

面试官：可以，至少你知道需要补偿机制。那如果订单服务已经创建成功，但支付回调迟到了，如何避免重复扣减库存？

燕双非：给订单加唯一业务号，支付回调做幂等；库存那边也按订单号做去重。重复来就当没看见，主打一个“你来几次都一样”。

第二轮：微服务治理与链路可观测性

面试官：如果这个电商系统拆成了商品、库存、订单、支付四个服务，你会怎么做服务注册、发现和调用？

燕双非：可以用 Spring Cloud 配合 Eureka 做注册发现，服务间调用用 OpenFeign，配合 Resilience4j 做熔断和限流。这样一个服务挂了，不至于全家一起下班。

面试官：不错。那你如何设计超时、重试和熔断的参数，避免把问题放大？

燕双非：超时要短一点，重试别太多，不然一个慢接口会被打成“慢上加慢”。熔断要看错误率和慢调用比例，别一看到波动就直接把门焊死。

面试官：那链路监控呢？如何定位一次下单请求到底慢在哪？

燕双非：用 Micrometer 打指标，Prometheus 拉数据，Grafana 看图。再接 Jaeger 或 Zipkin 做分布式链路追踪，就能看到请求卡在订单、库存还是支付。

面试官：如果日志量很大，你会怎么统一排查？

燕双非：日志用 SLF4J 统一门面，底层 Logback 或 Log4j2 都行，关键字段里带 traceId、userId、orderId。出事的时候直接按 traceId 一把梭。

第三轮：AI 智能客服与企业级演进

面试官：现在很多电商系统都加了智能客服。假设我们要做一个基于企业文档问答的客服机器人，你会怎么接入 AI 能力？

燕双非：可以用 Spring AI 连接大模型，先把售后政策、商品 FAQ、物流规则做文档加载，再切分、向量化，存到 Milvus 或 Redis 这种向量数据库里。用户提问时先做语义检索，再把召回内容拼进提示词，让模型基于知识回答。

面试官：很好。那如果用户问“我的订单为什么一直没发货”，你如何避免模型胡说八道？

燕双非：这个要做 RAG。先查订单系统的真实状态，再让模型结合业务数据回答。不能全靠它自由发挥，不然它一激动，可能直接编一个“快递员在路上睡着了”。

面试官：如果后面要让机器人自动查物流、查退款、查优惠券，还要调用内部系统接口，你会怎么设计？

燕双非：可以做 Agent，配合工具调用标准化。模型负责判断要调用哪个工具，工具负责查订单、查物流、查券。再加聊天会话内存，机器人才能记住用户刚才说过什么，不会一边问“你是谁”，一边给人查订单。

面试官：最后一个问题，如果这个 AI 客服要在高峰期服务百万用户，你会怎么做稳定性保障？

燕双非：限流、降级、缓存、异步化都要上。高频 FAQ 可以缓存，复杂问题走队列异步处理，服务挂了也要有兜底回复。要是模型慢，就先回一句“正在帮您加急处理中”，别让用户盯着转圈圈。

面试官总结

面试官：整体上你对电商高并发、微服务治理和 AI 落地有一定了解，基础思路还可以。不过有些细节还不够扎实，尤其是一致性、容错和 AI 工程化实现部分。这样吧，你先回家等通知。

所有面试问题详细解答

1. 电商秒杀场景下如何设计下单链路？

核心目标是削峰、限流、异步化、最终一致性。常见做法是：

\n
前置限流：Nginx、网关、令牌桶、漏桶。
\n
库存预扣：Redis 原子操作或 Lua 脚本，避免并发超卖。
\n
异步下单：将下单请求转成 Kafka/RabbitMQ 消息，削峰填谷。
\n
数据库落库：订单服务异步消费消息，创建订单并持久化。
\n
幂等控制：订单号、业务流水号、唯一索引、防重复消费。
\n

在真实业务里，下单不是“同步立即成功”，而是“先确保系统不被打爆，再通过补偿保证结果正确”。

\n\n

2. 库存预扣成功但消息丢失，如何保证最终一致性？

这是典型的分布式一致性问题。常见方案：

\n
本地消息表：业务表和消息表同库事务提交，定时重发。
\n
事务消息：如 RocketMQ 的事务消息思想，先执行本地事务，再确认消息。
\n
Outbox 模式：把待发送事件写入 outbox 表，由后台投递。
\n
补偿任务：定时扫描异常状态订单进行恢复。
\

企业官网建设流程全解析