企业官网建设流程全解析

Java 面试实战：Spring Boot + Kafka + Redis + Spring Security + RAG，大厂场景下的燕双非闯关记

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

角色：严肃面试官 vs 搞笑水货程序员燕双非

第一轮：电商大促与订单链路

面试官：我们先从一个电商大促场景开始。假设你负责订单服务，技术栈是 Spring Boot + MyBatis + Redis + Kafka。下单接口如何保证高并发下不超卖？

燕双非：这个我熟。先把库存放 Redis 里，用户下单先扣 Redis，再发 Kafka 异步落库。只要 Redis 扣成功，就说明库存没问题，数据库慢一点没关系。

面试官：思路方向对，但还不够严谨。那如果 Kafka 消息重复、消费者重试、以及 Redis 和数据库最终一致性怎么处理？

燕双非：嗯……可以给消息加个唯一 ID，消费者做幂等。然后数据库那边也加个状态字段，嗯，反正重复了就忽略。至于一致性嘛，靠补偿任务兜底。

面试官：可以，至少你提到了幂等和补偿。那你说说 Spring Boot 里怎么做接口限流和降级？如果大促流量打满了怎么办？

燕双非：可以用网关限流，比如令牌桶。服务内部再配合 Resilience4j 做熔断降级，实在不行就返回“活动火爆，请稍后再试”。

面试官：回答得还行，至少知道保命策略。那你再说下 Redis 选什么数据结构更适合库存预扣？

燕双非：一般用 String 或者 Hash 吧，String 简单，Hash 看起来很专业……我两个都能用。

面试官：嗯，先到这儿，继续往下看业务链路。

第二轮：支付风控与安全认证

面试官：订单创建后进入支付环节。现在要求你设计一套支付回调与风控系统，涉及 Spring Security、JWT、OAuth2、MyBatis、MySQL、Redis。如何防止伪造回调？

燕双非：回调接口加签名校验嘛，支付平台发来的参数要验签。再加个时间戳和随机串，防止别人抓包重放。

面试官：很好，这块比较基础。那用户登录态你会选 JWT 还是 Session？为什么？

燕双非：大厂嘛，肯定 JWT 更潮。无状态，适合分布式，前后端分离也方便。就是……嗯……退出登录时可能需要黑名单，不然 token 还在有效期内。

面试官：不错，知道优缺点。那如果你的系统要对接第三方商户，OAuth2 的授权码模式和客户端模式分别适合什么场景？

燕双非：授权码模式适合用户自己授权第三方应用访问资源，客户端模式适合服务之间机器对机器调用。前者有用户参与，后者没有。

面试官：这题答得还算清晰。再说个复杂点的：风控系统需要接入规则引擎和机器学习评分，如何保证高性能查询？

燕双非：可以把常用规则结果缓存到 Redis，命中后直接返回。复杂模型结果异步计算，先给一个基础分。然后……再配一个消息队列做刷新？

面试官：方向可以，核心是分层决策、热数据缓存、异步化与可解释性。最后一个问题，Spring Security 里你如何做权限模型设计？

燕双非：我会做 RBAC，用户、角色、权限三层。接口上用注解控制，比如 @PreAuthorize。菜单和按钮权限也分开管理。

面试官：嗯，至少不是“全都放开”。

第三轮：AI 客服与云原生演进

面试官：最后一个场景。我们要做一个电商 AI 客服，支持自然语言语义搜索、企业文档问答、复杂工作流和工具调用。技术栈里有 Spring AI、RAG、MCP、向量数据库、Embedding 模型、Agentic RAG、WebSocket、Kubernetes。你怎么设计？

燕双非：先把商品文档、FAQ、售后政策做文档加载，然后切分、向量化，存到 Milvus 或 Redis 向量库。用户提问时先做语义检索，再把召回内容喂给大模型生成答案。这个就是 RAG。

面试官：不错，已经说到了检索增强生成。那如果用户问的是“我这个订单为什么不能退款”，而不是普通知识问答，你怎么让 AI 真正调用业务系统？

燕双非：这就要用工具调用。通过 MCP 或统一工具接口，把查订单、查物流、查退款状态这些能力标准化成工具。Agent 先判断要不要调用工具，再决定是直接回答还是走业务流程。

面试官：很好。那 AI 幻觉怎么控制？客服场景里乱编答案可是事故。

燕双非：嗯……一是检索不到就明确说“不确定”；二是加提示词约束，只能基于知识库回答；三是对高风险问题转人工。还可以加答案引用和置信度阈值。

面试官：可以。最后说说如果这个客服系统要上云原生，Spring Boot 服务如何部署到 Kubernetes，并支持灰度发布和扩缩容？

燕双非：先 Docker 打包，再上 K8s，配 Deployment、Service、Ingress。通过 HPA 根据 CPU 或 QPS 自动扩缩容。灰度发布可以用不同版本标签或者网关路由。

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

问题详解与知识点总结

1. 电商大促：高并发下单与库存一致性

在电商抢购场景中，核心目标是快速响应、避免超卖、保证最终一致性。常见做法是：

• 使用 Redis 做库存预扣，减少数据库压力。
• 下单成功后发送 Kafka 消息异步落库，削峰填谷。
• 消费者侧必须实现幂等，例如使用业务唯一 ID、去重表、状态机。
• 当 Redis 与数据库出现偏差时，通过补偿任务、对账任务修复。
• 接口限流可在网关或服务层完成，熔断降级由 Resilience4j 等工具实现。

业务上要明确：Redis 预扣并不等于最终成交，必须有订单状态流转来兜底。

2