互联网大厂 Java 面试实录Spring Boot Kafka Redis Spring Security Spring AI场景某互联网大厂燕双非来参加 Java 高级工程师面试业务方向是企业协同与 SaaS 大数据与 AI 服务需要同时支撑消息通知、权限控制、缓存、检索与智能问答。第一轮基础架构与服务拆分面试官先聊聊你在 Spring Boot 里怎么做模块拆分如果我们要做一个 SaaS 协同平台你会怎么设计用户、组织、权限、通知这几块燕双非这个我会按领域拆用户中心、组织中心、权限中心、通知中心各自独立成服务。Spring Boot 起服务统一配置、统一日志、统一异常处理接口层用 REST 风格先把边界划清楚。面试官回答得还行至少知道先分边界。那你说说 Maven 在这种多模块项目里怎么管理依赖冲突燕双非嗯……我一般会在父工程里统一版本子模块尽量不自己乱写版本。冲突的话就看依赖树谁不听话就排除谁。面试官可以思路对。那如果通知中心需要高并发发消息Kafka 还是 RabbitMQ你怎么选燕双非如果更偏吞吐量、日志流、事件流我会选 Kafka如果更偏业务路由、确认机制、复杂投递我会考虑 RabbitMQ。SaaS 场景里通知、审计日志、埋点更适合 Kafka。面试官不错至少不是一上来就“我全都要”。那消息发出去后怎么保证用户重复收到时不出错燕双非做幂等嘛业务表里加唯一键或者消费端记消息 ID处理过就直接跳过。实在不行还可以靠 Redis 做去重。第二轮权限、缓存与接口治理面试官现在用户要登录平台既要支持 JWT也要支持 OAuth2 单点登录你怎么设计 Spring Security 的认证链路燕双非登录后签 JWT前端带着 token 访问接口。内部系统如果接企业统一身份源就走 OAuth2 或者对接 Keycloak。Spring Security 里我会把认证、鉴权、异常处理拆开别混在一起。面试官说得比刚才完整了。那权限模型上SaaS 多租户怎么避免“张三看见李四公司数据”燕双非这个要做租户隔离最少得在表里带 tenant_id查询条件统一加。更严格一点可以分库分表或者 schema 隔离。接口层和数据层都要兜底不能只靠前端遮。面试官对前端遮挡只能骗用户骗不了自己。接着说缓存用户资料、组织树、权限菜单经常查Redis 该怎么用燕双非热点数据放 Redis读多写少的比如组织树、权限菜单、会话信息都适合缓存。更新时要么先删后更要么通过消息通知去刷新缓存避免脏数据。面试官如果你的通知列表接口要分页而且首页流量很大Spring Cache 能直接上吗燕双非可以上但要小心缓存粒度。列表页如果参数很多缓存 key 会爆炸所以通常我会缓存用户侧的未读数、最近通知摘要而不是把所有分页结果都塞进去。面试官行至少知道缓存不是“万金油”。那接口文档怎么给前后端联调燕双非用 Swagger/OpenAPI接口参数、返回值、错误码写清楚。复杂一点还会给示例数据少让前端来回猜。第三轮AI 助手、检索与复杂工作流面试官现在业务要求在 SaaS 里加一个 AI 助手能回答“本周待办、合同状态、审批进度”。你怎么做燕双非我会做一个 Agent先让它理解用户问题再调用内部工具查待办、查合同、查审批。核心是把工具调用标准化不然模型只会瞎编。面试官这次回答有点像样了。那如果接入企业文档问答RAG 怎么落地燕双非先文档加载切分成 chunk做向量化再存到向量数据库比如 Milvus 或者 Redis Vector。用户提问时先语义检索再把召回内容拼到提示词里交给大模型生成答案。面试官那怎么减少 AI 幻觉燕双非限制它只能基于检索结果回答没检索到就说不知道再加引用来源、答案置信度、敏感词拦截。复杂任务就拆成多步工作流不让它一把梭。面试官最后一个问题假设 AI 助手还要帮员工创建工单、发通知、查审批你怎么保证这个复杂流程稳定燕双非我会把它做成编排式工作流前面是意图识别中间是工具执行后面是结果校验和回执通知。失败要有重试和补偿关键操作要落审计日志别让模型乱点按钮。面试官嗯今天先到这里。你回去等通知吧。问题详解1. Spring Boot 多模块拆分在企业协同与 SaaS 场景中推荐按领域边界拆分模块或服务例如用户、组织、权限、通知、审计等。这样能降低耦合方便独立扩容和独立迭代。Maven 父子工程通常统一版本和插件避免依赖冲突。若系统规模继续扩大可进一步演进为微服务架构。2. Kafka 与 RabbitMQ 的选择Kafka 更擅长高吞吐、顺序日志、事件流处理适合埋点、审计、异步通知、数据管道。RabbitMQ 更适合复杂路由、灵活投递、业务消息确认。SaaS 通知中心通常事件量大且偏流式因此 Kafka 更常见。3. 幂等与消息重复消费消息系统里重复投递是常态消费者必须具备幂等能力。常见方式包括业务唯一键、消息表去重、Redis 去重、状态机校验等。对于“已处理”的消息消费者应能安全跳过避免重复创建工单、重复发通知。4. Spring Security、JWT、OAuth2 与 KeycloakJWT 适合无状态认证客户端携带 token 访问接口。OAuth2 更适合授权委托和统一登录企业内部常通过 Keycloak 这类身份提供方实现 SSO。Spring Security 负责认证、授权、异常处理与过滤器链编排应将业务鉴权与基础认证分离。5. 多租户权限隔离SaaS 核心是租户隔离。常见方式有共享库共享表但加 tenant_id、独立 schema、独立数据库。简单场景可先使用 tenant_id 并统一在 DAO 层加过滤条件更强隔离需求则采用分库分表。无论哪种方式接口层、服务层、数据层都要一起兜底。6. Redis 与 Spring CacheRedis 适合缓存热点数据如组织树、权限菜单、用户会话、未读消息数等。缓存更新策略常见为先删后更、写穿、延迟双删或通过 MQ 广播刷新。Spring Cache 适合统一缓存抽象但不意味着所有接口都适合缓存分页列表和强一致数据要谨慎。7. Swagger/OpenAPI 的接口治理在多团队协作中OpenAPI 文档能显著降低联调成本。它应该覆盖参数说明、返回结构、错误码、示例值和鉴权方式。对复杂 SaaS 项目建议配合统一响应体、统一异常码和版本管理一起使用。8. AI 助手与 Agent企业 AI 助手的关键不是“会聊天”而是“会调用工具解决问题”。Agent 需要先做意图识别再进行工具调用例如查待办、查审批、建工单、发通知。工具调用最好标准化避免不同系统接口不一致导致链路脆弱。9. RAG 与向量数据库RAG 的核心是“先检索再生成”。文档加载后进行切分、向量化存入向量数据库如 Milvus、Chroma 或 Redis Vector。查询时先做语义检索再把命中的上下文交给模型生成答案。这样可以显著提升企业文档问答的准确率。10. 降低 AI 幻觉幻觉是大模型在缺乏事实依据时仍然输出看似合理内容。应通过检索增强、答案引用、置信度控制、拒答策略、敏感操作二次确认等方式降低风险。对于创建工单、发通知等操作建议增加人机协同与审计记录。11. 复杂工作流与稳定性AI 驱动的业务流程不应直接把所有操作交给模型而应采用编排式工作流意图识别、工具执行、结果校验、失败重试、补偿回滚、通知回执。对关键动作要有审计日志和权限校验避免模型误触发高风险操作。感谢阅读希望这篇互联网大厂 Java 面试实录能帮助大家更好地理解 Spring Boot、Kafka、Redis、Spring Security 以及 AI Agent 与 RAG 在真实业务中的落地思路祝大家面试顺利、稳稳拿 offer