Java 面试实录：Spring Boot + Kafka + Redis + Spring Security + AI 的大厂拷打现场-二趣网

Java 面试实录：Spring Boot + Kafka + Redis + Spring Security + AI 的大厂拷打现场

场景：互联网大厂 Java 求职面试

人物：严肃面试官、搞笑水货程序员燕双非

第一轮：电商增长与高并发下单

面试官：我们先从一个电商秒杀场景开始。你用 Spring Boot 做下单接口时，如何避免接口被刷爆？

燕双非：这个简单，先加限流，再加 Redis 缓存，必要时把库存提前预热到本地缓存里。Spring Boot 里我一般会配合拦截器或者网关做基础防护。

面试官：回答得还行。那如果要在高并发下保证库存不超卖，你会怎么设计？

燕双非：嗯……可以先把库存放 Redis，用原子操作扣减；数据库再异步落库。至于一致性嘛，反正最后总会对上的，大概吧。

面试官：你这个“大概”有点危险。那消息队列在这里怎么用？

燕双非：我会把下单请求先写入 Kafka，后面的订单服务异步消费。这样削峰填谷，前台先返回“抢购成功，待确认”。

面试官：可以，至少方向是对的。那你会如何处理 Kafka 消息重复消费？

燕双非：……加个唯一订单号，消费端做幂等校验。比如 Redis 记一下处理状态，或者数据库订单表加唯一索引。

第二轮：支付与风控链路

面试官：现在订单已经创建成功，进入支付环节。Spring Security 在这个场景里怎么保护支付接口？

燕双非：登录态要校验，JWT 携带用户身份，接口鉴权交给 Spring Security。支付这种敏感接口还要加二次校验，比如短信验证码或者风控令牌。

面试官：如果第三方支付回调来了，你怎么防止伪造请求？

燕双非：验签啊，检查签名、时间戳、随机串，确认是支付平台发来的。要是再严一点，可以把回调 IP 白名单也加上。

面试官：回调处理失败时，如何保证账务最终一致？

燕双非：可以用本地事务先记一条待处理流水，然后再发消息给 Kafka。消费端更新订单和账单状态，失败就重试。还可以配合 Outbox 模式，避免“数据库写成功、消息没发出去”的尴尬。

面试官：不错。那你知道 Micrometer 在支付链路里有什么价值吗？

燕双非：可以埋点统计接口耗时、成功率、异常率，再接 Prometheus 和 Grafana 看板。这样支付超时、Kafka 堆积、Redis 命中率下降都能更早发现。

面试官：这个回答比刚才靠谱。那如果风控要求实时识别异常下单，你会怎么结合 AI 能力？

燕双非：可以把用户行为、设备指纹、历史订单特征做向量化，再做语义检索或者规则增强；如果接 Spring AI 和 RAG，把风控知识库、历史案例接入，让模型辅助判断风险等级。

第三轮：企业协同与智能客服

面试官：最后一个场景，我们做企业协同 SaaS，用户会上传大量合同和工单。你会怎么设计文档问答系统？

燕双非：先文档加载，再切分文本，做 Embedding，存到向量数据库里，比如 Milvus 或 Redis。查询时做语义检索，召回相关片段，再交给大模型生成答案。

面试官：你提到了检索。那如果企业客户要求“不能胡说八道”，你怎么控制 AI 幻觉？

燕双非：要尽量走 Agentic RAG，答案必须基于检索到的企业文档；提示词里要求引用来源，召回不足就直接说“不确定”。另外可以限制工具调用范围，避免模型瞎编。

面试官：如果客服系统还要支持实时消息，你会考虑什么技术？

燕双非：可以用 WebSocket 做在线会话消息，后端再接 Kafka 异步处理工单流转。会话内存可以记录上下文，方便多轮追问。

面试官：再补一个问题：你如何把这一套系统做成可观测、可扩展的服务？

燕双非：服务层用 Spring Boot，接口层加 OpenAPI，监控用 Micrometer + Prometheus + Grafana，日志用 SLF4J 配合 Logback。容器化后上 Kubernetes，配合健康检查和弹性扩缩容。AI 服务和业务服务拆开，复杂工作流交给独立编排层。

面试官：行，今天先到这吧。你回去等通知。

题目详解

1. 如何在 Spring Boot 电商秒杀场景中防止接口被刷爆？

高并发场景下，入口保护通常分为网关层、应用层、缓存层三道防线。网关层可做 IP 限流、用户限流和黑名单拦截；应用层使用令牌桶、漏桶或滑动窗口限流；缓存层可将热点商品信息、库存、活动配置提前缓存，减少数据库压力。实际业务中，通常会结合 Nginx、Gateway 或 Sentinel 一类组件做统一治理。

2. 如何避免库存超卖？

核心思想是让“扣库存”尽可能原子化。常见方案有：Redis 原子扣减库存、数据库乐观锁扣减库存、消息队列异步下单后落库。Redis 方案适合高并发抢购，但最终仍需与数据库对账；数据库方案更稳妥但吞吐较低。生产中常采用“Redis 预扣减 + MQ 异步下单 + 数据库最终确认”的组合方案，并通过幂等键、唯一索引、状态机保证一致性。

3. Kafka 在下单链路中的作用是什么？

Kafka 的价值在于削峰填谷、异步解耦和扩展吞吐。下单请求先进入消息队列，订单服务异步消费后写库、扣减库存、发通知。这样前台接口响应更快，后端也可按消费能力平滑处理请求。需要注意消费者幂等、消息重试、死信处理和分区顺序性，避免重复下单和状态错乱。

企业官网建设流程全解析