先说结论:这篇实录我整理了很久,谢飞机同学的三轮面试,表面上考的是Spring Cloud、Redis、RAG这三个技术栈,实际上每一轮都在考“原理理解 + 项目落地 + 异常排查”这条线。大厂面试官已经不满足于背八股了,他们更想知道你面对真实业务时怎么选型、怎么设计、怎么救火。
这篇文章我按面试时间线来写,把每一轮的经典问题、我的答题思路、面试官追问的方向,以及事后复盘发现的坑都摊开讲。不管你是准备跳槽的Java开发,还是刚开始搭Spring Cloud微服务、玩Redis缓存、做大模型知识库的工程同学,这三轮问题基本覆盖了后端高频考点,值得花二十分钟慢慢看。
1. 面试前的准备思路:先把三条技术线串起来
1.1 为什么大厂面试总爱“串着考”
很多人准备面试喜欢一个知识点一个知识点单独背,比如今天看Redis数据类型,明天看Spring Cloud组件,后天看RAG论文。真上了考场才发现,面试官问的问题全是交叉的:问Redis分布式锁,一定要扯到微服务集群下的线程竞争;问Spring Cloud Gateway,一定要问你限流数据存哪里;问RAG知识库,一定要问你的文档库怎么支撑高并发检索。
谢飞机前两次面试挂就挂在“单点思维”上。他后来总结了一个心得:每个技术点都要准备三层——第一层是“是什么”,第二层是“为什么这么设计”,第三层是“在我的项目里怎么用、踩过什么坑”。面试官连环追问的本质,就是顺着这三层往下钻,钻到哪一层你答不上来,哪一层就是你的天花板。
所以这篇实录里的每一道题,我都按“背景 → 原理 → 项目落地 → 坑”的方式复盘,而不是简单罗列标准答案。想直接背答案的朋友也能用,但我更建议你跟着思路走一遍,毕竟面试官一天面七八个人,他太容易分辨你是真懂还是背稿了。
1.2 硬啃八股没用,我列的复习主线
针对这个面试的标题“Spring Cloud + Redis + RAG三重奏”,我把复习内容拆成了三条主线:
- Spring Cloud线:服务注册发现(Nacos/Eureka)、OpenFeign调用、Gateway网关、熔断限流(Sentinel)、分布式事务(Seata)、配置中心。重点准备“网关怎么做集群”“Dubbo和Spring Cloud区别”“服务间调用链路怎么追踪”。
- Redis线:五种基本数据类型的底层结构、缓存穿透/击穿/雪崩的解决方案、分布式锁的演进(setnx→Redisson→Redlock)、持久化机制(RDB/AOF)、主从哨兵集群架构。重点准备“Redis分布式锁在集群下的坑”“缓存一致性怎么保证”。
- RAG线:什么是RAG、为什么大模型离线知识库离不开它、向量化全流程(文档加载→分块→Embedding→存入向量库→检索→重排→拼Prompt→LLM生成)、Agentic RAG的演进、RAG评估指标。重点准备“向量化流程怎么设计”“RAG测评怎么做”“怎么向面试官讲清楚一个RAG项目”。
这三条线不是平行的。Spring Cloud解决的是系统的骨架问题(微服务怎么组织),Redis解决的是系统的速度问题(数据怎么加速),RAG解决的是系统的智能化问题(知识怎么被大模型用起来)。面试官只要看到你能把这三点串成一个完整项目,这一轮基本就稳了。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 第一轮面试:Spring Cloud微服务治理的连环追问
2.1 开场先摸底:服务拆分与调用链怎么答才算稳
谢飞机第一轮遇到的第一个问题是:“你负责的系统是怎么做微服务拆分的?拆分依据是什么?”
这个问题看着简单,但特别容易答崩。很多人上来就说“按功能拆,用户服务、订单服务、商品服务”,这种答案面试官一天听十遍,毫无记忆点。谢飞机这次学聪明了,他从业务边界和数据域两个角度答:
- 业务边界:不是所有功能都能拆成独立服务。拆分的核心标准是看“这个业务有没有独立的生命周期、独立的团队维护、独立的扩展需求”。比如用户体系和订单体系边界清晰,可以拆;但一个促销计算逻辑如果到处被调用,硬拆出去只会增加网络开销,不如先留在原来的服务里。
- 数据域:每个微服务必须独占自己的数据库或数据表,绝对不能多个服务共享同一张表。否则你拆了服务,数据还是耦合的,事务和锁的问题反而更复杂。
- 拆分后的治理:注册中心选Nacos,主要是因为阿里生态和Spring Cloud Alibaba集成度高;服务间调用用OpenFeign+Ribbon负载均衡;链路追踪用Sleuth+Zipkin,后面升级到Micrometer Tracing。
这里有个细节值得写一下:面试官追问了“服务拆太细怎么办”。谢飞机答了“服务网关可以聚合接口”,然后顺势把Spring Cloud Gateway引了出来,这个衔接非常自然,面试官也点头了。所以第一轮的开局,重点不是背定义,而是让面试官看到你有自己的拆分方法论。
2.2 网关集群是关键:Spring Cloud Gateway到底能不能做集群
这个问题是热搜词里直击要害的一个:“spring cloud gateway 能做集群吗”。很多人的第一反应是“能,部署多个实例就行”,但这个答案只对了三分之一。
谢飞机这轮的完整回答思路是:
- 网关本身是无状态的,所以天然支持多实例部署。你只要在前面挂一个负载均衡器(Nginx/LVS),或者直接用云平台的SLB,把流量分发到多个Gateway节点,这就是最简单的集群。
- 集群以后真正麻烦的是“会话保持”和“限流状态共享”。WebFlux风格的Gateway如果开启了WebSocket长连接,需要配置基于IP的粘滞会话;限流如果用本地Guava的RateLimiter,每个
