基于 Spring Boot Kafka Redis Elasticsearch 的互联网大厂 Java 面试实录燕双非在电商增长场景里的 3 轮攻防场景设定某互联网大厂招聘 Java 后端工程师业务背景是电商增长与内容推荐。面试官风格严肃、追问深入候选人是自称“什么都会一点”的水货程序员燕双非。简单问题他能勉强答出来回答到点上时面试官会顺势夸赞并继续引导遇到复杂问题则开始含糊其辞、左右横跳。第一轮基础与系统设计意识面试官先从基础开始。你们团队做的是电商增长链路用户下单后会触发优惠券发放、站内信和积分变动。你先说说为什么这类场景常用Spring Boot而不是传统的 Spring MVC 手工配置燕双非因为 Spring Boot 快开箱即用自动配置比较多少写 XML适合快速搭建服务。面试官嗯方向对。那如果服务启动后慢、内存占用高你会怎么看待自动配置带来的副作用燕双非这个……我一般先把依赖删一删能跑就行。自动配置太多可能会“自动”出问题吧。面试官继续。那你说说在订单发券这种链路里为什么要把“下单成功”与“发券”解耦如果直接同步调用会怎样燕双非同步调用的话下单接口会被发券、积分这些慢操作拖住容易超时。解耦后可以用消息队列主链路更稳。面试官不错业务意识是有的。那这里如果用Kafka你会如何设计消息幂等避免重复发券燕双非可以用订单号做唯一键发券前先查一下数据库有没有发过。再配合消费端去重……大概这样。面试官可以先记住一个关键点业务唯一键 消费幂等 结果落库这是高并发链路的基本功。面试官那如果优惠券服务和积分服务都要一起处理但一个成功一个失败怎么办燕双非额……这个就看情况吧失败的那个重试一下面试官你先别急着重试回去想想分布式事务和最终一致性怎么权衡。第二轮缓存、数据访问与可靠性面试官电商大促时首页推荐和商品详情会被频繁访问。你会怎么用Redis和Caffeine做多级缓存燕双非本地用 Caffeine 提升热点读性能Redis 作为共享缓存先查本地再查 Redis再查数据库。面试官不错。那缓存穿透、击穿、雪崩分别是什么燕双非穿透是查不到一直查击穿是热点 key 失效后瞬间很多请求打到数据库雪崩是很多 key 同时过期。面试官这三个概念你分得还算清楚。继续说针对热点商品详情页怎么防击穿燕双非可以加互斥锁、逻辑过期或者预热热点数据。面试官可以。再往下电商商品信息通常需要做复杂字段映射。如果数据库字段、接口字段、展示字段不一致你会怎么做燕双非可以用MapStruct做 DTO 转换省得手写一堆 setter。面试官很好。那你知道为什么很多公司现在会把 JDBC 访问层从传统 MyBatis/JPA 之外补充引入Spring Data JDBC或者R2DBC吗燕双非嗯……可能是更轻量吧或者响应式更快我平时还是主要用 MyBatis。面试官对。你至少要知道Spring Data JDBC适合简单聚合模型R2DBC适合响应式非阻塞访问但它们都不是“银弹”。面试官那数据库连接池你怎么选比如HikariCP和 C3P0。燕双非我一般听说 HikariCP 性能更好、现在用得更多所以优先选它。面试官这个回答可以。最后一个场景问题大促期间缓存击穿导致数据库压力激增你会如何结合限流、降级、消息异步化来止血燕双非入口限流热点接口降级返回兜底数据非核心流程走消息队列异步处理。数据库压力大的时候先保核心下单链路。面试官很好这说明你至少知道“先保活再优化”。第三轮云原生、可观测性与 AI 能力面试官现在我们把场景升级一下。公司要做一个AIGC 电商助手用户可以自然语言问“这件衣服适合什么场景、有没有搭配建议、库存够不够”。你会怎么把Spring AI、RAG和企业知识库结合燕双非先把商品详情、搭配规则、FAQ 文档做向量化存到向量数据库里用户提问时先做语义检索再把检索结果拼到提示词里给大模型生成回答。面试官思路不错。那为什么不能直接让大模型裸问裸答燕双非因为它可能胡说八道会有幻觉。接入检索后能减少瞎编。面试官说到点上了。那如果你的知识库里面有商品库存、价格、活动规则这类实时数据RAG 还不够你会怎么处理燕双非呃……可以再加工具调用实时查库存接口和活动接口。模型负责组织答案实时数据由工具返回。面试官这就对了。那你理解的Agent和普通问答链路有什么区别燕双非Agent 更像会自己拆任务、选工具、执行步骤的智能代理普通问答就是一次性生成。面试官继续。那如果你的系统拆成商品、库存、推荐、营销四个微服务之间用gRPC和OpenFeign混合调用你会怎么考虑适用边界燕双非内部高性能强类型通信可以考虑 gRPC对接 HTTP 风格服务、方便和 Spring Cloud 生态结合时可以用 OpenFeign。面试官嗯回答有层次。那服务治理方面如果某个推荐服务偶发慢响应你会怎么配合Resilience4j做熔断、限流、重试燕双非慢服务先加超时再设置熔断阈值失败后走降级推荐重试不能乱加不然会雪上加霜。面试官不错已经开始像个做过线上系统的人了。最后一个问题你怎么监控这套 AI 电商助手的调用质量燕双非可以用 Micrometer 打埋点Prometheus Grafana 看 QPS、延迟、错误率再结合日志和链路追踪比如 Zipkin 或 Jaeger看哪一步慢、哪一步错。面试官行今天先到这。你回去等通知吧。问题详解结合电商增长与 AIGC 场景梳理技术要点1. 为什么电商增长链路常用 Spring BootSpring Boot 的价值在于自动配置、starter 依赖和约定优于配置能快速搭建业务服务。对于下单发券、订单通知、营销异步处理这类场景团队更关注业务交付速度和可维护性而不是手工搭建大量基础设施。需要注意的是自动配置会引入额外的初始化成本和依赖复杂度因此生产环境要结合启动耗时、Bean 数量、内存占用进行优化。2. 为什么同步发券会拖慢订单主链路订单主链路的目标是尽快返回用户“下单成功”而发券、积分、通知都属于派生动作。如果把这些逻辑同步串联任何一个下游异常都会扩大为用户感知的接口超时。更合理的方式是通过 Kafka、RabbitMQ 等消息队列进行解耦把“下单成功”作为事件发送出去后续业务异步消费做到最终一致性。3. Kafka 场景下如何保证幂等幂等的核心是同一业务事件重复到达时系统结果保持一致。常见做法包括使用订单号、支付单号等业务唯一键消费者先查本地记录或幂等表使用数据库唯一索引防止重复落库业务处理成功后再提交消费位点。对于发券这种不可重复发放的动作幂等设计是上线前必须做好的。4. 多级缓存为什么常见Redis 作为分布式缓存适合多实例共享Caffeine 作为本地缓存延迟更低适合热点小数据。多级缓存通常是“先本地、再远程、最后数据库”的三段式访问。这样既能降低 Redis 压力也能减少网络开销。需要注意缓存一致性、失效策略和热点数据预热。5. 缓存穿透、击穿、雪崩如何应对穿透可通过布隆过滤器、空值缓存和参数校验来治理击穿可通过互斥锁、逻辑过期、热点预热来避免请求瞬时打爆数据库雪崩可通过随机过期时间、分批失效、限流和降级来缓冲。大促场景中这些问题往往叠加出现所以通常要组合治理。6. HikariCP 为什么常被优先选用HikariCP 在性能、资源占用和实现简洁性方面表现优秀连接获取与归还效率高适合高并发业务。相比早期一些连接池实现它在现代 Java 服务中更常被默认推荐。当然连接池选择还要结合监控、超时参数、连接泄漏检测和数据库本身能力综合评估。7. Spring Data JDBC 与 R2DBC 的定位是什么Spring Data JDBC 更轻量适合简单领域模型和清晰的聚合边界R2DBC 则是响应式数据库访问方案适合高并发非阻塞链路。它们并不是 MyBatis/JPA 的简单替代而是在不同复杂度和性能目标下提供不同选择。复杂查询、强映射控制、报表分析等场景很多团队仍然会保留 MyBatis 或 JPA。8. 电商 AIGC 助手为什么需要 RAG大模型擅长生成但不天然拥有企业内部知识。电商场景里商品信息、活动规则、库存、售后政策变化很快直接裸问模型容易产生幻觉。RAG 的做法是先从企业文档、商品库、FAQ、活动配置中做向量化检索把最相关的上下文拼进提示词再让模型生成答案这样更准确、更可控。9. Agent 与普通问答链路的差异是什么普通问答链路通常是一次检索、一轮生成Agent 则能拆解目标、规划步骤、选择工具、执行多个动作并根据结果继续迭代。比如用户问“帮我推荐适合通勤的外套并查库存”Agent 可以先理解意图再查商品、查库存、查活动最后生成带约束的推荐结果。这类能力适合复杂工作流和智能客服系统。10. gRPC 和 OpenFeign 如何选型gRPC 适合内部高性能、强类型、低延迟服务调用尤其适合多语言微服务间通信OpenFeign 更贴合 Spring Cloud 生态使用 HTTP 接口更直观适合和已有 REST 服务体系协作。实际落地中经常会出现内部核心链路用 gRPC外围能力或第三方对接用 OpenFeign 的混合方案。11. Resilience4j 为什么适合做服务治理Resilience4j 提供熔断、限流、重试、隔离、超时等能力适合在微服务间构建防护墙。面对慢服务、抖动服务或下游故障合理的超时与熔断能防止线程堆积和级联故障。需要强调的是重试不能滥用尤其是幂等性不强的接口盲目重试可能带来更大的副作用。12. 如何监控 AIGC 电商助手的质量监控不仅看接口是否成功还要看模型调用链路的整体质量。可以通过 Micrometer 统一埋点Prometheus 收集指标Grafana 做可视化结合日志、Zipkin 或 Jaeger 追踪请求路径。重点指标包括响应延迟、检索命中率、工具调用成功率、模型输出满意度、幻觉率等。只有把业务指标和技术指标一起看才能真正评估 AI 系统是否可用。总体来说这套面试题围绕电商增长、缓存治理、消息异步、云原生调用、AIGC 企业知识问答等场景展开既考察基础功也考察候选人对真实业务系统的理解。希望这篇内容能帮助大家在准备 Java 面试时更好地把知识点与实际业务结合起来。感谢阅读愿这篇文章能帮助到正在求职和进阶的你。
基于 Spring Boot Kafka Redis Elasticsearch 的互联网大厂 Java 面试实录燕双非在电商增长场景里的 3 轮攻防场景设定某互联网大厂招聘 Java 后端工程师业务背景是电商增长与内容推荐。面试官风格严肃、追问深入候选人是自称“什么都会一点”的水货程序员燕双非。简单问题他能勉强答出来回答到点上时面试官会顺势夸赞并继续引导遇到复杂问题则开始含糊其辞、左右横跳。第一轮基础与系统设计意识面试官先从基础开始。你们团队做的是电商增长链路用户下单后会触发优惠券发放、站内信和积分变动。你先说说为什么这类场景常用Spring Boot而不是传统的 Spring MVC 手工配置燕双非因为 Spring Boot 快开箱即用自动配置比较多少写 XML适合快速搭建服务。面试官嗯方向对。那如果服务启动后慢、内存占用高你会怎么看待自动配置带来的副作用燕双非这个……我一般先把依赖删一删能跑就行。自动配置太多可能会“自动”出问题吧。面试官继续。那你说说在订单发券这种链路里为什么要把“下单成功”与“发券”解耦如果直接同步调用会怎样燕双非同步调用的话下单接口会被发券、积分这些慢操作拖住容易超时。解耦后可以用消息队列主链路更稳。面试官不错业务意识是有的。那这里如果用Kafka你会如何设计消息幂等避免重复发券燕双非可以用订单号做唯一键发券前先查一下数据库有没有发过。再配合消费端去重……大概这样。面试官可以先记住一个关键点业务唯一键 消费幂等 结果落库这是高并发链路的基本功。面试官那如果优惠券服务和积分服务都要一起处理但一个成功一个失败怎么办燕双非额……这个就看情况吧失败的那个重试一下面试官你先别急着重试回去想想分布式事务和最终一致性怎么权衡。第二轮缓存、数据访问与可靠性面试官电商大促时首页推荐和商品详情会被频繁访问。你会怎么用Redis和Caffeine做多级缓存燕双非本地用 Caffeine 提升热点读性能Redis 作为共享缓存先查本地再查 Redis再查数据库。面试官不错。那缓存穿透、击穿、雪崩分别是什么燕双非穿透是查不到一直查击穿是热点 key 失效后瞬间很多请求打到数据库雪崩是很多 key 同时过期。面试官这三个概念你分得还算清楚。继续说针对热点商品详情页怎么防击穿燕双非可以加互斥锁、逻辑过期或者预热热点数据。面试官可以。再往下电商商品信息通常需要做复杂字段映射。如果数据库字段、接口字段、展示字段不一致你会怎么做燕双非可以用MapStruct做 DTO 转换省得手写一堆 setter。面试官很好。那你知道为什么很多公司现在会把 JDBC 访问层从传统 MyBatis/JPA 之外补充引入Spring Data JDBC或者R2DBC吗燕双非嗯……可能是更轻量吧或者响应式更快我平时还是主要用 MyBatis。面试官对。你至少要知道Spring Data JDBC适合简单聚合模型R2DBC适合响应式非阻塞访问但它们都不是“银弹”。面试官那数据库连接池你怎么选比如HikariCP和 C3P0。燕双非我一般听说 HikariCP 性能更好、现在用得更多所以优先选它。面试官这个回答可以。最后一个场景问题大促期间缓存击穿导致数据库压力激增你会如何结合限流、降级、消息异步化来止血燕双非入口限流热点接口降级返回兜底数据非核心流程走消息队列异步处理。数据库压力大的时候先保核心下单链路。面试官很好这说明你至少知道“先保活再优化”。第三轮云原生、可观测性与 AI 能力面试官现在我们把场景升级一下。公司要做一个AIGC 电商助手用户可以自然语言问“这件衣服适合什么场景、有没有搭配建议、库存够不够”。你会怎么把Spring AI、RAG和企业知识库结合燕双非先把商品详情、搭配规则、FAQ 文档做向量化存到向量数据库里用户提问时先做语义检索再把检索结果拼到提示词里给大模型生成回答。面试官思路不错。那为什么不能直接让大模型裸问裸答燕双非因为它可能胡说八道会有幻觉。接入检索后能减少瞎编。面试官说到点上了。那如果你的知识库里面有商品库存、价格、活动规则这类实时数据RAG 还不够你会怎么处理燕双非呃……可以再加工具调用实时查库存接口和活动接口。模型负责组织答案实时数据由工具返回。面试官这就对了。那你理解的Agent和普通问答链路有什么区别燕双非Agent 更像会自己拆任务、选工具、执行步骤的智能代理普通问答就是一次性生成。面试官继续。那如果你的系统拆成商品、库存、推荐、营销四个微服务之间用gRPC和OpenFeign混合调用你会怎么考虑适用边界燕双非内部高性能强类型通信可以考虑 gRPC对接 HTTP 风格服务、方便和 Spring Cloud 生态结合时可以用 OpenFeign。面试官嗯回答有层次。那服务治理方面如果某个推荐服务偶发慢响应你会怎么配合Resilience4j做熔断、限流、重试燕双非慢服务先加超时再设置熔断阈值失败后走降级推荐重试不能乱加不然会雪上加霜。面试官不错已经开始像个做过线上系统的人了。最后一个问题你怎么监控这套 AI 电商助手的调用质量燕双非可以用 Micrometer 打埋点Prometheus Grafana 看 QPS、延迟、错误率再结合日志和链路追踪比如 Zipkin 或 Jaeger看哪一步慢、哪一步错。面试官行今天先到这。你回去等通知吧。问题详解结合电商增长与 AIGC 场景梳理技术要点1. 为什么电商增长链路常用 Spring BootSpring Boot 的价值在于自动配置、starter 依赖和约定优于配置能快速搭建业务服务。对于下单发券、订单通知、营销异步处理这类场景团队更关注业务交付速度和可维护性而不是手工搭建大量基础设施。需要注意的是自动配置会引入额外的初始化成本和依赖复杂度因此生产环境要结合启动耗时、Bean 数量、内存占用进行优化。2. 为什么同步发券会拖慢订单主链路订单主链路的目标是尽快返回用户“下单成功”而发券、积分、通知都属于派生动作。如果把这些逻辑同步串联任何一个下游异常都会扩大为用户感知的接口超时。更合理的方式是通过 Kafka、RabbitMQ 等消息队列进行解耦把“下单成功”作为事件发送出去后续业务异步消费做到最终一致性。3. Kafka 场景下如何保证幂等幂等的核心是同一业务事件重复到达时系统结果保持一致。常见做法包括使用订单号、支付单号等业务唯一键消费者先查本地记录或幂等表使用数据库唯一索引防止重复落库业务处理成功后再提交消费位点。对于发券这种不可重复发放的动作幂等设计是上线前必须做好的。4. 多级缓存为什么常见Redis 作为分布式缓存适合多实例共享Caffeine 作为本地缓存延迟更低适合热点小数据。多级缓存通常是“先本地、再远程、最后数据库”的三段式访问。这样既能降低 Redis 压力也能减少网络开销。需要注意缓存一致性、失效策略和热点数据预热。5. 缓存穿透、击穿、雪崩如何应对穿透可通过布隆过滤器、空值缓存和参数校验来治理击穿可通过互斥锁、逻辑过期、热点预热来避免请求瞬时打爆数据库雪崩可通过随机过期时间、分批失效、限流和降级来缓冲。大促场景中这些问题往往叠加出现所以通常要组合治理。6. HikariCP 为什么常被优先选用HikariCP 在性能、资源占用和实现简洁性方面表现优秀连接获取与归还效率高适合高并发业务。相比早期一些连接池实现它在现代 Java 服务中更常被默认推荐。当然连接池选择还要结合监控、超时参数、连接泄漏检测和数据库本身能力综合评估。7. Spring Data JDBC 与 R2DBC 的定位是什么Spring Data JDBC 更轻量适合简单领域模型和清晰的聚合边界R2DBC 则是响应式数据库访问方案适合高并发非阻塞链路。它们并不是 MyBatis/JPA 的简单替代而是在不同复杂度和性能目标下提供不同选择。复杂查询、强映射控制、报表分析等场景很多团队仍然会保留 MyBatis 或 JPA。8. 电商 AIGC 助手为什么需要 RAG大模型擅长生成但不天然拥有企业内部知识。电商场景里商品信息、活动规则、库存、售后政策变化很快直接裸问模型容易产生幻觉。RAG 的做法是先从企业文档、商品库、FAQ、活动配置中做向量化检索把最相关的上下文拼进提示词再让模型生成答案这样更准确、更可控。9. Agent 与普通问答链路的差异是什么普通问答链路通常是一次检索、一轮生成Agent 则能拆解目标、规划步骤、选择工具、执行多个动作并根据结果继续迭代。比如用户问“帮我推荐适合通勤的外套并查库存”Agent 可以先理解意图再查商品、查库存、查活动最后生成带约束的推荐结果。这类能力适合复杂工作流和智能客服系统。10. gRPC 和 OpenFeign 如何选型gRPC 适合内部高性能、强类型、低延迟服务调用尤其适合多语言微服务间通信OpenFeign 更贴合 Spring Cloud 生态使用 HTTP 接口更直观适合和已有 REST 服务体系协作。实际落地中经常会出现内部核心链路用 gRPC外围能力或第三方对接用 OpenFeign 的混合方案。11. Resilience4j 为什么适合做服务治理Resilience4j 提供熔断、限流、重试、隔离、超时等能力适合在微服务间构建防护墙。面对慢服务、抖动服务或下游故障合理的超时与熔断能防止线程堆积和级联故障。需要强调的是重试不能滥用尤其是幂等性不强的接口盲目重试可能带来更大的副作用。12. 如何监控 AIGC 电商助手的质量监控不仅看接口是否成功还要看模型调用链路的整体质量。可以通过 Micrometer 统一埋点Prometheus 收集指标Grafana 做可视化结合日志、Zipkin 或 Jaeger 追踪请求路径。重点指标包括响应延迟、检索命中率、工具调用成功率、模型输出满意度、幻觉率等。只有把业务指标和技术指标一起看才能真正评估 AI 系统是否可用。总体来说这套面试题围绕电商增长、缓存治理、消息异步、云原生调用、AIGC 企业知识问答等场景展开既考察基础功也考察候选人对真实业务系统的理解。希望这篇内容能帮助大家在准备 Java 面试时更好地把知识点与实际业务结合起来。感谢阅读愿这篇文章能帮助到正在求职和进阶的你。
