Spring Boot + Kafka + Redis + Spring AI：互联网大厂 Java 面试实录（企业协同 SaaS 场景）
Spring Boot + Kafka + Redis + Spring AI：互联网大厂 Java 面试实录（企业协同 SaaS 场景）
场景设定：某互联网大厂正在招聘企业协同与 SaaS 方向的 Java 后端工程师。面试官风格严肃，候选人是外号“燕双非”的水货程序员，擅长在简单问题上侃侃而谈，遇到复杂问题就开始顾左右而言他。整场面试围绕“多租户协同平台 + 消息异步化 + AI 助手 + 稳定性治理”展开。
第一轮：基础架构与多租户设计
面试官：你先说说，SaaS 协同平台为什么通常会优先选择 Spring Boot 而不是传统的 Spring MVC + XML 配置？
燕双非：因为 Spring Boot 启动快，自动配置多，少写很多样板代码。对 SaaS 平台来说，快速迭代和统一约束很重要，所以 Boot 更合适。
面试官：不错。那如果系统要支持“按租户隔离配置”，你会怎么做？
燕双非：这个我一般会在请求进来时先解析 tenantId，然后把配置放到 ThreadLocal 里……再配合拦截器或者网关去路由。
面试官：思路基本对。那租户隔离在数据库层通常有哪些模式？
燕双非：嗯……单库单 schema、单库多 schema、以及多库多 schema。一般小公司先单库，后面业务大了再拆。
面试官：很好。那在 Java 17 上你会特别关注什么？
燕双非：我会关注更现代的语法，比如 switch 表达式、record、sealed class。能减少样板代码，DTO 之类的对象会更清爽。
第二轮：消息、缓存与稳定性
面试官：协同平台里有“评论、审批、消息提醒”这些动作，为什么不能都同步调用？
燕双非：如果都同步，接口会很慢，而且一旦通知服务挂了，主流程也会被拖死。所以要拆成异步，用户操作先成功，后续靠消息队列慢慢处理。
面试官：那你会选 Kafka 还是 RabbitMQ？
燕双非：看场景。像这种事件流、埋点、通知广播，Kafka 更适合；如果是比较强路由、复杂工作队列，RabbitMQ 也挺方便。
面试官：很好。那异步之后如何保证消息不丢、不重复？
燕双非：这个……一般就是幂等嘛。消费者根据业务唯一键做去重，数据库加唯一索引，或者 Redis 记处理状态。消息不丢的话，生产端和消费端都得配合确认机制。
面试官：那缓存你会怎么设计？
燕双非：热点数据，比如租户配置、权限菜单、会话信息，可以放 Redis；本地热点可以用 Caffeine 做一级缓存。要注意缓存一致性，更新时先写库再删缓存，或者通过消息通知失效。
面试官：如果 Redis 突然抖动，你怎么避免大面积雪崩？
燕双非：可以加随机过期时间，做热点预热，必要时降级到本地缓存或者直接返回兜底数据。还有限流和熔断也要配合。
面试官：说到熔断，你会怎么理解 Resilience4j？
燕双非：它就是做限流、熔断、重试、隔离这些治理能力的。适合微服务里保护下游，防止一个服务挂了把整条链路拖垮。
第三轮：AI 助手与可观测性
面试官：现在很多 SaaS 都接了 AI 助手。你如果要做“企业知识问答”，会怎么结合 Spring AI、RAG 和向量数据库？
燕双非：先把企业文档做切分、清洗、向量化，存到 Milvus 或 Redis 这类向量库。用户提问时先做语义检索，召回相关片段，再把上下文交给大模型生成回答，这就是 RAG。
面试官：那你怎么控制 AI 幻觉？
燕双非：嗯……尽量让模型“有据可依”，只让它基于检索到的知识回答；再加引用来源、置信度阈值、拒答策略。如果检索不到，就明确告诉用户“暂未找到相关内容”。
面试官：很好。那如果要让 AI 代理帮用户自动发起审批、创建工单，你会关注什么？
燕双非：会关注工具调用标准化、权限校验、审计日志，还有上下文记忆。不能让 agent 随便乱调用工具，得有明确边界和授权。
面试官：最后一个问题，系统上线后你如何观测慢请求和链路瓶颈？
燕双非：用 Micrometer 接 Prometheus，Grafana 做看板；链路追踪可以用 Jaeger 或 Zipkin。再结合日志里的 traceId，能快速定位是数据库慢、接口慢还是下游超时。
面试官：不错，今天先到这儿吧。你回去等通知。
面试题详细解答
1. 为什么 SaaS 平台常用 Spring Boot
Spring Boot 的核心价值是约定优于配置。对于企业协同 SaaS 平台，项目通常包含登录鉴权、多租户、消息通知、审批流、AI 助手等模块，Boot 能快速统一技术栈，减少 XML 和繁琐装配，让团队更快交付。
2. 多租户隔离怎么设计
常见模式有：
- 单库单 schema：实现简单，但隔离弱，适合早期。
- 单库多 schema：逻辑隔离较好，运维复杂度适中。
- 多库多 schema：隔离最强，适合大客户或高安全场景，但成本最高。
实际设计时，需要结合租户规模、数据安全要求、查询模式与运维能力综合取舍。请求进来后，通常通过网关、拦截器或 Filter 解析 tenantId，并贯穿到数据库路由、缓存 key、消息主题和审计日志中。
3. Java 17 对业务开发的价值
Java 17 带来的 record、sealed class、switch 表达式等特性，特别适合 DTO、事件对象、结果封装等场景。比如审批事件、消息 payload、AI 召回结果，都可以用更轻量的方式表达，减少模板代码，提高可读性。
4. 为什么异步化适合评论、审批、通知
这类操作往往不是主链路核心结果，用户最关心的是“操作成功”，而不是“短信是否即时发送”。通过 Kafka 或 RabbitMQ 异步处理，可以把耗时操作下沉，提升响应速度，并在高并发场景下缓冲流量峰值。
设计时要注意：
- 消息幂等：同一业务事件可能重复投递。
- 消息可靠性：生产确认、消费确认、重试、死信队列。
- 最终一致性：主事务成功后，再靠消息补偿下游。
5. Kafka 与 RabbitMQ 的选择
Kafka 更偏向高吞吐、事件流、日志收集、埋点和广播型场景；RabbitMQ 更适合复杂路由、延迟处理和传统任务队列。企业协同平台的消息通知、行为事件、审计事件，多数更适合 Kafka。
6. 缓存设计与一致性
Redis 适合作为分布式缓存，用于租户配置、用户权限、热点会话等共享数据；Caffeine 适合作为本地缓存，降低 Redis 压力。缓存更新策略常见有“先写库再删缓存”，并配合消息通知、多级缓存和随机过期时间来避免缓存击穿、穿透和雪崩。
7. Resilience4j 的作用
在微服务调用链中，下游服务可能超时或异常。Resilience4j 提供熔断、限流、重试、隔离等能力，帮助系统在部分依赖异常时保持可用，避免故障扩散。对企业协同平台来说，审批、通知、文件服务等都可能成为受保护的对象。
8. Spring AI + RAG 怎么做企业知识问答
RAG 的基本流程是：
- 文档加载：从制度、FAQ、SOP、合同等资料中抽取文本。
- 切分与向量化：将文档分段并转换成 embedding。
- 向量检索：用户提问后，先检索最相关片段。
- 提示填充：把检索结果拼进 prompt。
- 大模型生成：基于证据输出答案。
Spring AI 可以作为统一编排层，把向量检索、模型调用、工具调用串起来，适合搭建企业知识助手和智能客服系统。
9. 如何控制 AI 幻觉
AI 幻觉指模型生成了看似合理但实际错误的内容。控制方式包括：
- 只允许基于检索上下文回答。
- 设置引用来源，增强可解释性。
- 检索不到就拒答，而不是强答。
- 关键业务加规则校验和人工审核。
- 对敏感操作引入权限与审计。
在企业场景中，AI 的价值不是“会说”，而是“说得对、可追溯、可控制”。
10. Agent 工具调用要注意什么
Agent 能自动调用工具完成任务，但在企业系统里必须有边界控制。工具调用需要标准化接口、权限验证、审计日志、参数校验和失败回滚策略。尤其涉及审批、财务、客户数据时，必须限制 agent 仅能在授权范围内操作。
11. 可观测性如何做
使用 Micrometer 暴露指标，Prometheus 采集，Grafana 展示；链路追踪用 Jaeger 或 Zipkin；日志中统一注入 traceId 和 tenantId。这样可以把慢请求定位到具体接口、具体 SQL、具体下游依赖，快速判断问题出在缓存、数据库还是网络。
结语
本文围绕企业协同 SaaS 的面试场景，串联了 Spring Boot、Kafka、Redis、Resilience4j、Spring AI、RAG 和可观测性等核心知识点。希望这篇文章能帮助你在面试和实战中更从容地理解技术选型与系统设计。感谢阅读，祝大家都能在面试中稳稳拿下心仪 offer！