说个真实感受三年前我第一次准备大厂Java面试时以为把常考题背熟就够了。直到面试官淡然地抛出那句“你们那个秒杀系统的库存扣减是怎么设计的”我才发现自己对电商秒杀、微服务架构这些高频场景的理解停留在只会背概念的层面。这篇文章就是那场面试的完整复盘从电商秒杀这个入口被面试官一路拷问到了微服务架构、分布式事务、限流熔断和线上故障处置。内容主要面向正在备战Java后端岗位的候选人也适合想系统梳理高并发知识体系的工程师参考。文章以真实问答为线索我会把面试官每一句追问背后的意图拆开讲清楚顺带给出可以直接用的方案思路。1. 面试开场从项目介绍到秒杀系统的自然引路1.1 一道看似普通的“项目自述”题绝大多数大厂Java面试第一题都不是技术八股而是“先介绍一下你最近做过的项目”。千万别小看这五分钟面试官对候选人的整体印象基本在这五分钟里定型了。我当时被问到这个问题时没有选择把项目架构从头到尾背一遍而是直接抛出了秒杀业务。我的原话大概是最近主要负责公司电商平台的秒杀系统核心链路是用户点击秒杀按钮后系统完成库存校验、订单创建、支付对接三个关键动作峰值QPS大概在几十万级别。我重点解决的是三个问题库存不超卖、热点商品缓存稳定、下单链路的数据一致性。这段话说完面试官明显来了兴致追着问了一句“那你先说库存不超卖你是怎么做的”我后来复盘发现这其实是他设计好的钩子——从简单问题开始逐步往深里挖。候选人要做的不是等被问而是主动把话题引导到自己熟悉的战场。你在自我介绍环节提到的每个技术点都有可能成为下一轮的题目所以只提真正做过的、能讲透的东西。1.2 能落地的业务口径比技术名词堆砌更值钱很多候选人在介绍项目时喜欢堆名词我们用了Spring Cloud、Redis集群、Kafka、Seata……面试官听到这些名词基本无感因为他听过的类似版本太多了。真正让他眼睛亮起来的是具体到某个场景下的某个决定。比如你说“秒杀库存扣减用了Redis Lua脚本”这只是一个方案名。但如果换成“最初库存直接更新数据库压测发现单库只能扛几千TPS后来把库存预扣前置到了Redis用Lua脚本保证扣减的原子性再通过异步消息把最终扣减结果落到DB”面试官就知道你真碰过这个问题知道瓶颈在哪、为什么这样改。这就引出了一个面试底层逻辑几乎每个问题面试官都在同时考察两个维度一是你对技术原理的理解深度二是你在真实业务里的方案取舍能力。只背第一层他会默认你只是“知道”能说出第二层他才认为你“会做”。1.3 面试官视角他到底在听什么我自己后来也多次参与技术面试站在提问方再看这个问题发现面试官心里其实有一张打分表。他听项目介绍时重点捕捉三样东西你在这个系统里的角色是什么、你做的最难的一件事是什么、这件事的复杂度是被你主动消解的还是被动接受的。如果你的项目里全是“别人搭好的框架我只是调用”那技术深度这块基本拿不到分。相反如果你能说出某个环节的优化过程哪怕最终方案并不完美只要逻辑自洽他都会顺着往深处问因为“能不能讲出一个完整的技术故事”本身就是一种能力。所以准备面试的第一步不是背题而是把你的项目故事捋顺明确主线、难点、取舍三条线。2. 第一轮拷问库存扣减的并发防线2.1 超卖是怎么产生的两条SQL的原理解剖面试官听完项目介绍后第一刀就切进了库存问题“先说说如果只用数据库超卖是怎么发生的”这里其实在考并发编程的基础。超卖的本质是多个事务读到相同的库存余额然后都认为自己可以扣减。最典型的错误写法是这样两条SQL-- 先查库存 SELECT stock FROM goods WHERE id 1001; -- 判断库存大于0执行扣减 UPDATE goods SET stock stock - 1 WHERE id 1001;看似没问题但高并发下会发生经典的中断竞争场景线程A和线程B同时查到库存为1A执行扣减后库存变0B这边因为已经在查询阶段拿到了“库存还有1”的旧读照样执行更新库存变成-1。这个问题的根因是“检查”和“更新”没有作为一个原子操作中间被其他事务插入了。2.2 数据库层方案乐观锁与悲观锁的取舍面试官紧接着问“那你在数据库层面有什么办法”通常要给出两套方案并对比。悲观锁直接用SELECT ... FOR UPDATE把行锁住让更新串行化。优点是实现简单缺点是锁等待会拖垮数据库连接池秒杀这种超高并发场景根本扛不住所以一般只在常规交易场景用。乐观锁的做法是加版本号更新时带上版本条件如果影响行数为0就说明冲突了重试或放弃。SQL可以写成UPDATE goods SET stock stock - 1, version version 1 WHERE id 1001 AND version 1;这里stock 0也可以作为更新的条件之一一并放进WHERE里。你会发现加上这个条件后这条SQL本身就保证了不超卖——数据库的行锁会让多个更新请求排队执行每个请求都会重新判断库存是否大于0。这也就是常说的“乐观锁CAS思想”。面试官要听的不是你写得出这条SQL而是你说得出它为什么能在高并发下保证正确性。2.3 流量高峰期Redis预扣库存与异步落库数据库方案再优化也有天花板因为磁盘IO和行锁竞争摆在那里。面试官见你回答到SQL层面会立刻加码“如果秒杀瞬间几十万请求打到数据库呢”这是整个秒杀问题的关键分水岭。我当时给出的方案是前置一层Redis。秒杀开始前先把商品总库存预热到Redis用户请求到达时用Lua脚本完成扣减保证原子性。脚本逻辑大致是判断库存key是否存在存在则判断当前值是否大于0大于0则执行DECR并返回1否则返回0。local stock redis.call(GET, KEYS[1]) if not stock then return -1 end if tonumber(stock) 0 then return 0 end redis.call(DECR, KEYS[1]) return 1这段脚本通过Redis的单线程模型天然避免了并发扣减的竞争问题。扣减成功的用户才允许进入下单流程而下单操作不直接更新库存表而是发一条消息给MQ由消费端异步同步Redis的最终扣减结果到数据库。这里有个特别容易忽略的点预扣库存成功后订单业务还得继续处理如果后面订单创建失败了已经扣掉的Redis库存要补偿回去。所以我会设计一个兜底机制比如订单创建超时或失败时执行INCR回补库存或者依赖延迟消息在5分钟后自动回补未支付的占位库存。2.4 追问陷阱扣减失败后的库存回补面试官又多问了一句“回补库存你考虑过并发问题吗”这是典型的追问陷阱想看看你的方案有没有闭环。库存回补出现在两个场景一个是用户下单后没支付超时释放库存一个是下单链路异常需要取消占用的库存。最简单的做法是每次回补都记录一条流水回补操作本身和执行扣减一样也要走原子操作避免在库存回补和新的扣减之间产生竞态。如果回补的量级大可以走MQ异步回补消费时做幂等防止重复回补把库存加多了。我在这里主动加了一句所有的库存操作都应该带流水号流水表记录扣减、回补、冻结、解冻的完整轨迹。这给面试官传递了一个信号——我知道库存不是一个简单的计数器而是一套需要审计和追踪的数据模型。3. 第二轮拷问缓存穿透、击穿、雪崩的连环combo3.1 穿透布隆过滤器还是缓存空值秒杀系统中热点商品数据一定会有缓存层。面试官接下来直接抛出一个组合拳“说说你遇到过缓存穿透、击穿、雪崩吗分别怎么处理”第一个是穿透指请求的数据在缓存和数据库里都不存在导致每次请求都要打到数据库。秒杀场景中如果恶意用户用不存在的商品ID刷接口流量就会直接击穿缓存压垮DB。处理方案有两个主流选择。一是缓存空值对查询结果为null的key也写一个短TTL的占位缓存比如60秒后续相同请求直接返回空。优点是实现简单缺点是最恶意的攻击者会不断生成新的不存在的key缓存空值形同虚设。二是布隆过滤器系统启动时把所有可能存在的数据ID预加载进布隆过滤器请求先过过滤器判断ID不存在就直接拦截。面试官如果追问“布隆过滤器有什么缺点”你要答得上来它存在误判率可能把不存在的ID判成存在但绝不会把存在的ID判成不存在而且它不支持删除如果要调整已存在的ID集合只能重建。实际项目我常用缓存空值兜底布隆过滤器的误判两层配合效果更好。3.2 击穿热点Key过期那一刻的加锁重建击穿和穿透一字之差含义完全不同。击穿指某个非常热点的key在过期的瞬间大量请求同时发现缓存没命中于是一起冲向数据库去重建缓存。秒杀商品就是最典型的超热点key。解决方案的核心思路是限制并发重建只让一个请求去数据库加载其他请求等待结果。最简单的是互斥锁使用SETNX或Redisson的分布式锁只有成功获取锁的线程能查库并回填缓存其他线程短暂自旋等待后重新读缓存。String lockKey lock:goods: goodsId; String lockValue UUID.randomUUID().toString(); Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, lockValue, 3, TimeUnit.SECONDS); if (locked) { try { // 查询数据库并回填缓存 } finally { // 用 Lua 脚本判断 token 是否一致后删除锁 } } else { // 自旋短暂 sleep 后重查缓存 }这里还有另一个方案值得提逻辑过期。缓存中不设置物理过期时间而是把一个过期时间字段放在value里每次读取时发现逻辑过期先返回旧数据同时异步开启一个线程重建缓存。这种方案牺牲了短暂的数据一致性但换来了极佳的并发性能特别适合秒杀这种“读多写少、允许短暂旧值”的场景。我实际项目中两种方案都用了秒杀热点用的是逻辑过期加异步重建普通商品用的是互斥锁。3.3 雪崩过期时间打散与多级缓存兜底雪崩是另一个维度的风险大量key在同一时间段内集中过期导致请求整体穿过缓存层。秒杀系统如果所有商品缓存都是同一时刻设置的2小时TTL那么同一秒到达的有效期很可能集中在同一时刻数据库就会瞬间被打爆。解决办法最基础的一条过期时间不要写死加上一个随机数比如2小时 Random(0~600秒)把过期时间打散。但这条只对“自然过期”有效如果缓存节点宕机导致大面积缓存丢失那就需要多级缓存兜底。我当时的方案是Redis之上再挡一层本地缓存比如Caffeine本地缓存只存秒杀商品这类绝对热点即使Redis不可用本地缓存还能扛住一段时间。同时本地缓存的过期时间比Redis的更短避免两端数据差异持续太久。面试到这里面试官补充了一个关键点雪崩的根源不只是缓存层还包括了依赖的下游服务。如果数据库连接池被打满所有线程阻塞服务整体假死这就是服务雪崩。所以缓存方案只是第一道防线后面还需要限流、熔断、降级来兜底。这也是后面他问微服务治理的伏笔。3.4 压轴追问缓存与数据库的一致性方案连环三问之后面试官换了个方向“你用了缓存那缓存和数据库的一致性怎么保证”这个问题在含秒杀场景的面试中出现概率极高因为它考查的不只是缓存读写还有你对一致性本质的理解。常见的错误回答是“先更新数据库再删除缓存”。面试官接下来一定会问如果删缓存失败怎么办或者更新数据库和删缓存之间恰好有请求读到了旧值怎么办比较完备的思路是延迟双删先删缓存再更新数据库隔一段极短时间后再次删除缓存。这能规避大部分并发窗口但是在极端情况下仍有短暂脏读所以核心业务不能完全依赖它。更好的做法是订阅数据库的变更日志来做异步缓存更新比如监听Binlog解析出数据变更后再刷新缓存。这样缓存刷新和业务主链路解耦不会影响交易接口的rt。在面试里讲到这里表达通常可以打个良以上但如果你能再补一句“秒杀系统中库存数据走的是Redis预扣不属于缓存同步范畴因为Redis本身就是数据源”面试官会知道你脑子里有一条清晰的系统链路。4. 第三轮拷问下单链路的数据一致性4.1 面试官为什么执着于“下单又失败”用户通过秒杀校验后进入下单环节。这里隐藏着一个大坑订单服务和库存服务、支付服务在微服务架构下分属不同的服务每个服务有自己的数据库下单成功后如果库存扣减消息没有消费成功就会出现“订单有了、库存没减”的脏数据。面试官在这一轮问的核心只有一个分布式链路里数据一致性怎么解决。他要考察的其实是两个层次。第一你知道分布式事务有哪些方案第二你能判断秒杀这种高吞吐场景适合哪一种。如果不能答出第二点前面的罗列就会显得像是死记硬背。4.2 本地消息表不会画这个图就别碰分布式事务我选择的落地方案是本地消息表加消息队列这也是面试里最容易被接受的方案因为它不依赖强一致框架概念也清晰。原理是这样的下单服务在自己的数据库里把“订单创建”和“往消息表插入一条待发送消息”放在同一个本地事务里。事务提交成功后通过一个定时任务扫描消息表把状态为pending的消息发给MQ收到MQ的ack后再把消息状态改为已发送。库存服务消费消息去扣减库存执行成功后回调更新消息状态为已消费。整个过程的关键是本地事务保证了订单和消息不会一个成一个不成消息表保证了消息不会丢失。面试时如果能顺手把这个流程画出来会明显加分。因为这张图表达的其实是“最终一致性”的核心思想不追求多个服务同时成功而是保证业务链路能最终收敛到一致状态。只要消息最终被正确消费即使中间有短暂的不一致业务也是可以接受的。4.3 Seata AT模式与TCC模式的取舍如果面试官继续加压他会问“为什么不用SeataAT模式跟你的本地消息表比有什么优劣”这就要讲到AT模式的特点了。Seata AT模式通过全局事务ID和undo_log在业务SQL执行后自动生成回滚日志由事务协调器统一控制提交或回滚。优点是对业务代码侵入小但缺点也很明显全局锁会让参与的每个资源都变得串行秒杀场景下吞吐量会严重受影响。TCC模式性能更好一些Try阶段预留资源Confirm阶段确认提交Cancel阶段回滚释放资源但需要为每个业务写三个方法开发成本和复杂度都不低。我在面试里的表达是普通交易场景且并发量可控可以用Seata AT或者TCC秒杀链路为了吞吐量我优先选本地消息表加MQ让核心链路的每个节点都保持异步化和最终一致性。这里没有绝对对错面试官看的是你的取舍有没有依据。4.4 最终一致性与幂等性的配合面试官追问了这条链路上最常见的故障“如果消息重复消费了怎么办”你只要答出“消费端幂等”五个字还不行还要说出具体做法。我在库存服务里做了库存扣减流水表以订单号作为唯一业务键扣减前先查流水是否存在存在就直接返回成功。这样即使MQ因为重试机制把同一张消息投递了多次库存也只会被扣一次。再加一层保障的话还可以把MQ消费的offset和业务流水记录的更新放进同一个本地事务里彻底避免“业务处理了但offset没提交”导致的重复执行以及“offset提交了业务没完成”导致的消息丢失。这个点答完面试官非常满意。他后来说大部分候选人都能扯到幂等但能把“本地事务与MQ消费位点绑定”说清楚的很少这类细节才是区分度和实战深度的关键。5. 第四轮拷问微服务架构的拆分逻辑与治理细节5.1 为什么拆、怎么拆按业务能力而不是按技术层从下单一致性谈完面试官很自然地转向了架构层面“你们这个秒杀系统为什么要拆成微服务直接一个单体不行吗”这个问题听起来基础但其实特别容易答偏。很多人会说“因为大厂都用微服务”这种回答会瞬间拉低印象分。我当时的回答是最初是单体应用秒杀和日常交易耦合在一个工程里一次秒杀发布要连带整个交易链路回归风险太大拆开后秒杀服务、订单服务、库存服务、支付服务可以独立发布、独立扩容秒杀的峰值流量来了只需要给秒杀链路加机器不用带动整条链路扩容。面试官又追了一句“你拆分的依据是什么”这里最佳回答是“按业务能力拆分”加DDD的边界思想。比如订单域和库存域各自有明确的业务对象和上下文边界库存域向上提供了“扣减库存”能力和“查询库存”能力订单域不需要关心库存数据是怎么存储的。这样拆分出来的服务才具有自治性而不是单纯把类搬到不同的包里。他还习惯性地问了一句“你们公司服务拆分到什么粒度”这个问题没有标准答案核心是你能说出“拆太细会带来通信开销和事务复杂度拆太粗又起不到独立伸缩的作用”的权衡。我给出的标准是一个服务至少要满足三个条件才拆——有独立的业务能力、有独立的存储边界、能够独立发布和伸缩三条缺一条就先不拆。5.2 注册中心与配置中心选型不只看名气面试官接着考了基础设施的选型“你们服务注册中心用的什么为什么不用Eureka”这里其实是在看你有没有真正理解注册中心的原理差异。返回给面试官的答案里要体现出对注册中心核心机制的掌握服务注册、服务发现、心跳续约、健康检查、故障摘除。我选型时用Nacos而不是Eureka原因不是名气而是因为Nacos同时支持注册中心和配置中心还支持服务端的主动健康探测可以把不健康的实例快速摘除相比之下Eureka的自我保护机制在极端情况下会造成请求路由到已经挂掉的实例上。配置中心方面也是一样我强调了一下配置变更的动态推送能力线上秒杀的开关、库存阈值、限流阈值都是配置项需要在不动服务的情况下秒级生效Nacos的长轮询机制刚好能实现这个诉求。面试官想听到的就是这种“选型贴合业务诉求”的答案而非背一遍功能清单。5.3 网关层从统一入口到流量管控赶赴微服务话题的收尾时面试官问“你们的流量都经过网关吗秒杀场景网关做了什么”这个问题把之前聊的限流概念和架构场景打通了。网关层我用的Spring Cloud Gateway做了三件事。第一全局路由转发登录鉴权前置到网关内层服务不再关心用户是谁第二流量管控秒杀请求先过网关层的分布式限流不是所有请求都能到达秒杀服务第三协议适配和监控埋点方便摘除异常实例。需要注意的一个点是网关本身是无状态的所以可以部署多实例水平扩容但网关里的限流策略依赖Redis存储计数器这就意味着限流模块本身要有故障降级机制不能因为Redis抖动让所有流量进不来。5.4 低耦合下的数据交界分布式事务方案复盘这一章最后面试官故意把我的答案串起来问了一个综合题“你之前说本地消息表解决订单和库存的一致性那网关限流拦截了一部分流量订单服务里又用了缓存和异步消息这一整套链路里哪些点是必须强一致的哪些允许最终一致”这道题特别考验架构全局观。我的回答是用户支付结果必须强一致否则会出现“扣了钱但订单未支付”的资损问题库存预扣通过Redis Lua保证强一致订单创建与消息表投放通过本地事务保证强一致库存异步扣减、缓存刷新、积分发放这类非资金链路全部可以接受最终一致。表达完之后你跟他讨论的是同一套系统但明显在谈系统级设计而不只是某个局部实现。6. 第五轮拷问高可用防护与线上故障处置6.1 限流的算法细节令牌桶与漏桶的差异大厂面试的固定收尾动作接近结束时会突然问“你们秒杀系统怎么限流用的什么算法”。别以为这是基础题真正的考点是“你对算法的选择和实现边界是否清楚”。我详细展开了两种算法的核心差异。令牌桶以固定速率往桶里放令牌请求需要获取到令牌才能执行桶有容量上限。优点是允许一定程度的突发流量因为桶里积攒的令牌可以被一次拿光。漏桶请求像水一样进入漏桶底部以固定速率漏出不管上游请求多么不均匀下游收到的流量永远是匀速的。优点是流量整形能力强缺点是突发流量会被直接削平。秒杀场景我选的是令牌桶因为秒杀用户前几秒确实有合法的高峰进入需要给用户快速反馈“正在排队”而不是把所有流量一律硬限死。具体实现上单机可以用Guava RateLimiter集群环境则用Redis加Lua实现分布式令牌桶。但要注意Redis实现令牌桶时令牌补充逻辑和请求获取逻辑必须在一个Lua脚本里完成否则就会出现并发重复发放令牌的问题。6.2 熔断降级的实战理解保护下游也是保护上游话题从这里自然滑到了熔断和降级。面试官的问题很直接“如果秒杀服务调用库存服务开始超时你会怎么办”我认识的很多候选人这时候只答“加超时时间”或“用Hystrix”但真正的链路思考是这样的秒杀服务在5秒内出现大量对库存服务的调用超时库存服务的线程池被打满请求排队越来越长秒杀服务本身也开始出现线程阻塞。如果不做熔断库存服务故障会顺着调用链反向传染到秒杀服务再传到网关最终整体雪崩。所以我给的方案是秒杀服务与库存服务之间设置熔断策略当错误率超过阈值比如5秒内错误率超过50%直接熔断对库存服务的调用走降级逻辑返回“系统繁忙请稍后重试”。同时在降级策略里把对库存的实时扣减切换为延迟扣减先把用户的秒杀资格锁定等库存服务恢复后再完成真正的库存扣减。这样既保护了下游也没让用户的秒杀操作完全失败。6.3 一次线上秒杀事故的完整复盘表达到这里面试官抛出了压轴题“给我讲一次你经历过的线上故障。”这道题的分量很重大到可以单独决定这场面试的级别。千万不能回答“没遇到过”因为这意味着你缺少线上经验。我讲了一个自己真实经历的故障一次秒杀活动上线后开始15秒服务正常然后突然订单服务异常激增排查发现是秒杀商品详情页的缓存失效时间设成了固定值所有实例同时回源数据库数据库连接数打满。当时的处置顺序是网关层立刻开启全局限流把入口流量砍到峰值的30%同时Redis手动删除热点key让缓存重建但因为压力还在又临时把详情页接口的降级开关打开直接返回静态模板最后定位到问题后修改过期时间为固定值加随机数并针对热点商品增加了本地缓存层。整个过程大约4分钟恢复了可用性。复盘时我总结出三条经验上线前必须压测缓存过期场景、全局限流开关要能一键生效、降级预案不是写了就完事必须每季度演练一次。面试官明显对这套“故障-处置-复盘”的完整链路表示了认可他说处理故障的能力不只是看定位速度还要看你能不能从一次故障里总结出机制层面的改进。6.4 面试官的最后试探如何设计下一版秒杀系统出人意料的是面试官最后一个问题变成了开放式设计题“如果让你重新设计这套秒杀系统你会改哪里”开放式问题的目的是看你有没有持续的反思能力而不是测试你的记忆。我的回答聚焦了三个升级点。第一引入消息队列削峰填谷用户点击秒杀按钮后直接返回“已进入抢购队列”真正下单逻辑放在MQ后异步执行让秒杀业务从同步等待变成异步处理这是应对超峰值的更优解。第二把库存扣减升级成分层策略网关层限流抵消恶意流量Redis层用令牌桶和Lua组合控制真实库存数据库层只做最终校验。第三完善可观测性体系请求链路追踪全链路贯通从网关到服务到Redis到数据库每一跳耗时和错误码都要能追溯。这样设计后的系统不再是一招打天下而是每一层各司其职。7. 面试结束后我复盘出来的三点心得7.1 面试是交流不是背诵整场面试持续的深度拷问让我最大的一个体会是大厂面试官根本不满足于“标准答案”。他期望的是你跟他处于同一语言体系里面对一个真实问题时能按“问题定义、方案对比、取舍依据、落地细节、故障预案”的顺序来输出。这本质上是一种技术交流而不是背诵八股。这也意味着你在准备时要少背“Redis为什么快”这类问题多问自己“我的项目里Redis起到了什么作用如果拿掉会怎样”。把问题挂到自己的系统架构里记忆会牢固得多表达也会自然得多。7.2 原理、实现、反思缺一不可我复盘这三个小时的面试发现每道「深度拷问」基本都遵循相同的递进逻辑先问原理让你解释为什么再问实现让你给出方案细节最后问反思让你评估当前方案的不足。比如库存扣减从“超卖原因”到“Lua脚本”再到“库存回补的竞争问题”一层层向下挖。建议在准备类似面试时把每个核心知识点都用这三层结构组织一遍。例如Redis持久化先理清RDB和AOF的实现原理再对比各自在故障恢复时的表现最后反思AOF重写对磁盘IO的影响。这套框架比单纯的记忆要立体得多也能帮你应对那些没准备过的题目。7.3 后续可以继续深挖的方向这场面试之后我又陆续补充了几个方向的积累对你应该也有参考价值。一是压测与容量评估秒杀系统上线前到底要压到多少QPS怎么根据压测结果推算机器数量二是分布式链路追踪的具体落地包括SkyWalking的接入、采样策略和告警规则三是从秒杀系统延伸到日常交易系统处理更复杂的资金一致性场景。只要肯花时间把一个高并发系统彻底磨透再去迁移到其他业务方法论是通用的。如果条件允许建议自己动手搭一个简化版的秒杀系统包含网关限流、Redis库存、MQ异步下单和分布式事务几个模块跑一轮完整的压测把每一个报错都调通一遍。你会发现面试中那些答得磕磕绊绊的细节恰恰就是搭建过程中你曾经绕过或掉进去的坑。把这些问题全部补齐后下一次走进面试现场你就有底气跟面试官聊真正有深度的话题了。