企业官网建设流程全解析

Java 面试实战：Spring Boot + Kafka + Redis + Elasticsearch + RAG 的大厂求职问答（燕双非翻车现场）

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

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

第一轮：基础与工程能力

面试官：先说说 Spring Boot 的自动配置是怎么实现的？你们项目里一般怎么排查一个 Bean 为什么没生效？

燕双非：自动配置我理解就是 Spring Boot 帮我们把很多配置都默认装好了。Bean 没生效的话，我一般先看是不是没加注解，或者包扫描不到。再不行就把配置类打印一下，看看有没有被加载。

面试官：思路方向对，说明你至少知道排查入口。那你继续说一下，Maven 多模块项目里，怎么管理公共依赖和版本冲突？

燕双非：嗯……我一般用父子 POM，公共依赖放父工程里统一管。冲突的话，可能就 exclude 一下，或者看哪个依赖先引进来的。

面试官：不错，至少知道 parent POM 和依赖排除。那如果我们做一个内容社区，用户发帖后要异步生成推荐摘要，你会优先怎么设计？

燕双非：我会先把发帖接口和摘要生成解耦，发帖成功后丢一条消息到 Kafka，让后面的消费者去处理摘要，避免主流程卡住。

面试官：这个方向很好，已经有事件驱动的意识了。那你说说 Kafka 里怎么保证消息不丢？

燕双非：额……生产者发消息要确认，消费者处理完再提交 offset，最好再配点重试和补偿。

第二轮：业务扩展与中间件协同

面试官：假设这是一个内容社区加 AIGC 的场景，帖子发布后要做：敏感词审核、向量化、语义检索入库、推荐摘要生成。你会怎么串起来？

燕双非：我会先在接口层做基础校验，然后发 MQ。审核、向量化、摘要生成都可以拆成独立消费者。审核通过后再进入后续流程，向量化结果存 Milvus 或 Redis 向量结构，检索服务根据 embedding 做召回。

面试官：你说到了向量化和语义检索，这说明你不是完全没做过功课。那如果审核和向量化都要用到同一份内容，怎么避免重复读取数据库？

燕双非：可以把帖子内容作为消息体带过去，或者把原文先存对象存储，再让下游按 ID 拉取。要是内容很大，就别全塞 MQ 里，不然消息会太胖。

面试官：可以，说明你知道消息体设计的边界。那再说说 Redis 在这个系统里除了缓存还能做什么？

燕双非：除了缓存帖子列表、用户会话、热点榜单，Redis 还可以做分布式锁、限流、消息队列的轻量发布订阅。比如热门帖子点赞数可以先走 Redis 计数，再异步落库。

面试官：很好，已经开始往业务流量设计上靠了。那如果点赞数、阅读数这些最终要对账，你怎么避免 Redis 和 MySQL 不一致？

燕双非：我会做延迟双删或者定时对账，核心是让 Redis 负责高并发写入，MySQL 负责最终持久化，允许短时间不一致。

面试官：这就是一个比较靠谱的方向。最后一个问题，Spring Security + JWT 放在这个系统里，你会怎么做登录态和接口鉴权？

燕双非：登录成功后签发 JWT，前端带着 token 调接口，后端过滤器里解析 token 和权限信息。社区里像发帖、评论、审核这些接口，就按角色和权限做拦截。

第三轮：性能、观测与架构落地

面试官：如果这个系统日活很高，帖子详情页 QPS 很大，你会怎么做性能优化？先从 Java 侧说。

燕双非：我会先看 JVM 和线程池配置，避免线程打满；再看对象创建是不是太多，能不能用缓存和复用。数据库层面也会加索引，接口上做分页和局部加载。

面试官：还算比较全面。那你如何用 Micrometer + Prometheus + Grafana 监控帖子发布链路的耗时和错误率？

燕双非：在接口和消费链路里打埋点，记录请求计数、耗时分布、异常数，然后 Prometheus 拉指标，Grafana 出图。这样可以看到哪个环节慢，哪个环节出错多。

面试官：很好。那如果某个 AIGC 摘要服务偶尔返回幻觉内容，用户投诉了，你会怎么定位和治理？

燕双非：先把输入、prompt、模型版本、检索结果、输出结果全链路记录下来，看看是不是检索没召回到正确文档，或者 prompt 约束不够。必要时加人工审核和兜底模板，减少胡说八道。

面试官：思路可以，说明你至少知道 AI 幻觉不是“模型喝多了”。那如果我们把这个系统拆成 Spring Cloud 微服务，服务之间调用失败怎么办？

燕双非：可以用 OpenFeign 调用，再配 Resilience4j 做超时、重试、熔断、降级。比如推荐服务挂了，帖子详情页先返回基础信息，不影响主流程。

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

问题详解：结合内容社区 + AIGC 场景的深入解析

1. Spring Boot 自动配置如何工作？

Spring Boot 的自动配置本质上是基于条件装配机制，将常见 Bean、配置项按约定自动注入到容器中。在内容社区系统里，例如 RedisTemplate、KafkaTemplate、Jackson ObjectMapper、Spring Security 过滤链，都可能通过自动配置快速接入。排查 Bean 不生效时，一般从以下方向入手：是否被组件扫描到、是否命中条件注解、是否被其他配置覆盖、是否在排除列表中。

2. Maven 多模块如何管理依赖与版本？

大厂项目通常采用 parent POM + dependencyManagement 统一管理版本。公共依赖如 Spring Boot、Jackson、Kafka 客户端、测试框架版本都在父工程控制，子模块只声明坐标不写版本，避免漂移。遇到冲突时，通过依赖树定位冲突来源，再用 exclude、强制版本、拆分公共 BOM 的方式治理。

3. Kafka 在异步业务中的作用与消息不丢设计

社区发帖后异步生成摘要、审核、向量化，最适合用 Kafka 解耦。生产端可通过 acks=all、幂等生产者、重试机制提升可靠性；消费端通过手动提交 offset、业务幂等、失败重试、死信队列、补偿任务保证最终一致性。对于高价值任务，如审核和索引入库，还应考虑消息顺序、重复消费和事务边界。

4. AIGC 流程如何设计：审核、向量化、语义检索、摘要生成

推荐做法是把业务拆成事件流：帖子创建后先进入审核服务，通过后再触发摘要生成、Embedding 计算和向量库写入。若需要检索，可将帖子内容、标题、标签进行向量化，存入 Milvus、Chroma 或 Redis 向量能力中，后续通过语义检索召回相关内容。业务上一定要保留原文、版本号和处理状态，方便回溯。

5. Redis 除缓存外还能承担哪些职责？

Redis 在高并发内容平台中通常承担热点缓存、会话存储、排行榜、分布式锁、限流、消息广播等职责。点赞数、收藏数、阅读数等适合先写 Redis，再异步刷 MySQL，以降低主库压力。为了保证数据一致性，可采用定时对账、消息补偿、延迟双删等策略。对于实时榜单，可使用 ZSet 做热度排序。

6. Spring Security + JWT 的登录态与权限控制

JWT 适合无状态登录，用户登录后签发 token，后续请求携带 token 访问资源。服务端可在过滤器中解析 token、获取用户身份和角色权限，并结合方法级鉴权控制发帖、评论、审核等接口。注意 JWT 的撤销问题，通常配合黑名单、短有效期、刷新令牌或统一认证中心解决。

7. 高并发场景下的 Java 性能优化

高 QPS 的帖子详情页常见问题包括数据库压力、对象分配过多、线程池阻塞、序列化开销大。优化手段包括：JVM 参数调优、减少临时对象、使用缓存、接口分页、数据库索引优化、减少大字段返回、异步化非核心逻辑。若引入 WebFlux 适合 I/O 密集场景，但要评估链路是否真正收益。

8. Micrometer + Prometheus + Grafana 如何监控链路

Micrometer 负责统一指标采集，Prometheus 负责抓取和存储指标，Grafana 负责展示。可在发帖接口、Kafka 消费器、向量化服务、摘要服务中埋点请求量、耗时、错误率、重试次数等。这样一旦用户反馈“发帖后摘要慢”，就能快速定位是审核慢、MQ 堆积，还是 AI 模型响应慢。

9. AI 幻觉如何治理？

AI 幻觉本质上是模型生成了看似合理但不符合事实的内容。在内容社区里，摘要、评论辅助生成、问答机器人都可能产生幻觉。治理方式包括：增强检索上下文、限制 prompt 输出范围、对关键输出做事实校验、引入人工审核、对低置信结果走模板兜底。对于企业场景，推荐采用 RAG，把“检索到的可信资料”作为生成依据。

10. Spring Cloud + OpenFeign + Resilience4j 的微服务协同

当内容、审核、搜索、推荐、AI 服务拆分后，服务间调用不可避免会失败。OpenFeign 负责声明式调用，Resilience4j 负责熔断、限流、重试、隔离和降级。比如推荐服务超时，帖子详情页仍可展示基础内容；搜索服务异常时，退化为按数据库或缓存查询。大厂面试中，候选人若能讲清“失败如何优雅退化”，通常会加分。

感谢阅读，希望这篇文章能帮助你在 Java 面试中把基础、业务和架构思路串起来，真正做到既能回答问题，也能讲清落地方案。