企业官网建设流程全解析

互联网大厂 Java 面试实录：燕双非的三轮挑战

场景：某互联网大厂 Java 面试现场，候选人燕双非，面试官语气严肃但偶尔会引导。本文以真实面试对话风格呈现，最后附详细解析。

第一轮：基础架构与核心链路

面试官：我们先从电商下单链路说起。你们系统是 Spring Boot 启动的，为什么很多团队会优先选它，而不是传统的 Spring MVC + XML 配置？

燕双非：因为……它快，开箱即用，少写配置，能直接跑起来。对电商这种高迭代场景，确实省时间。

面试官：这回答可以，至少抓住了“约定优于配置”。那你说下 Spring Boot 在大厂常见的收益，不只是“启动快”。

燕双非：嗯，还包括统一依赖管理、自动装配、内嵌容器，和监控、日志、配置中心更容易集成。

面试官：还行，能落到工程化。那订单服务接 Kafka 之后，你怎么保证消息不会被重复消费影响库存扣减？

燕双非：这个……可以做幂等，给消息加唯一 ID，数据库里做去重。然后消费失败就重试，应该差不多。

面试官：幂等方向对了，但要说清楚。你再补一句，怎么在业务上落地？

燕双非：比如订单状态流转表里记录消息消费标记，消费前先查状态；或者用 Redis 做短期去重，再配合数据库唯一键。库存扣减要用乐观锁或者原子更新。

面试官：这次讲得像样了。订单中心再往下走，查订单详情接口为什么会配 Redis 缓存？

燕双非：因为详情页访问多，库存和支付状态变化相对没那么频繁，缓存能减轻数据库压力，提高响应速度。

面试官：很好。那缓存一致性你怎么考虑？

燕双非：一般是先更新数据库，再删缓存。对强一致要求高的字段，要缩短缓存 TTL，或者通过消息通知异步失效。

面试官：可以，先到这。

第二轮：微服务、安全与可观测性

面试官：现在我们看支付链路。你们如果用 Spring Cloud 做微服务，支付服务调用用户服务和风控服务，服务间怎么做稳定性保护？

燕双非：这个……可以熔断、限流、重试。比如 Resilience4j 做熔断，失败多了就快速失败。

面试官：可以，继续说。重试能不能随便加？

燕双非：不能吧，像支付扣款这种接口，重试要特别小心，不然会重复扣钱。通常只对读接口或可幂等接口重试。

面试官：回答得不错。那用户登录态我们用 JWT，为什么很多公司还会在 JWT 外面再加一层 Redis 会话控制？

燕双非：因为 JWT 本身签发后不好主动失效。加 Redis 可以做黑名单、踢人下线、续期控制，增强可控性。

面试官：对。那如果是大厂多端登录，你怎么设计 token 刷新？

燕双非：可以短 access token + 长 refresh token，refresh token 放更安全的存储，配合设备维度管理，避免一个端失效影响全部。

面试官：说得还行。监控方面，支付成功率下降了，你第一时间看什么？

燕双非：看 Prometheus 指标和 Grafana 面板，先看 QPS、RT、错误率、下游依赖超时，再结合日志和链路追踪。

面试官：链路追踪你用过什么？

燕双非：Jaeger 或 Zipkin。通过 traceId 把订单、支付、风控、通知整条链路串起来。

面试官：可以。那日志体系里为什么常见 SLF4J + Logback，而不是业务代码直接绑死某个日志实现？

燕双非：为了解耦，统一门面层，底层实现可以替换，还方便接入不同环境的日志方案。

面试官：嗯，基础稳住了。

第三轮：AI 赋能与复杂工作流

面试官：最后看一下增长场景。假设我们做一个电商智能客服，基于 Spring AI + RAG + MCP，你会怎么设计？

燕双非：这个我听过。先把商品知识、售后政策、物流说明做文档加载，再切分、向量化，存到向量数据库里。用户提问后做语义检索，召回相关片段，拼进提示词给大模型回答。

面试官：思路对，继续。那 MCP 在这里解决什么问题？

燕双非：MCP 好像是让模型更标准地调用工具吧，比如查订单、查物流、发起退款这些能力都统一暴露，模型按协议调用，不用每个工具单独适配。

面试官：这次说得很好。那如果客服回答经常“胡说八道”，也就是幻觉，怎么控制？

燕双非：可以限制回答必须基于检索到的文档，不足时就转人工；还要做提示词约束、引用来源、答案置信度校验。

面试官：不错。假如这个客服要接入“订单修改、发票申请、售后退款”复杂工作流，单靠一个大模型行不行？

燕双非：不太行。应该把大模型当调度员，结合工具执行框架和状态机，把步骤拆成可控流程；关键动作要人工确认和审计。

面试官：那如果客服要支持自然语言语义搜索，用户输入“我上周买的那个蓝色耳机在哪”，系统怎么做？

燕双非：先做意图识别和实体抽取，结合向量检索找相似订单、商品和历史会话，再调用业务系统查用户最近订单，最后把结果组织成自然语言回复。

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

问题详解与知识点总结

1. Spring Boot 为什么适合大厂高迭代系统？

Spring Boot 的核心价值不只是“启动快”，而是通过自动装配、统一依赖管理、内嵌容器和外部化配置，把传统 Java Web 项目的样板代码大幅减少。在电商、内容社区、金融等高并发业务中，团队更关注的是交付效率、可维护性和标准化治理。Spring Boot 能自然衔接配置中心、监控、日志、链路追踪和安全体系，因此成为很多微服务项目的基础框架。

2. Kafka 消费幂等如何落地？

Kafka 本身不能直接保证业务幂等，所以需要应用层设计。常见做法包括：消息唯一 ID + 去重表、业务状态表记录消费标记、数据库唯一键约束、Redis 短期去重、消费端事务控制等。对于扣库存、发券、支付确认这类核心链路，必须避免重复消费带来的资金和库存异常。

3. Redis 缓存一致性怎么处理？

常见策略是“先更新数据库，再删除缓存”，因为直接更新缓存容易在并发下产生脏数据。对于读多写少的详情接口，Redis 可以显著减轻数据库压力。但对价格、库存等强一致场景，要谨慎使用缓存，通常结合短 TTL、消息失效和版本号控制，降低不一致窗口。

4. Resilience4j 在微服务里解决什么问题？

它用于熔断、限流、重试、隔离和时间窗口统计，帮助系统在下游故障时避免雪崩。比如支付服务调用风控服务时，如果风控响应变慢，可以通过熔断快速失败，保护主链路稳定。重试只适合幂等接口，否则可能造成重复扣款、重复下单等问题。

5. JWT 为什么常配 Redis 做会话控制？

JWT 的优势是无状态、携带信息、适合跨服务验证，但它一旦签发，在过期前无法天然撤销。Redis 常用于存储黑名单、刷新令牌、踢下线状态、设备列表等，增强 token 的可控性。大厂多端登录常采用短 access token + 长 refresh token 的组合，既保证安全，也兼顾体验。

6. Prometheus、Grafana、Jaeger 如何配合？

Prometheus 负责采集指标，Grafana 负责可视化，Jaeger/Zipkin 负责链路追踪。线上出现支付成功率下降时，通常先看指标面板定位是 QPS 激增、错误率升高还是下游超时，再通过 traceId 追踪具体慢点和异常点，最后结合日志排查根因。

7. 为什么日志门面常用 SLF4J？

SLF4J 作为门面层把业务代码与具体日志实现解耦，底层可以灵活切换 Logback、Log4j2 等实现，方便统一规范、统一格式、统一采集。大厂通常会要求日志中带 traceId、userId、orderId 等关键字段，便于问题快速定位。

8. Spring AI + RAG 的核心流程是什么？

RAG 的典型流程是：文档加载、切分、向量化、存储到向量数据库、语义检索、拼接上下文、调用大模型生成答案。它的优势是能让模型回答基于企业真实知识库，减少幻觉。适合企业文档问答、智能客服、知识库问答等业务。

9. MCP 的价值是什么？

MCP 可以理解为让模型与外部工具之间的调用方式标准化，方便模型统一接入查询订单、查物流、开票、退款等工具能力。它提升了扩展性与互操作性，使得不同工具、不同模型之间的集成成本降低，更适合复杂 Agent 工作流。

10. 如何降低 AI 幻觉？

主要手段有：检索增强、强约束提示词、答案引用来源、置信度评估、低置信度转人工、工具调用优先于自由生成。对于客服和企业问答系统，宁可少答，也不要瞎答，因为幻觉会直接伤害用户信任和业务正确性。

感谢阅读，希望这篇“燕双非面试实录”能帮助大家更轻松地理解 Java 大厂面试中的高频知识点，也希望能对你的求职准备有所帮助。祝大家面试顺利，拿到心仪 offer！