互联网大厂Java面试绕不开一个经典组合缓存、分布式、微服务。这几年我以候选人身份参加过不少技术面也作为面试官坐在桌子的另一侧看过上百份简历发现一个非常现实的现象能把这几个问题讲到位的候选人少之又少。大多数人的瓶颈不在知识量而在知识结构——知道一堆零散的概念却串不成一条完整的技术主线。如果把这几个话题串起来看其实是一条从单机到分布式的演进路径先是单机应用扛不住流量于是引入缓存缓存又带来一致性问题于是需要更多机制来兜底一旦应用拆分成多个服务注册、调用、熔断、分布式事务这些就全变成了微服务治理的范畴。理解这条主线比背一百个面试题更有用。下面我结合自己面试别人和被别人面试的经验把从缓存到微服务的核心考点逐个拆开讲顺便聊聊哪些地方最容易翻车。1. 面试场景背后的技术主线1.1 一条从单机到分布式的能力链路大厂面试官很少一上来就问“什么是微服务”他们更喜欢从一个具体的业务场景切入比如“假设你的接口响应很慢你怎么优化”。这个问题看上去是性能优化实际上是在考察你的第一反应是加缓存还是加机器。如果你回答加缓存下一步就会追问缓存怎么做、数据怎么保证一致、缓存失效怎么办。如果你回答加机器下一步就会追问服务怎么拆分、流量怎么分发、注册中心用什么。两条路走到底最终都会汇到缓存和微服务这套体系上。为什么会这样因为互联网业务的技术选型本质上就是在解决三个问题高性能、高可用、可扩展。缓存解决的是高性能微服务解决的是可扩展而高可用贯穿在两者之间。面试官用一个看似简单的问题开场其实是在衡量你处于这条能力链路的哪个位置。能往前多走一步你的技术深度就高一个档次。我自己的体会是面试官问缓存的时候脑子里想的绝不是“你会不会用Redis”而是“你有没有处理过高并发场景”。问微服务的时候想的也不是“你会不会写几个微服务接口”而是“你有没有真正拆过系统、踩过分布式环境下的坑”。所以准备面试不能光背书得把技术放到场景里去理解。1.2 面试官真正想验证什么很多候选人容易陷入一个误区把面试当成知识的堆砌恨不得把所有会的技术名词全倒出来。但面试官真正想验证的无非是三件事第一你是否真的理解这个技术要解决什么问题第二你在实际项目中是怎么落地的有没有自己的判断第三当方案有缺陷时你有没有备选方案和兜底手段。举个例子谈到缓存穿透有人能流畅地说出“用布隆过滤器”但再问一句“布隆过滤器误判了怎么办”就卡住了。倒不是说他不会而是他根本没想过这个问题。在真实场景中布隆过滤器只能挡住“不存在”的key误判的请求还是会穿透到数据库所以必须叠加空值缓存、限流等手段。面试官要的就是这种系统性的思考和细节把控能力。从缓存到微服务这条主线恰好能把这些能力全部暴露出来缓存考的是性能优化和数据一致性微服务考的是架构拆分和故障容错。顺着这条主线准备比零散刷题要有效得多。2. 缓存考题穿透、击穿与雪崩的差异2.1 三个名词背后是三种不同的故障场景缓存相关的面试题里穿透、击穿、雪崩是出现频率最高的三个。很多人觉得这三个概念容易混淆其实是没抓住它们的本质差异。从故障来源看穿透是“查了一个不存在的数据”击穿是“一个热点key恰好过期”雪崩是“大量key同时失效或Redis直接宕机”。三类问题从原因到解法都不一样。我的建议是用一张表把三者区分开面试时先讲场景再讲方案会显得思路非常清晰场景触发原因对数据库的影响关键特征缓存穿透查询的数据在缓存和数据库中都不存在每次请求都直达数据库大量无效查询缓存击穿一个热点key在缓存中过期瞬间高并发请求穿透到数据库单点过期缓存雪崩大量key同时过期或Redis不可用请求洪峰直接打到数据库批量失效/整体不可用这三个问题的共同点是“缓存没挡住请求”但解决思路完全不同。穿透问题的核心是“别让无效请求到达数据库”击穿的核心是“重建缓存时别让所有线程都冲进数据库”雪崩的核心是“错开失效时间保障Redis可用”。能把这三个层次分清楚面试官就知道你是真理解了而不是背了概念。2.2 缓存穿透的两种应对方案先说说缓存穿透。这个问题的场景非常典型用户频繁查询一个不存在的商品ID每次查询在Redis里都不命中请求就会打到数据库数据库里也没有这条记录于是返回空。如果这是恶意请求数据库会被打满接口直接瘫痪。第一种方案是空值缓存。既然数据不存在就把“空”这个结果本身也缓存起来设置一个较短的过期时间比如5分钟。这样同一个不存在的key再次查询时直接在Redis层返回空不会打到数据库。这个方案实现简单但有一个明显的副作用如果恶意请求的key是随机生成的就会产生大量空值缓存反而占用Redis内存。所以空值缓存必须设置过期时间同时控制key的数量。第二种方案是布隆过滤器。初始化时把所有可能存在的数据ID计算哈希后写入位数组查询前先判断这个ID是否在过滤器中。如果不在直接返回不存在根本不用查缓存和数据库。布隆过滤器的问题是它存在误判率也就是说某个ID明明不存在但过滤器可能认为它存在。这仍然会让一小部分请求穿透到数据库所以通常会把两种方案组合使用布隆过滤器做第一道拦截空值缓存做第二道兜底。我在实际项目中更推荐先上布隆过滤器因为它的内存占用非常低。一个亿级数据的位数组在合适的误差率下只需要几百MB内存而且Redis本身就支持位图操作也可以用Redisson的布隆过滤器实现。不过要注意布隆过滤器不支持删除元素如果业务上经常要删除数据ID就需要定期重建过滤器或者改用Counting Bloom Filter但那个复杂度会高不少。2.3 击穿与雪崩互斥锁、逻辑过期与高可用缓存击穿是我在面试中比较喜欢追问的一个点因为解决方案本身存在明显的取舍。热点key过期的瞬间比如某个爆款商品的详情页系统里可能同时涌进上千个请求。缓存失效后这些请求全部跑到数据库数据库瞬间压力飙升。解决击穿的核心思路是“让数据库只承受最小的重建压力”。最常见的做法是互斥锁当缓存miss时先尝试获取分布式锁只有拿到锁的线程才允许去查询数据库并回填缓存其他线程则等待一段时间后重新读取缓存。这个方案能保证同一时刻只有一个请求打到数据库代价是请求的延迟变高了而且如果Redis锁所在的节点挂掉需要额外处理锁的释放问题。另一个在电商场景里用得很多的是逻辑过期方案缓存数据里附带一个逻辑过期时间字段读取时如果发现逻辑时间已过期不是直接删除缓存而是返回旧数据同时由一个后台线程去更新缓存。这个方案的好处是请求永远不会被阻塞用户体验不受影响但代价是实现较复杂而且极端情况下会有短暂的脏数据。两者没有绝对优劣关键看你更在乎数据实时性还是接口响应时间。至于缓存雪崩解决思路要分两层来看。第一层是避免大量key同时过期最简单有效的方法是给过期时间加一个随机值比如基础过期时间1小时在此基础上加0到300秒的随机延迟这样所有key的失效时刻就不会集中在同一瞬间。第二层是保障Redis本身的高可用比如部署哨兵模式或集群模式避免单点故障导致所有缓存不可访问。面试时如果能主动提到“即使做了错峰Redis宕机时也要有降级策略”比如本地缓存兜底或限流保护数据库那基本上这个点就能拿满分。3. 缓存与数据库的一致性难题3.1 为什么会有缓存一致性问题缓存能扛住高并发但它和数据库本质上存储的是两份数据。只要读写顺序不对就会出现一份更新了、另一份还是旧数据的情况这就是缓存一致性问题。举个例子用户修改了商品价格数据库已经改成99元但缓存里还是100元其他用户看到的仍然是旧价格。这个问题在面试里几乎必问因为它在任何真实项目里都躲不掉。面试官想听的往往不是“怎么彻底解决”而是“你怎么权衡”。要理解一致性问题的根源得先看一次完整的读写操作。读请求先查缓存缓存不命中则查数据库并回填缓存写请求先更新数据库再处理缓存的更新或删除。问题就出在“更新数据库”和“更新/删除缓存”这两步之间如果它们是并发执行的就很容易产生中间态。比如线程A先更新数据库为99元线程B在这之后读到了100元的旧缓存并回填了数据库的99元缓存里就留下了一个错误的值。3.2 主流的四种缓存读写模式面试里常考的缓存读写模式有四种Cache Aside、Read/Write Through、Write Behind Caching、Read Through。它们的核心区别在于“业务代码是否直接操作缓存”。Cache Aside是大多数人日常使用的方式逻辑很清晰读缓存不命中再读数据库并回填写数据时先更新数据库然后删除缓存。这里要注意一个反直觉的点为什么不更新缓存而是删除缓存因为更新缓存需要额外的写操作而且如果多个线程并发更新缓存顺序很难控制容易产生旧值覆盖新值的问题。删除缓存则是等下一次读请求过来时再重新构建更简单也更不容易出错。Read/Write Through模式则是把缓存当成一个数据访问层业务代码只操作缓存由缓存层负责同步到数据库。这种模式的优点是业务代码简单一致性更容易控制缺点是对缓存层的能力要求高Redis本身不太适合直接做这种模式常见的落地方式是使用Caffeine等本地缓存。Write Behind Caching更进一步先更新缓存然后异步批量地把写操作合并到数据库。它能显著提升写性能但风险是如果缓存或服务宕机未落库的数据会丢所以一般只用在监控计数这类允许丢数据的场景。面试时能把这个模式的风险点说出来会显得你不是只会生搬硬套。3.3 延迟双删与binlog订阅的落地细节谈到Cache Aside面试官经常会追问一个场景先更新数据库再删缓存如果删缓存失败了怎么办。于是很多候选人会提到“延迟双删”先删除缓存再更新数据库睡眠一小段时间后再次删除缓存。这个方案看起来很优雅但实际操作中有不少坑。延迟双删的基本思想是更新数据库前先删一次缓存这样即使有线程在更新数据库期间读到旧数据库值并回填缓存也会在延迟后被第二次删除。但问题来了“睡眠一小段时间”到底该设置多久如果设置太短回填还没来得及完成就删了设置太长中间态的脏数据会持续很久。我在项目里见过有人把延迟设成500毫秒结果还是在某些极端情况下出现了脏数据。这本质上是因为延迟双删是一种“概率性”的最终一致方案它无法做到精确的强一致。现在更多团队会选择binlog订阅方案。具体流程是应用只更新数据库然后通过订阅MySQL的binlog变化来感知数据变更再异步更新缓存。用到的组件一般是Canal或者Flink CDC。这个方案的优势非常明显业务代码完全不需要关注缓存操作事务回滚的时候缓存也不会被误删因为只有binlog里真正提交的数据变更才会驱动缓存更新。而且它天然支持多表关联更新比如订单状态变更后同时清理订单和用户的缓存。binlog订阅方案也有它的代价需要额外维护一套数据同步组件引入的消息链路会增加几十毫秒的延迟还有可能因为消息重复投递导致重复更新。但在此基础上配合消息队列的去重机制能做到非常稳定的最终一致。如果项目里已经有消息中间件我个人比较推荐优先考虑这个方案它的长期可维护性比延迟双删好得多。4. 微服务架构的必修课4.1 服务拆分业务、团队与数据聊完缓存面试的节奏通常会自然地切到微服务。面试官可能会问“你们为什么要把系统拆成微服务”“拆分的依据是什么”。如果回答说“因为大家都在拆”那基本就凉了。服务拆分必须落到具体维度上哪怕是问你自己项目的假想拆分也得有逻辑依据。服务拆分通常有三个维度业务域、团队边界和数据域。业务域拆分是最自然的比如把用户、商品、订单拆成不同的服务。团队边界拆分的核心依据是康威定律也就是“组织架构决定系统架构”两个人写同一个服务必然产生大量的代码冲突和联调成本所以拆分边界常常跟着团队划分走。数据域拆分是难度最大的因为服务拆了但数据库没拆等于没拆。真正拆成微服务意味着每个服务有自己独立的数据库实例这样才能实现隔离和自治。拆分粒度也值得细说这是很多候选人容易掉进去的坑。不要为了微服务而微服务如果一个服务只有几个接口、一个月改不了几次强行拆出来只会增加调用链路和运维成本。我见过有的团队把一个用户服务拆成三四个所谓“业务微服务”结果服务间调用链长达七八跳排查问题变得非常痛苦最后又走回了合并服务的老路。面试时如果能说出“拆分的本质是权衡什么时候拆比怎么拆更重要”会显得很有实战深度。4.2 注册中心与配置中心选型服务拆分之后服务之间怎么互相找到对方这就引出了注册中心。注册中心解决的核心问题是“服务的动态发现”服务实例IP会变、数量会伸缩不能再在配置文件里写死必须让服务从注册中心动态获取可用节点。目前Java生态里常见的注册中心有Nacos、Consul、ZooKeeper和Eureka选型时主要看你对一致性模型的要求。Nacos是国内团队使用率最高的选择它同时支持CP和AP两种模式还集成了配置管理的功能省掉了再部署一套配置中心的成本。Consul在服务发现和健康检查上做得比较完善对多数据中心支持好但中文社区相对小众。ZooKeeper本身是一个分布式协调组件不是为注册中心设计的用它做服务发现可以但写性能有瓶颈节点一多就容易有压力。配置中心是另一个常被忽视的刚需。微服务数量上来后每个服务的配置如果都放在本地配置文件和启动参数里改一个公共配置就要重启一大片服务这完全不可接受。用Nacos Config或者Spring Cloud Config把配置集中管理支持动态刷新才能真正做到“改了配置不用重启”。面试时如果能主动提到配置中心和服务发现的选型关系说明你理解微服务不是“挂个网关就完事了”的玩具架构。4.3 熔断、限流与降级高可用的三个杠杆微服务架构落地之后面临的最直观问题就是“一个服务挂了会不会拖垮整个系统”。服务之间的调用是串联的下游服务的超时和异常会不断往上传递最终导致整个调用链阻塞。解决这个问题靠三个手段限流、熔断和降级。限流是控制进入系统的流量。常见的限流算法有固定窗口、滑动窗口、令牌桶和漏桶。面试时重点要能说出两个令牌桶适合应对突发流量只要桶里有令牌就可以放行漏桶则强制恒定流出速率不管进来多少请求出水的速度是固定的。在Java生态里Sentinel已经是非常主流的限流/熔断库了它支持流控规则动态配置还能持久化到Nacos比Hystrix那套配置更灵活。熔断解决的是“下游不可用时的快速失败”。当某个服务的失败率达到阈值熔断器打开后续请求直接返回降级结果不再继续调用下游避免资源被持续浪费。这个思路类似电路里的保险丝你不需要立刻修好电器但你要先切断电路保护其他电器。Hystrix开了个先河但已经停更现在实际项目里更多用Sentinel或者Spring Cloud Circuit Breaker。降级则是兜底方案。当系统压力过大或者依赖不可用时主动牺牲一些非核心功能比如取消“猜你喜欢”这类个性化推荐只返回热门商品列表保证核心交易链路还能跑通。面试时如果能给出一个具体的降级决策逻辑什么接口可以被降级、什么接口必须保活说明你有真实的架构经验而不只是背概念。5. 分布式事务与CAP权衡5.1 从CAP到BASE理解一致性边界微服务拆分后原本在一个数据库里完成的事务逻辑被拆到了多个服务、多个数据库之间这就绕不开分布式事务。我在面试中问候选人“CAP理论”时最怕听到的回答是“CAP三者不可兼得必须牺牲一个”这等于没理解。CAP理论更准确地说应该是在网络分区发生时你需要在一致性和可用性之间做一个选择而分区在分布式环境中是必然会发生的。具体到实际系统里C指的是强一致性A指的是可用性P指的是分区容错性。当网络出现分区时如果选择保证一致性CP系统就暂时不可用比如ZooKeeper在进行Leader选举时会拒绝服务如果选择保证可用性AP系统就允许暂时不一致比如Eureka的节点之间数据不同步时也能响应请求。还有一条补充原则叫BASE即基本可用、软状态、最终一致。BASE理论的意思是你不必做到强一致但系统最终会收敛到一致状态。面试时我会比较看重候选人能否把这些理论落到业务场景。比如扣减库存的操作如果并发度很高你用强一致方案成本太高那就可以容忍短暂超卖再用后续的对账机制修正。能说清楚“什么时候必须强一致、什么时候可以最终一致”说明你有实际权衡的能力。5.2 分布式事务的四种主流方案常见的分布式事务方案有四类2PC两阶段提交、TCC、SAGA和本地消息表。面试时不需要面面俱到但至少要能讲清楚其中两三种的优缺点和适用场景。2PC是最经典的强一致方案通过事务协调者分两个阶段来让所有参与者提交或回滚第一阶段是准备所有参与者执行事务但不提交返回“可以提交”第二阶段协调者根据第一阶段的响应决定全局提交或回滚。它有明显的性能问题两阶段期间所有参与者都持有锁并发能力很差而且协调者本身是单点一旦挂了整个事务卡死。现在实际业务里直接用2PC的项目不多但理解它的思想对理解后续方案有帮助。TCC是业务层面的“补偿型”分布式事务方案。它的思路是把一个事务拆成Try、Confirm、Cancel三个操作Try阶段尝试预留资源比如扣减冻结库存Confirm阶段确认执行比如真正扣减库存Cancel阶段取消执行比如释放冻结库存。TCC的优点是不用锁数据库资源性能比2PC好很多但每个业务都要实现三个接口编码成本高、侵入性强适合对一致性要求高且并发量大的场景。SAGA则更适合业务流程长、实时性要求不高的场景。它把一个长事务拆成多个本地事务每个本地事务都带一个补偿操作。比如一个订单流程涉及下单、扣库存、发积分三个步骤如果扣库存失败就依次反向执行“取消订单”“补回库存”来补偿。SAGA的编排方式有两种基于事件的编排每个服务通过消息触发下一个服务和基于状态的编排由一个协调者控制流程。缺点是它只能保证最终一致中间状态对用户是可见的。5.3 事务消息与最终一致性实践分布式事务方案里现在实际落地比较多的还是本地消息表和事务消息两者思想类似核心都是“把要发送的消息和业务操作放在同一个本地事务里保证业务操作成功消息才发出去业务操作失败消息就不发”。本地消息表的做法是在业务数据库里建一张消息表业务操作和插入消息在同一个本地事务中完成然后通过定时任务轮询消息表发送未发送的消息。这个方案实现简单但需要处理消息重复发送的问题消费端一般要做幂等。事务消息则避免了自己写定时任务的麻烦它的代表实现是RocketMQ的事务消息机制。RocketMQ事务消息的工作流程是这样的生产者先发送一条“半消息”消息到Broker此时消费者看不到这条消息生产者执行本地事务根据本地事务结果向Broker发送Commit或Rollback指令。如果本地事务执行完成后还没来得及发送指令RocketMQ会回查生产者的本地事务状态来获取最终结果。这个机制能非常好地实现“本地事务和消息发送的原子性”。这条知识在微服务面试中非常加分因为它是把分布式事务落到工业可实现层面的最好证明。推荐面试时把“事务消息的三种状态流转”和“消息重复消费时的幂等策略”一起讲出来基本上就能覆盖住这一轮的追问深度。6. 一条完整的高并发链路设计6.1 从用户点击到数据库分库的完整路径面试进行到这里如果候选人前面回答得都不错面试官通常会抛出一个综合性场景比如“设计一个商品详情页系统”。这个场景特别适合检验你对整个从缓存到微服务主线的掌握程度因为它的完整链路几乎覆盖了前面所有话题。我自己的设计思路是把它分成几层来看。第一层是CDN把图片、静态资源、JS文件全部放到CDN让用户就近访问这是最便宜也最有效的一层缓存。第二层是Nginx可以做本地缓存和负载均衡把热点页面的HTML缓存下来。第三层是网关层负责鉴权、限流、路由转发。第四层才是真正的微服务层商品服务、库存服务、评价服务各自独立部署每个服务内部还可以用Caffeine做本地缓存。最后一层是数据库按业务和数据量决定是否分库分表。从性能角度来说用户的请求到达商品服务时理想情况下根本不需要查数据库CDN命中返回静态内容Nginx命中返回热点页面Redis命中返回商品信息只有到本地缓存也没有命中时才会调用数据库查询。每一层的命中率逐级下降但数据实时性逐级上升。分层设计的关键就是让每个数据都有合适的存储位置和时效策略。6.2 热点key、缓存预热与其他细节分层设计讲完之后真正的区分度在这个细节层面。面试官大概率会追问“如果某个商品突然爆火缓存并发量很高你怎么处理”这就是热点key问题。常见的做法是先识别热点比如统计一段时间内访问量超过阈值的key然后针对这些key做本地缓存兜底把热点key的数据复制到每台机器内存里避免全部打到Redis。另一个高频细节是缓存预热。新服务上线或Redis重启后缓存是空的如果直接放流量进来全部请求都会打到数据库。所以在流量进来前先用一个预热任务把热数据批量写入Redis。我见过有的团队在凌晨低峰期做预热也有的团队用历史访问日志统计出Top N的数据进行预热。关键是要把“预热的数据范围怎么定、预热失败怎么办”提前想清楚。还有一个很多人忽略的细节是缓存key的设计。不少人喜欢用“商品ID”做key但商品维度可能涉及标题、价格、库存、评价等不同数据归属在不同服务里。一个更好的做法是按业务域拆分key比如product:basic:{id}表示基本信息product:stock:{id}表示库存信息库存服务只更新自己的key避免多个服务操作同一份缓存数据造成互相覆盖。这也体现了缓存和微服务结合时的设计意识。6.3 面试作答的节奏与深度展示针对综合场景题我建议按“整体架构→关键细节→方案权衡”的三步节奏来回答。第一步先用一两分钟画清楚整体链路不需要展开细节目的是让面试官知道你有全局观。第二步选一个最体现技术的细节往里钻比如缓存击穿的解决方案或者分布式事务的取舍过程。第三步说出这个方案的局限性和兜底手段比如“我们最终选择了缓存加数据库的最终一致性方案容忍秒级的脏数据因为扣库存操作使用了预扣款所以不会超卖”。很多候选人失败在节奏和取舍上。一是太早陷入细节整体还没说清楚就开始讲“我的拦截器怎么写的”面试官根本没法接二是只说方案的优点不说缺点一听就是背的。真实工程里每个方案都有缺陷你能清楚地承认并给出应对措施反而说明你踩过坑、有自己的判断。我自己做面试官时最欣赏的候选人不是把所有答案说完的人而是会主动说出“当时其实还有另一种方案我们之所以选这个是因为……”的人。7. 面试实战避坑心得7.1 最常见的五个反面案例这些年我看到的经典翻车案例其实很有共性在这里列一下给准备面试的朋友做个参考。第一个反面案例是只背概念不会落地。比如问“你们缓存穿透遇到过吗”回答“我们用布隆过滤器”再追问“过滤器误判率怎么配、内存占用怎么估算”一下就答不上来了。这种情况说明候选人只看了博客没做过实验面试官很难相信他真的处理过线上问题。第二个反面案例是方案没有取舍。有些候选人一说Redis挂了怎么办就回答“优化代码加缓存”好像所有问题都靠缓存解决完全忽略了Redis本身也需要高可用架构。真实项目里Redis集群、哨兵、主从切换这些基础能力才是保障代码优化解决不了单点故障。第三个反面案例是技术名词堆砌。把Sentinel、Seata、RocketMQ、Canal全说了一遍但问他“为什么选这个消息队列不选另一个”完全说不出理由。面试官需要的是你做过选型判断的证据而不是一个技术词典。第四个反面案例是忽略幂等和重复消费。提到事务消息时能说出流程但追问“消费者收到重复消息怎么办”就愣住。几乎所有异步消息场景都必须考虑幂等这是分布式系统的基础素养忘了说很容易暴露实战盲区。第五个反面案例是过度承诺。有的候选人会说自己“负责过千万并发系统”结果被问到简单的Redis数据结构底层实现时答不上来。一次撒谎带来的负面影响远比承认自己了解有限要大得多。面试官更愿意听到“这块我接触不深但我了解大致的原理平时是这样去排查的”。7.2 我个人觉得最有用的几点准备经验这个话题聊到最后还是想分享几条我自己觉得最有效的准备方法。第一把“场景题”作为练习核心。不要对着题目背答案而是试着把每个技术放到业务场景中问自己这个技术解决什么问题没有它系统会怎样选了它之后会带来什么新问题这个思考方式会逼着你把知识点串联起来而不是停留在记忆层面。第二找个周末自己画一遍架构图。不用画到什么高深程度就画一个电商系统的缓存与微服务链路请求经过哪些层、每层用什么组件、缓存策略是什么、分布式事务怎么处理。这幅图能画清楚面试中百分之六七十的架构题就都覆盖了。这是我最推荐大家做的动手练习比看十篇面经都有用。第三准备一个“踩坑故事”。面试官问到项目经验时最好有一个你真实遇到过的故障排查故事比如“因为Redis大key导致集群延迟抖动”“因为缓存和数据库不一致导致价格显示错误”。故事比任何理论都更能说明你的实战能力。如果没有真实经历也可以拿公开的大规模故障案例做深度的复盘分析重点是体现排查思路而不是搬运结论。从缓存到微服务表面上是一堆技术选型背后考验的是你“能不能把一个系统拆清楚、合得住、压不垮”的工程能力。这个能力靠背题背不出来只有在真实项目和持续复盘中才能慢慢积累。希望这篇梳理能帮你在下一次面试中说清楚每一行技术判断背后的真实考量。