Java大厂面试实录Spring Boot Kafka Redis Spring Security RAG 的三轮攻防场景某互联网大厂 Java 岗位面试现场。面试官表情严肃候选人燕双非一脸轻松主打一个“我可能不全会但我会努力胡说八道”。第一轮基础功与电商高并发下单面试官先聊聊你们在电商秒杀场景里Spring Boot 启动后整个订单服务的调用链一般怎么设计燕双非一般就是 Controller 接请求Service 处理业务MyBatis 访问数据库Redis 先做库存预热再用消息队列削峰整体就比较丝滑。面试官回答得还行说明你至少不是把所有逻辑都写在 Controller 里。那如果用 Redis 做库存扣减为什么还要配合 Kafka燕双非因为 Redis 适合快Kafka 适合排队。用户一多的时候直接写库容易扛不住所以先让 Redis 扣一下再把下单消息发到 Kafka后面慢慢异步落库。面试官嗯这个思路对。那如果 Kafka 消息重复消费了你怎么保证订单不会重复创建燕双非这个……可以在数据库加唯一索引吧比如订单号唯一。然后消费端做幂等重复消息就直接忽略。面试官对幂等是关键。那你说说 Spring Boot 里怎么优雅地做接口限流和降级燕双非可以接 Resilience4j或者网关层做限流。比如抢购接口超过阈值直接返回“系统繁忙”别让用户一直转圈省得大家都以为自己网速有问题。第二轮安全、支付与监控告警面试官继续。假设这是一个本地生活支付系统用户下单后要走登录态校验、支付鉴权、风控拦截。Spring Security 你怎么用燕双非Spring Security 负责认证和授权登录后签发 JWT后面每次请求带 token。然后可以配合自定义过滤器做权限校验。面试官不错继续。JWT 放在客户端服务端怎么做失效控制燕双非嗯……JWT 不是天生无状态嘛。可以配合 Redis 存黑名单或者设置短有效期再用刷新 token 机制续期。面试官这就接近实战了。那支付回调通知如果重复到达、顺序还乱你怎么处理燕双非支付回调要按业务流水号做幂等状态机也得控制好。比如已支付状态不能再改回待支付。至于顺序乱应该以最终状态为准别拿一条旧消息把新状态覆盖了。面试官很好。那线上出了“支付成功但订单没更新”的问题你怎么排查燕双非先看日志再看链路追踪Micrometer 指标和 Jaeger/Zipkin 也一起查。可能是 MQ 消费失败、数据库慢、或者事务提交前应用挂了。面试官回答得比较完整。那如果要做告警闭环你会怎么设计燕双非Prometheus 抓指标Grafana 看板展示告警规则触发后通知值班同学如果是链路异常就结合 ELK 和 Trace ID 定位问题。第三轮AIGC、企业知识库与复杂工作流面试官现在公司想做一个企业协同 SaaS 的智能助手员工可以问“报销流程是什么”“合同模板在哪儿”。你会怎么把 Spring AI 和 RAG 结合起来燕双非先把企业文档做加载和切分再向量化存到向量数据库里。用户提问时先做语义检索召回相关文档再把上下文喂给大模型生成答案这就是 RAG。面试官很好。那为什么不能直接让大模型回答燕双非因为大模型会幻觉容易一本正经地瞎说。企业场景不能靠“感觉”得让它基于知识库回答不然员工照着假流程去报销财务会先崩。面试官如果要做复杂工作流比如“识别问题—检索制度—判断权限—调用审批系统—返回结果”你怎么理解 Agent燕双非Agent 就是能自己想一想、会调用工具的智能体。它不只是聊天还能根据任务决定要不要查知识库、要不要调用接口。像审批场景就可以让 Agent 编排多个工具执行。面试官那你知道 MCP 的价值吗燕双非MCP 可以理解成把工具调用标准化让模型接不同系统的时候不用每家都重新写一套适配。这样扩展能力更好也更适合客户端-服务器架构。面试官最后一个问题如果知识库文档特别多检索效果不好怎么办燕双非可以优化切片策略改 embedding 模型做语义检索重排还可以结合业务标签、权限过滤、Agentic RAG。要是还不行那就只能祈祷数据治理先跟上了。面试官总结面试官整体来说你对常见架构和关键技术点有一定理解尤其是电商高并发、支付幂等、监控告警、RAG 和 Agent 这些方向。细节上还需要继续打磨。今天先这样你回家等通知吧。问题详解与知识点总结1. 电商秒杀场景中 Spring Boot、Redis、Kafka 如何协同在高并发秒杀或抢购场景中Spring Boot 通常作为服务入口负责接收请求、参数校验与业务编排。Redis 常用于库存预热和快速扣减避免大量请求直接冲击数据库。Kafka 则用于削峰填谷把下单请求异步化后续由消费者慢慢落库和处理订单状态。这样可以显著提升系统吞吐量并降低数据库压力。关键点包括Redis 做原子库存扣减必要时结合 Lua 脚本保证原子性。Kafka 消息消费端必须做幂等防止重复下单。数据库层建议增加唯一索引和状态机约束形成最后一道防线。2. Kafka 消息重复消费与幂等设计消息队列天然存在至少一次投递语义因此重复消费是常见问题。幂等设计的核心是同一业务请求无论执行多少次结果都应一致。常见方案有业务流水号唯一约束、消费记录表、防重 Token、状态机校验、Redis 去重标记等。在订单系统里最简单有效的是使用订单号或业务单号建立唯一索引并在消费者侧先查询状态再决定是否执行业务逻辑。3. Spring Security JWT 的认证授权思路Spring Security 负责过滤请求、鉴权、权限控制。JWT 用于承载登录态信息服务端签发后客户端携带访问。由于 JWT 本身无状态失效控制通常通过短有效期、刷新令牌、Redis 黑名单等方式补充。适合互联网业务的设计是Access Token 短时有效Refresh Token 负责续期若发生封禁、退出登录、风险拦截则将 token 标记失效。4. 支付回调的幂等与状态机控制支付回调经常面临重复通知、乱序通知、超时重试等问题。正确做法是使用业务单号确保幂等。支付状态只能单向流转例如待支付 → 已支付不能回退。回调处理必须记录原始报文便于审计和排障。如果重复收到成功通知系统应直接返回成功而不是重复更新订单。5. 监控、日志与链路追踪如何协同排障线上问题的排查通常依赖三层能力日志、指标、链路追踪。日志用于查看局部上下文Micrometer Prometheus 提供 QPS、延迟、错误率等指标Grafana 展示可视化看板Jaeger/Zipkin 用于分析分布式调用链ELK 用于集中检索日志。如果出现“支付成功但订单未更新”就要检查 MQ 消费情况、数据库响应时间、事务是否提交、下游接口是否超时以及链路中的 Trace ID 是否完整贯通。6. Spring AI RAG 的企业知识库问答方案RAG检索增强生成的核心目标是让大模型基于企业私有知识回答问题减少幻觉。典型流程文档加载导入制度、FAQ、流程说明、合同模板等资料。切分按语义或结构切成合理片段。向量化使用 Embedding 模型将文本转换为向量。存储写入向量数据库如 Milvus、Chroma 或 Redis 向量能力。检索用户提问时进行语义搜索召回最相关片段。生成将检索结果拼接进提示词交给大模型生成答案。这类方案特别适合企业协同、SaaS、客服、制度问答等场景。7. Agent 与 MCP 的作用Agent 是具备任务分解和工具调用能力的智能体能根据目标自动决定“查知识库、调接口、写表单、发通知”等动作。MCP 则是工具调用标准化的方向让模型接入外部系统时更统一、更易扩展。在复杂工作流中Agent 可以作为编排层MCP 负责标准工具接入从而实现从聊天到执行的闭环。8. Agentic RAG 与传统 RAG 的区别传统 RAG 主要是“问什么搜什么答什么”。Agentic RAG 则进一步引入智能决策模型会判断是否需要多轮检索、是否需要调用外部工具、是否要对检索结果重排或补充查询。适用于复杂问答、跨系统查询、权限校验和多步骤业务流程。9. 检索效果差时的优化方向如果知识库问答效果不好常见优化包括优化切片粒度避免片段太长或太碎。更换或微调 Embedding 模型。增加重排模型提高召回精度。结合元数据、权限、业务标签过滤。使用混合检索关键词检索 语义检索。同时还要重视文档治理否则再强的模型也难以从“乱数据”中答出靠谱答案。10. 为什么企业场景不能直接依赖大模型回答因为大模型会产生幻觉可能输出看似合理但实际上错误的内容。在企业制度、报销、合同、医疗、金融等场景错误回答会直接带来业务风险。因此必须通过知识库、检索、权限控制与审计机制把模型的自由发挥限制在可控范围内。结语感谢阅读希望这篇文章能帮助你在 Java 面试中更好地理解高频技术点与真实业务场景的结合方式也希望能对你的求职准备带来一些启发和帮助。