互联网大厂 Java 面试实录：Spring Cloud + Kafka + Redis + Spring Security + AI 的电商场景八股与实战

互联网大厂 Java 面试实录Spring Cloud Kafka Redis Spring Security AI 的电商场景八股与实战场景某互联网大厂电商平台 Java 岗位面试。面试官严肃认真候选人“燕双非”嘴上很会手上一般简单题能答对复杂题开始含糊其辞但偶尔也能靠一点点经验蒙对。第一轮高并发下的订单链路面试官你先说说电商下单链路里为什么我们常常用 Spring Boot MyBatis Redis 来做基础架构燕双非Spring Boot 启动快、配置少MyBatis 适合写复杂 SQLRedis 用来缓存商品信息、库存、用户会话三者配合起来开发效率高性能也比较稳。面试官不错至少知道各自负责什么。那如果商品详情页流量特别大缓存怎么设计燕双非一般会做多级缓存吧先查本地缓存再查 Redis最后查数据库。热点商品还可以设置较短的过期时间避免缓存雪崩。面试官继续说缓存穿透、击穿、雪崩分别怎么处理燕双非穿透就是查不存在的数据可以布隆过滤器或者缓存空值击穿是热点 key 失效可以加互斥锁或者逻辑过期雪崩就是大量 key 同时过期可以加随机过期时间。面试官回答得还行说明你不是完全“缓存盲”。那订单提交时Redis 里扣库存和数据库扣库存怎么保证一致性燕双非这个……一般会先扣 Redis再异步落库或者用消息队列做最终一致性。也可以用分布式事务框架不过我更倾向于能不用就不用。面试官思路有但还不够完整等会儿再展开。第二轮消息驱动与分布式治理面试官下单成功后订单服务要通知库存、积分、营销系统你会选 Kafka 还是 RabbitMQ为什么燕双非如果是高吞吐、日志型、可回放的业务我会选 Kafka如果是更强调路由、延迟确认和复杂消息模型RabbitMQ 也很合适。电商订单通知通常 Kafka 用得更多。面试官那你怎么保证消息不丢、不重、不过期燕双非不丢的话生产端要确认落盘消费端要幂等不重的话消费者根据业务唯一键去重不过期的话可以设置合理保留策略或者消费失败后进入死信队列。面试官幂等设计你举个例子。燕双非比如订单消息里有 orderId库存扣减表里把 orderId 作为唯一索引重复消费时数据库会直接拦住或者先查再写但唯一索引更稳。面试官可以。那如果库存服务挂了订单链路还要继续怎么做熔断和限流燕双非可以用 Resilience4j 做熔断、限流、重试和隔离。比如库存接口超时次数太多就快速失败避免拖垮订单服务高峰期可以做令牌桶限流。面试官很好。那 Spring Cloud 体系下服务发现、配置中心、网关你怎么搭燕双非服务发现可以用 Eureka 或者 Consul网关可以用 Spring Cloud Gateway配置中心可以配合 Spring Cloud Config。实际还要看团队的基础设施和维护成本。面试官对这才是架构选型的思路不是背名词。第三轮安全、AI 与电商智能化面试官现在很多电商都在做 AI 导购。假设我们要给商品问答接一个企业知识库怎么设计燕双非可以做 RAG。先把商品说明、售后政策、活动规则做文档加载和切分再向量化存到向量数据库里比如 Milvus 或 Redis 向量检索。用户提问时先做语义检索再把检索结果拼到提示词里交给大模型回答。面试官那为什么不用直接让大模型回答燕双非因为会有幻觉尤其是价格、库存、活动规则这种强业务事实不能乱编。RAG 能把回答约束在企业知识范围内降低幻觉。面试官如果要让 AI 不只是回答问题还能帮用户查订单、改地址、催发货呢燕双非那就是 Agent 了吧。它可以通过工具调用标准化把查订单、改地址这些能力封装成工具模型根据用户意图选择工具执行再把结果返回给用户。面试官很好。那安全上AI 接口和普通业务接口有什么不同燕双非AI 接口要更注意鉴权、审计、敏感信息脱敏还要防提示词注入。比如用户输入里夹带恶意指令不能直接把全部上下文原样喂给模型。面试官最后一个问题电商支付链路里 Spring Security JWT 你会怎么配合燕双非登录后签发 JWT前端请求带 token网关或服务端校验签名和过期时间支付、退款这类敏感接口再加二次校验和权限控制比如角色、设备校验、风控策略。面试官行今天先到这儿你回家等通知吧。问题详细解析1. Spring Boot MyBatis Redis 为什么适合电商基础链路电商系统常见特点是读多写少、热点集中、业务复杂、SQL 诉求强。Spring Boot 负责快速搭建服务框架MyBatis 适合承载复杂查询、动态 SQL 和性能可控的持久化访问Redis 则用于缓存商品详情、库存快照、用户会话、验证码、限流计数等高频数据。三者组合能兼顾开发效率与运行性能。2. 缓存三大问题穿透、击穿、雪崩缓存穿透查询不存在的数据绕过缓存直达数据库。常用方案是布隆过滤器、缓存空值、参数校验。缓存击穿热点 key 突然失效大量并发打到数据库。常用方案是互斥锁、逻辑过期、永不过期配合后台更新。缓存雪崩大量 key 同时失效或缓存服务故障。常用方案是过期时间加随机值、多级缓存、限流降级、熔断保护。在电商场景里商品详情、活动信息、库存信息都容易成为热点必须提前设计防护策略。3. 订单与库存一致性怎么做订单系统最常见的问题是“下单成功但库存没减”或“库存减了但订单失败”。通常采用最终一致性方案订单创建成功后发送消息到 MQ库存服务异步消费并扣减库存或者采用事务消息、可靠消息最终一致性方案。若强一致性要求非常高则会引入分布式事务但代价较大通常只在核心资金链路谨慎使用。4. Kafka 与 RabbitMQ 的取舍Kafka 更适合高吞吐、可回放、日志流式处理场景例如订单事件流、埋点、数据同步RabbitMQ 更适合复杂路由、业务确认、较强的消息投递语义。电商订单通知、库存同步、营销发券等场景都能用 MQ关键在于团队对吞吐、延迟、运维复杂度的权衡。5. 消息幂等、可靠投递、死信处理消息系统无法天然保证“只处理一次”所以消费者必须幂等。常见做法包括业务唯一键去重、唯一索引约束、幂等表、状态机校验。可靠投递方面要关注生产者确认、消费者手动 ack、失败重试、补偿任务。死信队列则用于处理多次失败仍无法消费的消息避免消息堵塞主流程。6. Resilience4j 的作用在高并发电商系统中下游服务抖动很常见。Resilience4j 可提供熔断、限流、重试、隔离、舱壁等能力避免一个慢接口拖垮整个链路。比如库存服务超时率过高时订单服务可以快速失败并提示用户稍后重试。7. Spring Cloud 体系如何搭建Spring Cloud 常用于微服务治理核心能力包括服务注册发现、配置管理、网关、负载均衡、熔断与链路追踪。Eureka、Consul 可做注册中心Spring Cloud Gateway 做统一入口配置中心集中管理多环境配置再配合 Micrometer、Prometheus、Grafana 进行指标监控形成完整的微服务治理闭环。8. RAG、Agent 与企业知识库企业想做 AI 导购、智能客服、文档问答时不能直接依赖大模型“自由发挥”因为它可能产生幻觉。RAG 的核心是“先检索、再生成”把企业文档切分、向量化、存储到向量数据库用户提问后先做语义检索再把相关片段注入提示词中生成回答。若系统还需要调用查订单、改地址、查库存等外部工具就进入 Agent 阶段模型会根据任务选择工具并执行适合复杂工作流和智能客服系统。9. AI 场景的安全问题AI 接口除了传统鉴权还要防提示词注入、越权检索、敏感信息泄露、结果幻觉。对外输出前应做脱敏和内容审核对内部知识库应分级权限控制避免普通用户访问到不该看的文档。10. Spring Security JWT 在支付链路中的使用JWT 适合无状态认证前后端分离和微服务环境里使用方便。登录后签发 token网关或资源服务器进行签名校验和过期检查。支付、退款等敏感操作还应叠加权限判断、二次验证、风控策略如设备指纹、异常行为检测、交易限额控制等。感谢阅读希望这篇文章能帮助大家更好地准备 Java 面试把电商与 AI 场景下的常见问题吃透顺利拿到心仪的 offer。