企业官网建设流程全解析

Java 大厂面试实录：Spring Boot + Kafka + Redis + Spring AI + Kubernetes 的 12 道高频追问

场景：一家互联网大厂的 Java 社招面试现场，业务方向是电商秒杀 + 智能客服。面试官严肃专业，候选人是外号“水货程序员燕双非”的求职者。

规则：三轮递进式提问，每轮 3-5 个问题，问题从业务到技术逐步深入。燕双非对简单题能勉强答上来，答得好时面试官会顺势夸赞并继续追问；遇到复杂题则开始含糊其辞、语焉不详。

第一轮：系统设计与基础链路

面试官：我们先聊一个电商秒杀场景。假设大促时商品详情页 QPS 很高，你会怎么设计 Java 服务的整体架构？

燕双非：我会先把服务拆开，商品服务、订单服务、库存服务分开。用 Spring Boot 起服务，前面再加个网关，缓存放 Redis，数据库扛不住的地方尽量别直接打库。

面试官：思路还行，至少知道“别让数据库硬扛”。那商品详情页里哪些数据适合缓存，哪些不适合？

燕双非：商品基础信息、价格、活动配置这些可以缓存；库存这种变化特别快的要谨慎，或者加比较短的过期时间，另外要防止缓存击穿、穿透……

面试官：不错，能说到击穿和穿透，说明不是完全靠背。那如果 Redis 挂了，你准备怎么兜底？

燕双非：嗯……可以本地再加一层缓存，或者直接降级成返回默认值。再不行就让用户稍等，系统提示“当前访问人数较多”。

面试官：至少知道要有降级意识。最后一个基础问题，Spring Boot 里你通常怎么管理配置，线上和本地怎么区分？

燕双非：我一般用 application.yml，再配 spring profiles。比如 dev、test、prod 分开，敏感配置放到配置中心或者环境变量里。

第二轮：消息削峰与一致性

面试官：好，进入秒杀下单流程。用户点击抢购后，你会怎么避免库存被打爆？

燕双非：我会先做接口限流，然后请求进来后写 Kafka，异步处理下单。前台先返回“已受理”，后面慢慢落库。

面试官：用了 Kafka，说明你知道削峰。那如果消息重复消费了怎么办？

燕双非：额，这个要做幂等。比如订单号唯一，数据库加唯一索引，或者消费前先查 Redis 里有没有处理过。

面试官：可以。那你觉得“先写 Kafka 再扣库存”和“先扣库存再写 Kafka”哪个更合理？

燕双非：我觉得……都行吧，主要看业务。一般就是先把关键数据保存好，然后让异步系统慢慢处理。

面试官：“都行吧”在大厂面试里通常不太行。你要是做订单系统，怎么保证库存、订单、支付状态之间的一致性？

燕双非：嗯，可以用事务……但跨服务就比较麻烦。可能要用最终一致性，比如订单创建成功后发消息，库存服务和支付服务各自消费，失败就重试，实在不行走补偿。

面试官：这就开始像个工程师了。那重试和补偿怎么设计，避免“雪崩式补偿”？

燕双非：这个……可以给消息加重试次数和死信队列，补偿任务定时扫表。再配合监控看失败率，人工介入。

面试官：行，至少知道要留后手。再问你一个 MyBatis 的问题：你在高并发场景下会怎么优化数据库访问？

燕双非：减少 SQL 次数，避免 N+1，分页要走合理索引，连接池用 HikariCP，慢 SQL 通过日志和监控定位。

面试官：不错，回答已经比开头像样了。

第三轮：智能客服与云原生演进

面试官：现在公司想做一个智能客服系统，用户会问“我的订单为什么还没发货”。你会如何引入 Spring AI 和 RAG？

燕双非：我会先把订单、物流、售后文档做向量化，存到向量数据库里。用户提问时先做语义检索，找到相关文档，再把检索结果喂给大模型生成答案。

面试官：很好，已经接近正确答案了。那为什么不能只靠大模型直接回答？

燕双非：因为它可能会幻觉，瞎编。尤其是订单状态这种强业务场景，必须结合企业文档和实时数据，不然容易把用户带沟里。

面试官：对。那如果客服问题需要调用“查订单”“查物流”“改地址”这类工具，你会怎么做工具调用标准化？

燕双非：可以把这些能力包装成工具，让 Agent 根据意图决定调用哪个服务。工具入参、返回值尽量统一，避免每个接口都写一套特殊适配。

面试官：说得还行。最后问一个云原生问题：这套客服和订单服务都要部署到 Kubernetes，你如何做健康检查、监控和灰度发布？

燕双非：健康检查用 readiness 和 liveness，监控用 Micrometer 接 Prometheus，再在 Grafana 看图。灰度的话可以分批发布，或者按流量比例切一小部分到新版本。

面试官：嗯，云原生这块你至少不是完全空白。那如果我再追问一句：线上某个智能问答接口延迟突然升高，你怎么排查？

燕双非：先看监控指标，再看日志和链路追踪，可能是向量检索慢、模型接口慢，或者某个下游服务超时。然后按调用链一步一步缩小范围。

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

面试题详细解答

1. 电商高并发场景的整体架构怎么设计？

典型思路是按业务拆分服务：商品、库存、订单、支付、营销等。Java 技术栈上常见组合是 Spring Boot + Spring MVC / WebFlux、Redis、MyBatis / JPA、Kafka、Kubernetes。核心原则是把“读多写少”的数据提前缓存，把“必须强一致”的写操作收敛到少数关键链路，并通过限流、降级、熔断、异步化来保护系统。

在秒杀场景里，最怕的是请求直接打到数据库。正确做法通常是：前置网关限流、页面静态化或局部静态化、热点数据缓存、库存预扣、消息队列削峰、异步落库。

2. 哪些数据适合缓存，哪些不适合？

适合缓存的通常是：商品详情、活动规则、配置类数据、用户画像摘要、常见查询结果。
不太适合直接缓存的通常是：变化极快且要求绝对实时的数据，比如秒杀库存最终值、支付状态、风控强校验结果等。

缓存设计要重点考虑：

• 缓存穿透：查不存在的数据，需用布隆过滤器或空值缓存。
• 缓存击穿：热点 key 失效瞬间大量请求穿透到数据库，需用互斥锁、逻辑过期等方案。
• 缓存雪崩：大量 key 同时过期，需设置随机过期时间和多级缓存。

3. Redis 挂了怎么兜底？

可采用本地缓存、降级页面、静态兜底数据、读数据库限流等方式。关键是要先定义“系统降级后还能提供什么最小可用能力”，例如商品页只展示基础信息，库存不显示实时数值，避免全站不可用。

4. Kafka 在秒杀链路中的作用是什么？

Kafka 的作用是削峰填谷、异步解耦、提升吞吐。用户请求进入后，可以先快速校验资格，再把下单请求写入 Kafka，由后端消费者异步完成库存扣减、订单创建、支付预创建等操作。

这样做的好处是前端响应快，系统整体更平滑；坏处是引入了最终一致性，需要处理重复消费、消息丢失、顺序问题、幂等问题。

5. 如何保证消息重复消费也不会出错？

常见做法包括：

• 业务幂等键：如订单号、请求号、支付流水号。
• 数据库唯一索引：用唯一约束拦截重复写入。
• 消费日志表：记录消息是否处理过。
• Redis 去重标记：适合短期幂等防护。

在支付、库存这类关键链路里，通常会组合使用幂等键 + 数据库约束 + 失败重试。

6. 如何设计库存、订单、支付的一致性？

跨服务一致性一般不用分布式强事务，而是走最终一致性。常见模式有：

• 本地事务 + 消息可靠投递。
• 事务消息 / Outbox 模式。
• Saga 补偿模式。

例如订单创建成功后发出“库存预扣”消息，库存服务消费后扣减成功，再回写状态。若库存扣减失败，则通过补偿任务释放订单或恢复库存。系统必须具备重试、补偿、对账、告警能力。

7. MyBatis 在高并发场景如何优化？

重点是减少数据库访问次数和锁冲突：

• 合理建索引，避免全表扫描。
• 避免 N+1 查询。
• 控制单次返回数据量，分页合理。
• 批量写入，减少频繁往返。
• 连接池使用 HikariCP 提升连接获取效率。
• 通过慢 SQL 日志、APM 和数据库监控定位瓶颈。

8. 为什么不能只让大模型直接回答订单问题？

因为大模型可能出现 AI 幻觉，生成看似合理但实际上错误的答案。像“订单是否发货”“退款到哪一步”这种问题，必须结合企业实时数据、业务文档和流程状态。RAG的价值就在于：先检索可信知识，再让模型生成答案，从而显著降低幻觉概率。

9. Spring AI + RAG 在智能客服里怎么落地？

典型链路是：

1. 文档加载：导入 FAQ、业务手册、工单知识库、订单规则。
2. 切分与向量化：把文本切成适合检索的片段，生成 embedding。
3. 向量存储：写入 Milvus、Chroma 或 Redis 向量能力。
4. 语义检索：用户提问后找出最相关片段。
5. 提示填充：将检索结果与问题一起拼到 Prompt 中。
6. 大模型生成：输出答案，必要时附带引用来源。

如果再结合实时接口查询订单、物流，就可以做成 Agentic RAG：检索知识 + 工具调用 + 结果汇总。

10. 什么是工具调用标准化？

当 Agent 要调用“查订单”“查物流”“退货申请”时，最好把每个能力都封装成统一格式的工具接口：明确工具名、入参 schema、返回 schema、错误码和超时策略。这样模型更容易选择工具，系统也更容易治理。

这类架构常见于企业文档问答、智能客服、复杂工作流编排。工具执行框架可以把外部系统能力变成模型可理解、可调用、可追踪的动作。

11. Kubernetes 上如何做健康检查、监控和灰度发布？

健康检查一般分为：

• liveness：进程是否还活着。
• readiness：是否准备好接流量。

监控层面可以使用 Micrometer 暴露指标，Prometheus 采集，Grafana 展示。日志系统可配合 ELK Stack，链路追踪则可用 Jaeger 或 Zipkin。灰度发布通常通过分批滚动、流量染色、服务网格或网关路由实现。

12. 线上延迟升高怎么排查？

排查思路是从“现象”到“链路”再到“单点”：

• 看监控：QPS、RT、错误率、GC、CPU、内存、线程池。
• 看日志：是否有超时、重试、序列化异常。
• 看链路追踪：慢在模型接口、向量检索、数据库，还是消息消费。
• 看依赖：Redis、Kafka、数据库、外部模型服务是否抖动。

真正的大厂排障不是“我觉得是数据库”，而是用指标和链路一步步证据化定位。

总结

这场面试从电商秒杀、消息削峰、一致性设计，逐步深入到智能客服、RAG、Agent、Kubernetes 监控与灰度发布。对于 Java 求职者来说，真正重要的不只是会背概念，而是能把技术和业务场景连接起来，讲清楚为什么这么设计、如何落地、出了问题怎么兜底。

如果你正在准备大厂 Java 面试，希望这篇实录能帮助你梳理思路、查漏补缺、提升表达。感谢阅读，真心希望它能帮助到你。