Spring Boot + Kafka + Redis + Spring Security：互联网大厂 Java 面试实录（燕双非版）

Spring Boot Kafka Redis Spring Security互联网大厂 Java 面试实录燕双非版开场背景场景互联网大厂电商业务面试。候选人燕双非主打一个“我都懂一点但不多”。面试官风格严肃问题从业务落地一路追到架构设计与性能治理。第一轮订单流转与接口设计面试官我们做一个电商下单链路。用户提交订单后如何保证“创建订单、扣库存、发消息”这三个动作尽量可靠燕双非这个简单先下单再扣库存再发 Kafka 消息。失败了就重试应该问题不大。面试官你这个思路方向对但“应该问题不大”不适合大厂。那你说说Spring Boot 里怎么把下单接口做成幂等的燕双非嗯……可以用订单号做唯一键前端重复提交就拦一下。或者 Redis 存一个 token提交一次删一次。面试官不错至少知道幂等控制。那如果 Redis token 过期了或者网络抖动导致重复请求你再补充一下服务端怎么兜底燕双非可以再在数据库层加唯一索引最后再兜一下。服务端收到请求先查状态如果订单已存在就直接返回结果。面试官这个思路就像样了。再往下订单创建成功后你用 Kafka 异步通知库存系统消息重复消费怎么办燕双非我想想……消费者那边也做幂等按业务唯一键去重。比如订单号 事件类型处理过就不再处理。第二轮缓存、权限与数据一致性面试官订单详情页访问很频繁你会怎么用 Redis 和 Spring Cache 做优化燕双非可以把订单详情缓存到 Redis热点数据直接读缓存。Spring Cache 上个注解就行比如Cacheable。面试官如果订单状态频繁变化比如待支付、已支付、已取消缓存和数据库怎么保持一致燕双非这个……可以先更新数据库再删缓存。或者延迟双删防止脏读。面试官很好知道延迟双删说明你接触过生产问题。那如果支付接口暴露在外部Spring Security 你会怎么设计认证与授权燕双非登录后发 JWT前后端分离嘛。请求进来先验签再看角色权限。敏感接口加上权限注解。面试官继续说JWT 放在什么地方比较合适如果 token 泄露了怎么办燕双非一般放在 HttpOnly Cookie 或者请求头里。泄露了就得做短有效期再配合 refresh token 和黑名单机制。面试官这轮比刚才稳不少。最后一个问题支付场景里你如何避免“重复扣款 重复发货”燕双非我会在支付回调里做幂等校验订单状态流转要有严格机流转。嗯……还可以用分布式锁不过我觉得唯一约束和状态机更重要。第三轮高并发、可观测性与云原生面试官现在活动大促商品秒杀流量暴涨。Spring Boot 服务你怎么做限流、熔断和降级燕双非可以用 Resilience4j 做熔断限流超时就快速失败热点接口返回兜底页再配合网关和本地缓存。面试官那如果库存服务本身是 gRPC 调用链路里你会关注哪些指标燕双非嗯……QPS、RT、错误率、超时率还有 JVM 的 GC、线程池队列长度。最好再打一些 trace id方便排查。面试官不错已经开始像一个线上工程师了。那 Prometheus、Grafana、Micrometer 这套你怎么串起来燕双非Micrometer 在应用里埋点暴露指标给 Prometheus 抓取Grafana 做看板。比如订单成功率、Kafka 消费堆积、接口 P99 延迟都可以看。面试官最后一个偏架构的问题。你们团队准备做一个“智能客服”来回答订单、物流、退款问题结合 Spring AI、RAG、向量数据库你会怎么落地燕双非大概就是把 FAQ、工单、规则文档做文档加载切分后向量化存到 Milvus 之类的向量数据库。用户提问后先做语义检索再把召回内容拼到提示词里交给大模型。复杂流程可以做 Agent调用订单查询、物流查询这些工具。还要注意幻觉问题不能让模型乱编。面试官说得还算完整。那如果问的是“用户订单为什么没到账”而知识库里没有直接答案你怎么避免胡说八道燕双非那就让模型明确不知道就说不知道结合检索结果和工具调用结果回答如果证据不足就转人工。不能硬答。面试官好今天先到这。你回去等通知吧。面试问题详细解析1. 电商下单链路如何保证可靠性下单、扣库存、发消息通常不是一个原子事务生产中一般采用“本地事务 可靠消息 最终一致性”的思路。订单创建成功后再发 Kafka 事件消费者根据订单号做幂等处理避免重复消费导致库存重复扣减。接口层则需要幂等控制常见方式包括Redis token、业务唯一键、数据库唯一索引、状态机校验等。2. Spring Boot 接口幂等设计幂等的核心是“同一个请求多次提交结果一致”。对于创建类接口推荐前后端协同前端带一次性 token后端校验后删除同时数据库层用唯一索引兜底。对于状态变更接口则通过订单状态机和版本号控制防止非法重复更新。3. Kafka 消息重复消费与消息可靠性Kafka 保证的是消息投递能力不保证业务侧天然幂等。消费者必须以业务主键去重必要时建立“消费日志表”或“去重表”。如果涉及支付、库存、发货等关键链路建议结合重试、死信队列、补偿任务来处理异常。4. Redis Spring Cache 缓存优化高频读接口可以用 Redis 提升吞吐。Spring Cache 适合快速接入但业务上仍要关注缓存穿透、击穿、雪崩。对于热点商品、订单详情等数据建议设置合理 TTL、空值缓存、互斥重建必要时采用本地缓存 Caffeine 作为二级缓存。5. 缓存与数据库一致性常见策略是“先更新数据库再删除缓存”必要时配合延迟双删。原因是更新缓存比删缓存更容易引入并发脏读。对于读多写少业务这种模式足够实用对强一致要求很高的场景则需要进一步结合消息通知或事务消息。6. Spring Security JWT 的认证授权设计JWT 适合前后端分离系统。登录成功后服务端签发 token请求到达时先验签再解析用户身份和权限信息。短 token refresh token 是常见组合。若 token 泄露可通过缩短有效期、黑名单、刷新令牌轮换来降低风险。授权层面可使用方法级权限注解、URL 规则、角色/资源模型进行控制。7. 支付回调幂等与防重复发货支付回调通常会被重复通知因此必须幂等。正确做法是先校验订单是否已支付再执行状态更新只有状态从“未支付”流转到“已支付”才继续发货或发消息。比起单纯加分布式锁状态机、唯一约束和业务流水号更可靠。8. Resilience4j 在高并发场景中的作用秒杀、大促场景下依赖服务容易出现级联故障。Resilience4j 可提供限流、熔断、超时、重试和舱壁隔离能力。实践中应避免“盲目重试”因为重试可能放大流量。更好的做法是快速失败、返回降级结果并在网关、应用、数据库多层设置保护。9. Micrometer Prometheus Grafana 可观测性Micrometer 负责在应用里统一埋点Prometheus 负责采集与存储指标Grafana 负责展示。电商系统里常见指标包括接口 RT、错误率、订单成功率、Kafka 堆积、线程池队列长度、JVM GC、连接池使用率等。只有把指标看清楚才能定位性能瓶颈和异常波动。10. Spring AI RAG 向量数据库落地智能客服企业文档问答通常不能直接“把所有文档塞给大模型”而是要用 RAG先做文档加载、切分、向量化再存入向量数据库如 Milvus、Chroma、Redis 向量能力。用户提问后先进行语义检索再把召回片段作为上下文交给模型生成答案。若要处理复杂工作流如查订单、查物流、查退款则可以引入 Agent 和工具调用框架让模型按标准化接口调用后端服务。11. 如何应对 AI 幻觉AI 幻觉是指模型生成看似合理但实际错误的内容。控制方式包括限制回答范围、优先依据检索结果、要求引用证据、对关键结论做工具校验、无法确认时明确拒答并转人工。企业场景里宁可保守也不要让模型“自信胡说”。结语以上就是本次互联网大厂 Java 面试实录与详细解析。希望这篇内容能帮助大家更贴近真实面试场景既能看懂问题也能理解背后的业务与技术取舍。感谢阅读愿你在求职路上稳住节奏拿到心仪 offer