企业官网建设流程全解析

Java 面试实战：Spring Boot + Kafka + Redis + Spring Security + RAG 的大厂求职攻防战

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

今天面试的是候选人燕双非。他自称“代码写得不多，但面试题背得很熟”。面试官神情严肃，准备从电商与 AIGC 结合的业务场景出发，逐步追问技术深度。

第一轮：电商秒杀与订单链路

面试官：我们先从一个电商秒杀场景开始。你们系统用 Spring Boot 还是传统的 Spring MVC？为什么？

燕双非：我们一般用 Spring Boot 吧，启动快，配置少，省得我到处写 XML。Spring MVC 也能做，但 Boot 更适合快速搭服务。

面试官：回答得还行。那如果秒杀活动来了 10 万并发，你会怎么设计库存扣减，避免超卖？

燕双非：嗯……先把库存放 Redis 里，先预扣减，再异步落库。还可以加消息队列，削峰填谷。数据库那边再做最终一致性。

面试官：不错，已经有架构思路了。那 Redis 预扣减失败和消息队列重复消费，怎么保证幂等？

燕双非：可以用订单号做唯一键，消费端先查一下有没有处理过。还有就是……数据库加唯一索引，重复就拦住。

面试官：可以。再往下，如果你们下单链路要做链路追踪和指标监控，Spring Boot 里会怎么接？

燕双非：我会接 Micrometer，然后打到 Prometheus，再用 Grafana 看图。至于链路追踪，可能会接 Jaeger 或 Zipkin。

面试官：很好，至少知道观测体系怎么搭。进入第二轮。

第二轮：账号安全与 AIGC 智能客服

面试官：现在业务升级了，电商平台要接一个 AIGC 智能客服，用户登录后才能问订单、退货、物流。你会怎么做认证和授权？

燕双非：我会用 Spring Security 做登录鉴权，Token 可以用 JWT。用户登录成功后带着 Token 调接口，后端校验就行。

面试官：那如果客服要访问用户订单、售后、物流多个系统的接口，怎么控制细粒度权限？

燕双非：嗯……可以按角色来，比如用户、客服、管理员。再细一点的话，接口级别加权限表达式。要是更复杂，可能接 OAuth2 或 Keycloak 统一身份中心。

面试官：方向对。现在说回 AIGC。你的智能客服如果要基于企业文档问答，怎么避免模型胡说八道？

燕双非：这个我听过，叫 RAG。先把文档切块、向量化，存到向量数据库里，比如 Milvus 或 Redis。用户提问后先做语义检索，再把相关文档喂给大模型，这样能降低幻觉。

面试官：还不错。那如果要让 AI 调用订单查询、退款申请、物流查询这些工具，你会怎么设计？

燕双非：应该是工具调用框架吧。让模型先决定要不要调用工具，然后统一把工具参数标准化。这样 AI 就不是纯聊天了，而是能干活的 Agent。

面试官：对，已经接近业务落地了。继续第三轮。

第三轮：高并发、微服务与发布治理

面试官：现在系统拆成多个微服务，订单服务、库存服务、客服服务都要独立部署。你会怎么做服务治理？

燕双非：可以用 Spring Cloud，注册中心可以是 Eureka 或者 Consul。服务间调用可以用 OpenFeign，熔断限流可以用 Resilience4j。

面试官：如果订单服务要调用库存服务，网络抖动时怎么保证用户体验？

燕双非：可以设置超时、重试、降级。比如库存服务挂了，就返回“排队中”或者“稍后重试”，别让用户一直转圈。

面试官：很好。那你们上线怎么做？

燕双非：用 Docker 打包镜像，Kubernetes 部署，配 Jenkins 或 GitHub Actions 做 CI/CD。发版前跑单测、集成测试，没问题再灰度。

面试官：最后一个问题，假设线上出现接口变慢，你怎么排查？

燕双非：先看监控告警，再查日志和链路追踪，确认是数据库慢、缓存命中低，还是下游接口超时。然后再看 JVM、线程池、连接池这些指标。

面试官：思路基本对。好，今天就先到这里，你回去等通知吧。

详细解答：面试题逐题拆解

1. 为什么电商秒杀适合 Spring Boot

Spring Boot 的核心优势是“约定优于配置”，适合快速构建独立服务。电商秒杀业务通常由多个独立模块组成，如活动服务、库存服务、订单服务、支付服务。Boot 的自动装配、内嵌容器和生态集成能力，能显著降低搭建成本。

2. 秒杀库存为什么要用 Redis 预扣减

秒杀场景下，数据库直接承受高并发写入很容易成为瓶颈，甚至导致锁竞争和超卖。Redis 作为高性能缓存，适合先做库存预扣减。常见做法是：请求进入后先校验活动状态，再在 Redis 中扣库存，成功后发送消息到 Kafka/RabbitMQ 异步创建订单，最后由数据库进行最终落库。这个过程本质是“削峰填谷 + 最终一致性”。

3. 如何保证消息队列重复消费的幂等性

消息中间件本身通常只能保证“至少一次”投递，因此消费端必须自己做幂等。常见手段包括：
- 使用业务唯一键，如订单号、退款单号；
- 数据库唯一索引兜底；
- 记录消费日志表或状态表；
- 利用 Redis setnx 做去重标识。
在订单系统里，推荐以“业务唯一键 + 数据库约束”作为最终兜底。

4. Micrometer、Prometheus、Grafana 的组合价值

Micrometer 是应用埋点和指标采集的统一门面，能把 JVM、线程池、