互联网大厂 Java 面试实录Spring Boot、Kafka、Redis、Spring Security、AI RAG 与 Kubernetes 云原生场景场景某互联网大厂招聘“Java 高级工程师”业务方向覆盖本地生活服务 大数据与 AI 服务。面试现场严肃的面试官和自称“水货程序员”的燕双非围绕真实业务展开三轮追问。第一轮本地生活服务的下单链路与基础能力面试官我们做本地生活团购用户从 App 下单到商家接单后端用 Spring Boot MyBatis MySQL。先说说你怎么设计这个下单接口如何保证幂等燕双非这个简单先查一下订单有没有创建过如果创建过就直接返回成功没有就插入一条记录。可以加一个唯一索引比如用户 ID 业务单号防止重复下单。再配合 Redis 做一下请求去重应该就稳了。面试官思路是对的能把业务幂等和数据库约束结合起来说明你不是只会背概念。面试官那你说说 Spring Boot 在这个项目里为什么比传统 Spring MVC 更合适燕双非因为 Spring Boot 开箱即用少配置内嵌 Tomcat启动快。像数据库连接池、JSON 序列化、日志这些都能用 starter 快速集成适合快速迭代的互联网项目。面试官嗯能结合交付效率说说明你做过业务。面试官订单创建后要发消息给商家系统你会用 Kafka 还是 RabbitMQ为什么燕双非如果是高吞吐、可扩展的订单事件流我会偏向 Kafka。它适合日志和事件流处理能扛比较大的并发如果是需要更灵活的路由和复杂 ack 语义RabbitMQ 也可以。不过我们这种下单事件Kafka 更常见。面试官回答得还行至少知道不同 MQ 的定位。面试官如果 Kafka 消息重复消费了你怎么处理燕双非这个……可以在消费端做幂等比如用订单 ID 做去重表或者 Redis setnx 记录处理状态。实在不行再查业务状态反正核心就是别重复扣库存、别重复发券。面试官说得有点糙但方向没错先记账式去重再做业务状态校验。第二轮缓存、权限、支付与风控面试官订单后续会查详情、查状态、查优惠券。这里你怎么用 Redis 和 Caffeine 做多级缓存燕双非Caffeine 放本地热点数据访问快Redis 做分布式缓存多个实例共享。先查 Caffeine没命中再查 Redis再回源数据库。这样热点订单详情的 QPS 会好很多。面试官不错知道本地缓存和分布式缓存的职责分离。面试官如果缓存和数据库数据不一致你怎么处理燕双非一般会先更新数据库再删除缓存或者通过延迟双删减少脏数据。强一致很难更多是靠最终一致性和合理的过期时间。面试官还能提到延迟双删说明你看过些实战内容。面试官本地生活支付场景里如何设计 Spring Security JWT 的登录认证燕双非用户登录后服务端签发 JWT前端每次带 token 请求。Spring Security 负责过滤器链校验 token、提取用户身份和权限。这样无状态适合前后端分离和多实例部署。面试官对无状态认证在互联网业务里很常见。面试官如果商家后台还有管理员和运营角色你怎么做权限控制燕双非可以基于角色和权限点做 RBAC比如商家管理员能改商品、运营只能看报表。细一点的话还要结合数据权限比如只能看自己门店的数据。面试官这个回答还可以知道权限不仅是菜单还包括数据范围。面试官支付链路里如何防止重复扣款和回调乱序燕双非支付请求也要幂等生成唯一支付单号。回调的时候先校验签名再根据支付单号查状态只允许从“待支付”流转到“已支付”。乱序回调就按状态机处理状态不对直接忽略。面试官很好支付系统最怕状态乱跳你至少说到了状态机。第三轮大数据与 AI 服务、云原生落地面试官现在我们做的是 AI 驱动的本地生活助手用户问“附近适合聚餐的店”系统要结合商品、评价、位置、历史行为做语义搜索。你会怎么设计燕双非可以把门店、菜品、评价这些内容做向量化存到向量数据库比如 Milvus 或 Redis Vector。用户问题先经过 Embedding 模型转向量再做语义检索把最相关的内容召回。然后交给 LLM 做总结避免只靠关键词匹配。面试官不错已经开始像个做过 AI 应用的人了。面试官那 RAG 和 Agent 有什么区别燕双非RAG 更像“先检索再生成”重点是把企业文档或业务知识找出来喂给模型Agent 则更像会调用工具的智能体不仅能查资料还能下单、查库存、发消息。Agentic RAG 就是两者结合检索增强后再让 Agent 决策下一步动作。面试官回答得不错方向清晰。面试官如果这个 AI 助手要部署到 Kubernetes 上并且要支持高并发你会关注哪些点燕双非要看资源限额、弹性伸缩、探针、配置中心和日志监控。比如用 HPA 做自动扩缩容Micrometer Prometheus Grafana 看 QPS 和延迟Jaeger/Zipkin 追踪一次请求在检索、模型调用、数据库查询中的耗时。面试官嗯云原生可观测性这块你是知道一些的。面试官最后一个问题如果模型输出了幻觉胡说八道你怎么降低风险燕双非这个……我会尽量让它少胡说。比如加检索约束只让模型基于召回内容回答再加提示词限制要求引用来源关键动作要走工具校验不让它直接拍脑袋执行。还有就是把高风险问题转人工。面试官虽然说得有点朴素但思路是对的。今天先到这里你回去等通知吧。问题详解结合本地生活服务与 AI 助手业务深入理解1. 下单接口幂等设计在本地生活团购业务中用户可能因为网络重试、前端重复点击、网关超时而多次提交同一订单。幂等的核心是无论请求发来多少次业务结果都应一致。常见做法是- 以业务单号、用户 ID、活动 ID 设计唯一索引- 在服务端先做幂等校验再落库- 对于 MQ 消费场景消费端也要做幂等避免重复发券、重复扣库存- 对外回调和支付通知必须基于状态机进行流转控制。2. Spring Boot 相对传统 Spring MVC 的优势Spring Boot 更适合互联网大厂高频迭代场景。它通过 starter、自动配置、内嵌容器减少了大量 XML 和手工装配工作让团队能更快交付接口、上线新功能。对于团购、支付、商家后台这种变化快的业务开发效率和标准化非常重要。3. Kafka 与 RabbitMQ 的选择Kafka 更适合事件流、日志采集、订单状态变更、用户行为埋点等高吞吐场景。RabbitMQ 更擅长复杂路由、延迟队列、精细 ACK 控制。对于订单创建后异步通知商家、刷新缓存、触发风控等链路Kafka 的吞吐和分区扩展能力更有优势。4. 消息重复消费的处理MQ 在生产环境中不应假设“绝对只投递一次”。真实项目里应采用“至少一次投递 业务幂等”的设计- 通过唯一业务键落库去重- Redis setnx/数据库唯一索引实现防重- 结合业务状态判断是否已处理- 消费失败要有重试、死信、告警机制。5. Redis 与 Caffeine 多级缓存Caffeine 是高性能本地缓存适合承载单机热点数据Redis 是分布式缓存适合多实例共享。多级缓存可以明显降低数据库压力。实现时通常采用“先本地后远程再回源”的读取链路并配合合理过期时间、缓存失效通知、延迟双删来缓解一致性问题。6. 缓存与数据库一致性缓存和数据库一般追求最终一致性而不是强一致。写操作常见策略为- 先更新数据库再删除缓存- 使用延迟双删减少并发读写导致的旧值回填- 对核心账务类数据必要时采用更严格的事务或消息补偿机制。7. Spring Security JWT 的认证模型JWT 适合无状态认证尤其是前后端分离、多实例部署场景。登录成功后签发 token客户端每次请求携带 token服务端通过 Spring Security 过滤器链解析、验证签名、提取用户身份和权限。这样无需服务端保存 session扩展性更好。8. RBAC 与数据权限权限管理不能只停留在菜单和接口层。对于商家后台、运营后台还应考虑门店范围、组织层级、区域权限等数据权限控制。例如运营只能查看负责区域内门店的数据商家只能修改自家商品。9. 支付链路幂等与状态机支付系统必须防止重复扣款和回调乱序。做法通常包括- 使用唯一支付单号- 回调签名校验- 根据订单状态机控制流转- 只允许特定状态之间转换- 对异常回调进行记录和补偿。10. 语义搜索、向量数据库与 RAG在 AI 场景里用户不会总是输入精确关键词例如“适合聚餐、环境好、停车方便的店”。这类需求适合语义搜索。做法是将门店信息、评论、菜品等文本通过 Embedding 模型向量化存入 Milvus、Chroma 或 Redis 向量索引中查询时将用户问题也向量化再做相似度检索。RAG 先召回相关内容再让大模型基于内容生成答案可显著降低幻觉。11. Agent、Agentic RAG 与工具调用RAG 解决“检索知识”的问题Agent 解决“执行动作”的问题。比如用户问“帮我找一家能聚餐的店并下单预约”系统不仅要查知识还要调用门店查询、库存判断、预约接口等工具。Agentic RAG 是更进一步的组合方案先检索再决策再调用工具最后生成结果。企业级 AI 常见于智能客服、企业文档问答、复杂工作流编排。12. 云原生部署与可观测性AI 服务、检索服务、订单服务通常会部署在 Kubernetes 上。需要重点关注- HPA 自动伸缩- readiness/liveness 探针- 配置与密钥管理- Micrometer 指标埋点- Prometheus Grafana 监控- Jaeger/Zipkin 链路追踪- ELK 做日志分析。这些能力决定系统在高峰流量下是否稳定可控。13. 如何应对 AI 幻觉AI 幻觉是企业落地中的核心风险。常见措施有- 检索增强减少模型自由发挥- 提示词约束限定回答范围- 引用来源增强可解释性- 工具校验重要动作必须走后端接口确认- 风险分级高危问题转人工。在生产场景里“能回答”不如“答得对、答得稳”。总结这类面试往往不是考你会不会背框架而是考你能不能把 Java 基础、缓存、消息、权限、云原生、AI 应用串成一个完整业务闭环。只要你能围绕业务问题讲出设计思路、关键风险和落地方案就更接近大厂面试的期待。感谢阅读希望这篇文章能帮助大家在 Java 面试和真实业务设计中更有思路、更有底气。面试问题清单如何设计下单接口幂等为什么 Spring Boot 比传统 Spring MVC 更适合互联网项目订单事件应该选 Kafka 还是 RabbitMQ消息重复消费如何处理如何使用 Redis 和 Caffeine 做多级缓存缓存与数据库不一致怎么解决如何用 Spring Security JWT 做无状态认证如何做角色权限与数据权限控制支付链路如何防止重复扣款和回调乱序如何用向量数据库和 Embedding 做语义搜索RAG 和 Agent 有什么区别AI 服务部署到 Kubernetes 时关注什么如何降低 AI 幻觉风险 
长河君 · 2026/8/20 1:57:20 · 阅读 1.2k 互联网大厂 Java 面试实录：Spring Boot、Kafka、Redis、Spring Security、AI RAG 与 Kubernetes 云原生场景
互联网大厂 Java 面试实录Spring Boot、Kafka、Redis、Spring Security、AI RAG 与 Kubernetes 云原生场景场景某互联网大厂招聘“Java 高级工程师”业务方向覆盖本地生活服务 大数据与 AI 服务。面试现场严肃的面试官和自称“水货程序员”的燕双非围绕真实业务展开三轮追问。第一轮本地生活服务的下单链路与基础能力面试官我们做本地生活团购用户从 App 下单到商家接单后端用 Spring Boot MyBatis MySQL。先说说你怎么设计这个下单接口如何保证幂等燕双非这个简单先查一下订单有没有创建过如果创建过就直接返回成功没有就插入一条记录。可以加一个唯一索引比如用户 ID 业务单号防止重复下单。再配合 Redis 做一下请求去重应该就稳了。面试官思路是对的能把业务幂等和数据库约束结合起来说明你不是只会背概念。面试官那你说说 Spring Boot 在这个项目里为什么比传统 Spring MVC 更合适燕双非因为 Spring Boot 开箱即用少配置内嵌 Tomcat启动快。像数据库连接池、JSON 序列化、日志这些都能用 starter 快速集成适合快速迭代的互联网项目。面试官嗯能结合交付效率说说明你做过业务。面试官订单创建后要发消息给商家系统你会用 Kafka 还是 RabbitMQ为什么燕双非如果是高吞吐、可扩展的订单事件流我会偏向 Kafka。它适合日志和事件流处理能扛比较大的并发如果是需要更灵活的路由和复杂 ack 语义RabbitMQ 也可以。不过我们这种下单事件Kafka 更常见。面试官回答得还行至少知道不同 MQ 的定位。面试官如果 Kafka 消息重复消费了你怎么处理燕双非这个……可以在消费端做幂等比如用订单 ID 做去重表或者 Redis setnx 记录处理状态。实在不行再查业务状态反正核心就是别重复扣库存、别重复发券。面试官说得有点糙但方向没错先记账式去重再做业务状态校验。第二轮缓存、权限、支付与风控面试官订单后续会查详情、查状态、查优惠券。这里你怎么用 Redis 和 Caffeine 做多级缓存燕双非Caffeine 放本地热点数据访问快Redis 做分布式缓存多个实例共享。先查 Caffeine没命中再查 Redis再回源数据库。这样热点订单详情的 QPS 会好很多。面试官不错知道本地缓存和分布式缓存的职责分离。面试官如果缓存和数据库数据不一致你怎么处理燕双非一般会先更新数据库再删除缓存或者通过延迟双删减少脏数据。强一致很难更多是靠最终一致性和合理的过期时间。面试官还能提到延迟双删说明你看过些实战内容。面试官本地生活支付场景里如何设计 Spring Security JWT 的登录认证燕双非用户登录后服务端签发 JWT前端每次带 token 请求。Spring Security 负责过滤器链校验 token、提取用户身份和权限。这样无状态适合前后端分离和多实例部署。面试官对无状态认证在互联网业务里很常见。面试官如果商家后台还有管理员和运营角色你怎么做权限控制燕双非可以基于角色和权限点做 RBAC比如商家管理员能改商品、运营只能看报表。细一点的话还要结合数据权限比如只能看自己门店的数据。面试官这个回答还可以知道权限不仅是菜单还包括数据范围。面试官支付链路里如何防止重复扣款和回调乱序燕双非支付请求也要幂等生成唯一支付单号。回调的时候先校验签名再根据支付单号查状态只允许从“待支付”流转到“已支付”。乱序回调就按状态机处理状态不对直接忽略。面试官很好支付系统最怕状态乱跳你至少说到了状态机。第三轮大数据与 AI 服务、云原生落地面试官现在我们做的是 AI 驱动的本地生活助手用户问“附近适合聚餐的店”系统要结合商品、评价、位置、历史行为做语义搜索。你会怎么设计燕双非可以把门店、菜品、评价这些内容做向量化存到向量数据库比如 Milvus 或 Redis Vector。用户问题先经过 Embedding 模型转向量再做语义检索把最相关的内容召回。然后交给 LLM 做总结避免只靠关键词匹配。面试官不错已经开始像个做过 AI 应用的人了。面试官那 RAG 和 Agent 有什么区别燕双非RAG 更像“先检索再生成”重点是把企业文档或业务知识找出来喂给模型Agent 则更像会调用工具的智能体不仅能查资料还能下单、查库存、发消息。Agentic RAG 就是两者结合检索增强后再让 Agent 决策下一步动作。面试官回答得不错方向清晰。面试官如果这个 AI 助手要部署到 Kubernetes 上并且要支持高并发你会关注哪些点燕双非要看资源限额、弹性伸缩、探针、配置中心和日志监控。比如用 HPA 做自动扩缩容Micrometer Prometheus Grafana 看 QPS 和延迟Jaeger/Zipkin 追踪一次请求在检索、模型调用、数据库查询中的耗时。面试官嗯云原生可观测性这块你是知道一些的。面试官最后一个问题如果模型输出了幻觉胡说八道你怎么降低风险燕双非这个……我会尽量让它少胡说。比如加检索约束只让模型基于召回内容回答再加提示词限制要求引用来源关键动作要走工具校验不让它直接拍脑袋执行。还有就是把高风险问题转人工。面试官虽然说得有点朴素但思路是对的。今天先到这里你回去等通知吧。问题详解结合本地生活服务与 AI 助手业务深入理解1. 下单接口幂等设计在本地生活团购业务中用户可能因为网络重试、前端重复点击、网关超时而多次提交同一订单。幂等的核心是无论请求发来多少次业务结果都应一致。常见做法是- 以业务单号、用户 ID、活动 ID 设计唯一索引- 在服务端先做幂等校验再落库- 对于 MQ 消费场景消费端也要做幂等避免重复发券、重复扣库存- 对外回调和支付通知必须基于状态机进行流转控制。2. Spring Boot 相对传统 Spring MVC 的优势Spring Boot 更适合互联网大厂高频迭代场景。它通过 starter、自动配置、内嵌容器减少了大量 XML 和手工装配工作让团队能更快交付接口、上线新功能。对于团购、支付、商家后台这种变化快的业务开发效率和标准化非常重要。3. Kafka 与 RabbitMQ 的选择Kafka 更适合事件流、日志采集、订单状态变更、用户行为埋点等高吞吐场景。RabbitMQ 更擅长复杂路由、延迟队列、精细 ACK 控制。对于订单创建后异步通知商家、刷新缓存、触发风控等链路Kafka 的吞吐和分区扩展能力更有优势。4. 消息重复消费的处理MQ 在生产环境中不应假设“绝对只投递一次”。真实项目里应采用“至少一次投递 业务幂等”的设计- 通过唯一业务键落库去重- Redis setnx/数据库唯一索引实现防重- 结合业务状态判断是否已处理- 消费失败要有重试、死信、告警机制。5. Redis 与 Caffeine 多级缓存Caffeine 是高性能本地缓存适合承载单机热点数据Redis 是分布式缓存适合多实例共享。多级缓存可以明显降低数据库压力。实现时通常采用“先本地后远程再回源”的读取链路并配合合理过期时间、缓存失效通知、延迟双删来缓解一致性问题。6. 缓存与数据库一致性缓存和数据库一般追求最终一致性而不是强一致。写操作常见策略为- 先更新数据库再删除缓存- 使用延迟双删减少并发读写导致的旧值回填- 对核心账务类数据必要时采用更严格的事务或消息补偿机制。7. Spring Security JWT 的认证模型JWT 适合无状态认证尤其是前后端分离、多实例部署场景。登录成功后签发 token客户端每次请求携带 token服务端通过 Spring Security 过滤器链解析、验证签名、提取用户身份和权限。这样无需服务端保存 session扩展性更好。8. RBAC 与数据权限权限管理不能只停留在菜单和接口层。对于商家后台、运营后台还应考虑门店范围、组织层级、区域权限等数据权限控制。例如运营只能查看负责区域内门店的数据商家只能修改自家商品。9. 支付链路幂等与状态机支付系统必须防止重复扣款和回调乱序。做法通常包括- 使用唯一支付单号- 回调签名校验- 根据订单状态机控制流转- 只允许特定状态之间转换- 对异常回调进行记录和补偿。10. 语义搜索、向量数据库与 RAG在 AI 场景里用户不会总是输入精确关键词例如“适合聚餐、环境好、停车方便的店”。这类需求适合语义搜索。做法是将门店信息、评论、菜品等文本通过 Embedding 模型向量化存入 Milvus、Chroma 或 Redis 向量索引中查询时将用户问题也向量化再做相似度检索。RAG 先召回相关内容再让大模型基于内容生成答案可显著降低幻觉。11. Agent、Agentic RAG 与工具调用RAG 解决“检索知识”的问题Agent 解决“执行动作”的问题。比如用户问“帮我找一家能聚餐的店并下单预约”系统不仅要查知识还要调用门店查询、库存判断、预约接口等工具。Agentic RAG 是更进一步的组合方案先检索再决策再调用工具最后生成结果。企业级 AI 常见于智能客服、企业文档问答、复杂工作流编排。12. 云原生部署与可观测性AI 服务、检索服务、订单服务通常会部署在 Kubernetes 上。需要重点关注- HPA 自动伸缩- readiness/liveness 探针- 配置与密钥管理- Micrometer 指标埋点- Prometheus Grafana 监控- Jaeger/Zipkin 链路追踪- ELK 做日志分析。这些能力决定系统在高峰流量下是否稳定可控。13. 如何应对 AI 幻觉AI 幻觉是企业落地中的核心风险。常见措施有- 检索增强减少模型自由发挥- 提示词约束限定回答范围- 引用来源增强可解释性- 工具校验重要动作必须走后端接口确认- 风险分级高危问题转人工。在生产场景里“能回答”不如“答得对、答得稳”。总结这类面试往往不是考你会不会背框架而是考你能不能把 Java 基础、缓存、消息、权限、云原生、AI 应用串成一个完整业务闭环。只要你能围绕业务问题讲出设计思路、关键风险和落地方案就更接近大厂面试的期待。感谢阅读希望这篇文章能帮助大家在 Java 面试和真实业务设计中更有思路、更有底气。面试问题清单如何设计下单接口幂等为什么 Spring Boot 比传统 Spring MVC 更适合互联网项目订单事件应该选 Kafka 还是 RabbitMQ消息重复消费如何处理如何使用 Redis 和 Caffeine 做多级缓存缓存与数据库不一致怎么解决如何用 Spring Security JWT 做无状态认证如何做角色权限与数据权限控制支付链路如何防止重复扣款和回调乱序如何用向量数据库和 Embedding 做语义搜索RAG 和 Agent 有什么区别AI 服务部署到 Kubernetes 时关注什么如何降低 AI 幻觉风险