1. 项目概述1.1 面试场景还原这不是一道“八股文”题我去年年底帮朋友做面试辅导时遇到了一个挺有意思的题目原话大概是“假设你在一个电商平台负责订单系统双十一大促期间用户下单后偶尔会出现‘重复支付’、‘库存超卖’、‘缓存击穿’这几个问题你会怎么设计”乍一看这像是三个独立的问题实际上它考察的是一个Java工程师有没有真正做过微服务架构下的高并发系统设计。单纯把“缓存穿透、击穿、雪崩”背一遍把“分布式锁”的API背一遍根本拿不到高分。面试官想要的是你“为什么选择这个方案”的思考过程以及你在真实业务场景里踩坑后总结出的取舍逻辑。这篇文章我打算从三个层面展开其一电商核心链路拆解搞清楚订单、库存、支付、商品四个微服务之间到底怎么协作其二缓存与数据库的一致性怎么做Redis用的到底是哪种粒度其三分布式锁在单体应用和微服务架构下的巨大差别以及事务消息怎么保证最终一致性。最后我会把面试中最高频的几个追问整理成一份速查思路结合我自己在项目里的实操经验尽量还原真实工作里的“决策现场”。1.2 适合谁读面试者、转岗者、正在搭微服务的同学如果你是在准备Java后端岗位的面试这篇文章可以直接当“场景题复盘笔记”来用。如果你是刚把Spring Cloud或者Dubbo架构搭起来、还没经历过大流量的开发者这篇文章会帮你补上“组件选型”和“数据一致性”这两块硬骨头。也有一些内容适合架构评审场景——比如你怎么说服同事用Redisson而不是自己写Redis分布式锁怎么说服领导用事务消息而不是直接依赖本地事务。先说结论微服务架构的核心难题不是服务拆分而是拆分之后的数据一致性、通信可靠性和性能退化三个问题。Java生态里解决这些问题的成熟方案很多但真正的难点在于“场景匹配”。网上那些“标准答案”往往只讲技术不讲师业务所以这篇文章里每一小节我都尽量给出“我碰到的真实情况”和“我当时是怎么判断的”。2. 微服务拆分与电商核心链路2.1 订单、库存、支付、商品四大服务的边界划分面试里聊微服务最简单的开场就是把电商后台拆成四个服务订单服务、库存服务、支付服务、商品服务。这看起来像是在报菜名但面试官一定会追问“你凭什么这么拆”我习惯用“业务能力 数据所有权 伸缩性需求”三个维度来解释。订单服务的核心能力是创建订单、查询订单状态、处理订单超时关闭库存服务管的是sku维度的库存预占和回滚支付服务对接第三方支付渠道负责支付单创建、回调处理、退款商品服务管商品信息、价格、上下架状态。这四个服务的核心判断依据是数据边界——订单数据归订单库管库存数据归库存库管两者绝不能用同一张表直接联查。为什么不能联查大促场景下订单表每天的写入量可能是千万级库存表的写并发集中在少数热点sku上。如果订单服务直接查询库存服务的数据库一方面破坏数据封装另一方面库存热点数据的连接数可能直接把数据库连接池打爆。所以服务拆分的第一原则是数据跟着业务走服务之间只能用接口通信绝不共享数据库。拆分成四个服务还带来了一个隐性的好处伸缩性。商品服务读多写少可以横向部署很多实例然后前置CDN和Redis缓存扛住商品详情页的流量订单服务和支付服务写多读多需要更精细的数据库分库分表策略库存服务是四个服务里最“敏感”的它既要求高吞吐的扣减又要求数据的强一致所以通常会单独引入Lua脚本加Redis原子扣减。2.2 一次用户下单的背后服务调用链全景把四个服务串起来看一次完整的用户下单调用链大概是这样的用户提交订单订单服务创建订单记录状态为“待支付”。订单服务调用库存服务尝试预占库存库存预占是为了防止“下单成功但无货可发”。库存预占成功订单服务返回“下单成功请支付”。用户调用支付服务发起支付支付服务对接第三方支付渠道。第三方支付回调支付服务支付服务更新支付单状态。支付服务通知订单服务“支付成功”订单服务把订单状态改为“已支付”。订单服务通知库存服务“正式扣减库存”库存服务把预占库存转为实际扣减。这个链路里最需要讨论的不是每一步做什么而是第2步和第7步之间如果出现故障怎么办。比如库存预占成功但用户一直不支付那这笔预占库存什么时候释放如果支付成功但通知订单服务失败订单状态卡在“待支付”但钱已经扣了用户会不会重复支付我在实际项目里常用的方案是“订单超时关闭 库存预占自动回滚”。订单服务启动一个定时任务扫描超过30分钟未支付的订单将其状态改为“已关闭”同时发送一条Mq消息给库存服务库存服务收到消息后把预占库存加回来。这里的核心点是定时任务不能直接修改库存服务的数据库而是要通过消息队列解耦否则库存服务数据库会因为高频扫描被拖垮。2.3 服务间通信选型OpenFeign和消息队列的分工服务间同步调用Java生态里主流选择仍然是OpenFeign 注册中心Nacos或Eureka。OpenFeign的好处是接口化、声明式调用方像调用本地方法一样调用远程服务。但同步调用有一个天然的缺陷**调用链上每个环节的耗时等于所有下游服务耗时之和。**如果订单服务同步调用库存服务是50ms支付回调同步调用订单服务又是50ms用户能感知的延迟就会累积。所以在我的架构里凡是“需要立即拿到结果”的调用用同步凡是“不关心即时结果、只要最终能执行”的调用用消息队列。比如库存预占必须同步因为用户需要立刻知道库存是否充足但支付成功后的“通知订单服务改状态”可以考虑异步因为订单状态即使晚几秒更新用户也能接受。这个判断标准面试时我会直接说出来“我区分同步和异步的决策依据是业务的响应时间敏感度。”3. 缓存技术选型与高并发访问策略3.1 为什么是Redis缓存层选型背后的考量电商场景下缓存选型基本没有悬念就是Redis。但面试官会追问“为什么不是Memcached”或者“为什么不用本地缓存Caffeine”。我的回答框架是这样的Redis胜在三点。第一是数据结构丰富商品信息的Hash、排行榜的ZSet、分布式锁的Setnx、布隆过滤器的位图都能直接用原生命令实现Memcached只有简单的key-value很多逻辑得搬到应用层自己写。第二是持久化能力Redis的RDB和AOF能在进程重启后恢复数据电商场景下缓存虽然允许丢但能恢复总比全量回源数据库要好。第三是高可用方案成熟主从复制加哨兵、集群模式Redis Cluster都是现成的。Caffeine这类本地缓存也不是没用。实际上我在商品详情页用了两级缓存**本地Caffeine做一级缓存过期时间60秒Redis做二级缓存过期时间10分钟最后才是数据库。**为什么要加本地缓存这一层因为商品详情页的并发可能达到每秒几十万次读如果全部打到RedisRedis的带宽和连接数会成为瓶颈。加了本地缓存之后每个应用节点只在自己的内存里查一次Redis的压力能降低一个数量级。3.2 缓存穿透、击穿、雪崩的成因与解法这三个词面试必问但如果只说概念就是八股文。我习惯把三者串成一个故事讲缓存穿透是查了一个“根本不存在的数据”。比如用户查一个已被删除的商品ID缓存和数据库都没有每次请求都直达数据库。攻击者只要伪造一批不存在的ID就能用低成本的请求把数据库打挂。解法有三个角度第一个是缓存空值——查不到数据时把“空”也缓存起来设置较短的过期时间第二个是用布隆过滤器把存在的数据ID预加载到布隆过滤器里请求进来先过布隆过滤掉大概率不存在的ID第三个是接口层的参数校验直接把非法ID拦截掉。缓存击穿是“热点的key刚好过期了”。比如某个爆款商品的缓存过期瞬间涌入大量请求全部穿透到数据库。解决方法是互斥锁重建缓存也就是大家熟知的“只允许一个线程去查数据库并重建缓存其他线程阻塞等待”。实现上可以用Redis的Setnx做分布式锁也可以用JVM内部的Lock单机场景。缓存雪崩是大面积的key在同一个时间段集中过期或者Redis整个挂了。前者靠“过期时间加随机值”解决比如缓存过期时间设置为10分钟加0到300秒的随机延迟后者靠Redis高可用架构解决主从加哨兵或者Redis Cluster。3.3 缓存预热与热点key监控大促前的必修课缓存穿透、击穿、雪崩是“出了事之后的防御”而缓存预热和热点key监控才是“提前化解风险”。缓存预热最简单的做法是写一个应用启动监听器在服务刚启动时把当天TOP500的热门商品数据从数据库加载到Redis。但是启动时全量加载有一个问题应用集群同时启动的瞬间数据库会被短时间内的高并发查询打一下。我当时的做法是错峰预热——每个节点启动后延迟随机5到10秒再执行预热而不是启动同步加载。热点key监控就更有意思了。我写过一个基于Netty的全局唯一ID生成器顺便统计了每个商品ID在Redis的访问次数当某个key的每秒访问量超过阈值时把这个key推送到一个独立的“热点key缓存池”用更长过期时间和更多副本数来缓存。这里的关键洞察是热点key的问题本质是“单点压力”解决思路是让一份数据变成多份副本。比如同一个商品的key原来存在一个Redis节点上热点识别后可以额外生成几个带后缀的副本key比如goods:1001:hot:1、goods:1001:hot:2读的时候随机选一个副本。4. 缓存与数据库一致性从CAP到最终一致4.1 缓存更新策略Cache Aside还是Write Through缓存和数据库的一致性是所有微服务面试里最容易让候选人露怯的地方。因为很多人背过“先删缓存再更新数据库”或者“先更新数据库再删缓存”但说不清楚为什么。先说结论我用的最多的是Cache Aside模式具体到写流程是“先更新数据库再删除缓存”。为什么不是“先删缓存再更新数据库”因为业务更新和缓存删除之间总有时间窗口如果先删缓存在数据库还没更新完成时另一个线程读到了旧数据并回填缓存就会导致缓存长期保存旧数据。反过来先更新数据库再删缓存虽然也存在极短的时间窗口删除缓存前有人读到旧值但概率低得多。有一个经典的对策叫“延迟双删”——更新数据库后先删一次缓存等待500毫秒再删一次。这个方案能解决大部分“并发读回旧数据”的问题但500毫秒怎么取并没有绝对标准要根据业务查询链路耗时来估算。我当时的做法是把它做成一个配置项大促前压测时动态调整。4.2 基于Binlog的最终一致性方案延迟双删在高并发极端场景下仍然可能失效。比如删除缓存失败怎么办再比如多个线程并发更新同一条数据A先更新数据库B后更新数据库但B先删缓存、A后删缓存缓存里留下的反而是旧数据。所以在真正核心的链路里我更推荐引入Binlog订阅的方式数据库的更新操作通过Canal监听Binlog解析出变化的数据再同步更新Redis。这个方案的核心优势是缓存更新完全由数据库变更驱动业务代码里不需要手动维护缓存。业务服务只管更新数据库Canal组件异步地把变更推给Redis一致性窗口通常在几百毫秒内。用Binlog方案还有一个额外的好处可以做“读己之写”优化。比如用户下单后订单列表页需要立即展示最新状态如果用Cache Aside容易出现“刚下完单但列表缓存还是旧的”。用Binlog订阅后订单状态变更会迅速同步到缓存用户刷新看到新状态的概率高得多。4.3 分布式事务的取舍2PC、TCC还是本地消息表缓存与数据库的一致性是“缓存层的一致性”而微服务架构下更棘手的还是“跨服务的数据一致性”。面试里最常见的问题是“订单服务调用库存服务扣减库存如果扣减成功但订单创建失败两边数据怎么保持一致”这个问题的标准答案可以分三个层次。第一层如果你们公司还在单体阶段或者容忍秒级延迟直接用本地消息表在订单库建一张消息表订单创建和消息写入放在同一个本地事务里后台线程把消息发送到Mq库存服务消费消息执行扣减。这个方案简单、可靠我已经在多个项目里验证过。第二层如果要更强的实时性可以考虑TCCTry-Confirm-Cancel模式Try阶段预占库存Confirm阶段确认扣减Cancel阶段回滚预占。TCC的优点是强实时、无中间状态缺点是开发成本高每个业务都要实现Try/Confirm/Cancel三个方法。第三层不要一上来就上Seata。Seata的AT模式虽然号称“零侵入”但在高并发大促场景下全局锁冲突和undo_log的写入会成为新的瓶颈。我在面试里会这么说“分布式事务的选型核心是评估业务对一致性的容忍度能接受最终一致的绝不用强一致方案因为强一致意味着性能牺牲。”5. 分布式锁从单机到微服务的进化5.1 为什么单机锁不能用了JVM锁的局限性很多Java基础不错的同学第一次接触分布式锁时都会有个困惑我直接在方法上加synchronized不就能保证库存不超卖了吗问题出在部署形态上。单体应用部署在一个Tomcat容器里时synchronized确实有效因为所有线程共享同一个Java堆。但微服务架构里订单服务往往会启动多个实例每个实例是一个独立的JVM。同一时刻两个不同实例的线程可以同时进入synchronized保护的代码块各自去扣减库存库存数据就会不准确。我对这个问题的总结是**分布式锁解决的是“多个JVM之间的互斥”它和“JVM内部线程互斥”是两个完全不同的问题。**如果面试官问“分布式锁是什么”这个回答基本能直接拿到初始分。5.2 基于Redis的分布式锁从Setnx到Redisson基于Redis实现分布式锁最原始的版本是两条命令先SETNX lock_key unique_value如果返回1表示获取锁成功业务执行完后DEL lock_key释放锁。但这个版本有三个致命缺陷。第一获取锁后如果进程崩溃锁永远不会释放需要用EXPIRE设置过期时间。所以正确的姿势是SET lock_key unique_value NX EX 30一条原子命令搞定。第二锁的过期时间不好定。业务执行超过30秒锁自动过期了另一个线程就能拿到锁两个线程同时进入临界区。Redisson的答案叫“看门狗机制”获取锁时默认过期时间是30秒但Redisson会有一个后台线程每10秒检查一次如果业务还没执行完就自动续期。第三释放锁时不能误删别人的锁。比如ThreadA的锁过期了ThreadB获取了锁此时ThreadA才执行完业务去DEL会把ThreadB的锁删掉。所以释放锁时必须校验value是不是自己的用Lua脚本保证“比较删除”的原子性。Redisson把这些细节都封装好了但面试时如果直接说“我用Redisson的RLock”面试官会继续追问底层原理。我建议你至少能手写一遍上面提到的“Setnx Lua脚本”版本的分布式锁再对比说明Redisson的优势这样才能体现出你真的理解而不是背API。5.3 锁粒度优化从“全局锁”到“分段锁”解决了“能不能加锁”还得考虑“加锁的成本”。我在面试中讲库存扣减时会主动提到锁粒度优化这是拉开区分度的地方。假设商品ID是1001库存剩下100件。如果锁的key就是lock:1001所有用户抢购这一个商品时都竞争同一把锁Redis的并发能力会被严重限制。优化方案是“分段锁”——把库存分成10段每段10件锁的key变成lock:1001:0到lock:1001:9。用户请求进入时先随机选择某一段尝试加锁扣减成功后如果该段库存为0再找下一段。这样Redis单节点的锁并发能力提高了一个数量级。分段锁的代价是编码复杂度增加而且库存字段需要拆成多个段来存储。我实际项目里只有“限量抢购”这种超热点场景才会用分段锁普通商品的库存扣减直接用Lua脚本操作Redis就够了redis.call(decrby, sku_stock, buy_count)然后判断返回值是否小于0小于0就回滚并返回库存不足。这是Redis官方推荐的原子扣减方式非极端场景下性能完全够用。6. 幂等性设计重复支付的拦截方案6.1 幂等键的设计思路业务唯一ID与幂等表电商场景里幂等性最典型的就是“重复支付”和“重复下单”。用户支付时可能点了两次支付按钮或者支付回调因为网络原因被发送了两次如果没有幂等设计就会出现“一笔订单扣了两次钱”的严重事故。我的通用做法是“业务唯一ID 幂等表”。每个业务操作在入口处生成一个全局唯一ID比如支付场景用payment_id下单场景用order_id。请求进来时先去幂等表查这个ID是否已经处理过——处理过就直接返回上次结果没处理过则继续执行并在执行成功后写入幂等表。这里有一个关键细节幂等表的插入操作必须是唯一约束靠数据库唯一索引来保证“同时请求只成功一个”。如果只用“先查询再插入”在两个请求并发到达时会同时查到“不存在”然后都去执行幂等就被破坏了。所以正确实现是创建表时对payment_id加唯一索引插入时利用数据库的主键冲突机制谁先插入成功谁就执行业务另一个直接捕获唯一约束冲突并返回。6.2 支付回调场景状态机驱动加Redis防重支付回调是幂等性设计的高发区。第三方支付平台比如微信支付、支付宝为了保证回调一定到达通常会重试好几次间隔从几秒到几分钟不等。我在支付服务里做了一个“支付状态机 Redis防重”的组合方案。支付单的状态枚举是待支付 - 支付中 - 已支付 - 已退款。每次回调进来先用Redis的SETNX pay_callback_${paymentId}拿到防重锁拿到锁的线程才有资格处理回调。从数据库加载支付单判断当前状态。如果已经是“已支付”直接返回成功不再重复处理。如果是“待支付”或“支付中”则更新状态为“已支付”同时发送Mq消息通知订单服务。为什么需要状态机因为状态机天然是幂等的——只有“待支付”和“支付中”这两个状态才允许迁移到“已支付”其他状态下直接拒绝。这样即使Redis的防重锁因为过期失效数据库的状态判断也能挡住第二次处理。6.3 消息消费者幂等重复消费的兜底方案消息队列本身有“至少一次”的投递保证也就是说消费端可能收到重复消息。比如库存服务消费“订单支付成功”的消息时如果消费者处理完业务后还没来得及提交ack消费者进程挂了消息就会重新投递消费端会再次执行扣减逻辑。兜底方案是“消费记录表 去重判重”。消息里自带一个全局唯一messageId消费端先查消费记录表如果该messageId已经存在直接ack并跳过。但这个方案同样要注意原子性查询到“未消费”后执行库存扣减然后插入消费记录这三步不能分开。我当时的做法是用本地事务把“消费记录插入”和“库存扣减”放在同一个数据库事务里哪个步骤失败都整体回滚让消息重新投递。7. 面试追问拆解高频问题与回答思路7.1 “库存超卖怎么解决”从乐观锁到Redis原子操作这个问题我会分情况回答不背一个方案。如果库存数据在MySQL并且并发量不算极端可以用乐观锁更新库存时加上版本号条件UPDATE sku_stock SET stock stock - #{buyCount}, version version 1 WHERE sku_id #{skuId} AND stock #{buyCount}。如果更新行数为0说明库存不足或者版本冲突需要重试或者提示用户。如果并发量到了极端MySQL的更新会成为热点行锁的瓶颈这时候把库存预放在Redis里用Lua脚本做原子扣减。我还会补充一个“库存分桶”的思路——把同一个sku的库存拆到多个key里分别扣减降低热点key压力。但面试官可能接着问“分桶后怎么保证不超卖总量”答案是每个桶的扣减都是原子操作并且所有桶的初始库存总和就是总库存不存在额外超卖。7.2 “缓存穿透和击穿有什么区别”一页纸讲清边界这两个概念经常被混淆我用一句人话帮读者区分穿透是在数据源层面“查无此物”击穿是在缓存层面“热点失效”。穿透意味着数据库完全没有这个数据所以对策是判断后缓存空值或布隆过滤击穿意味着数据库有数据只是缓存刚好过期了所以对策是互斥锁重建缓存。我遇到过一个面试者把两者说得完全相反还坚持自己没错。后来我建议他画一张图请求从客户端到Redis再到数据库的路径穿透是打到了数据库的“不存在查询”击穿是打到数据库的“单key回源”图上画完就清楚了。面试时如果你也能把“路径图”说出来会比单纯背概念有说服力得多。7.3 “为什么要用消息队列”不仅仅是解耦最后一个高频追问是“微服务里为什么一定要用消息队列”。常见的回答是“解耦、削峰、异步”但光说这三个词太泛了。我的回答会落到具体场景第一异步缩短响应时间。支付成功后订单服务需要更新订单状态、发短信、发站内信、更新积分如果全部同步调用链路响应时间会飙升。把短信、站内信这些不核心的操作丢给Mq支付接口只关心核心链路响应时间能缩短一半。第二流量削峰。大促开始瞬间的流量可能是平时的几十倍积分服务或短信服务每秒只能处理几千请求但订单服务每秒能接收几万请求直接把请求打到下游下游必然被打挂。用Mq把流量暂存起来让下游按自己的消费能力慢慢处理。第三跨服务数据最终一致。这个在前面已经说过本地消息表加Mq是最终一致性的标准姿势。面试时如果能说出“我在订单服务里用本地消息表库存服务消费消息扣库存”会比空谈“分布式事务”有落地感。8. 实操中的避坑与经验总结8.1 缓存一致性定时校准任务比什么都重要不管用什么方案——Cache Aside、延迟双删还是Binlog订阅都会出现缓存与数据库不一致的极端情况。所以我一直坚持一个原则必须有一个定时校准任务兜底。我给每个核心业务表都配了一个“缓存对账Job”每天凌晨跑一次扫描那些缓存中存在但数据库状态已变化的key然后强制刷新。比如商品价格发生变化后如果删除缓存失败对账Job会在第二天凌晨把错误缓存纠正过来。面试官如果问“你怎么保证缓存最终一致”除了讲Binlog把定时对账加上答案就完整了。8.2 性能压测本地验证Redis原子脚本的并发上限在项目上线前我用过一段时间的JMeter对库存扣减接口做压测。模拟300个并发用户同时抢购一个库存只有100件的商品观察超卖数量是否为零、接口平均响应时间是否在200ms以内。压测结果暴露过一个很经典的问题直接用RedisTemplate调用decrby然后把返回值判断是否小于0这个操作不是原子的——在高并发下两个线程可能都读到了扣减后的值都认为库存还有最终导致超卖。换成Lua脚本后整个过程在Redis服务端原子执行再压测就稳定多了。这个过程我在面试时也会讲因为面试官能从“你压测过、你被坑过、你换了方案”这条故事线里看出你真实的项目经验。8.3 面试答题的节奏先业务后技术先方案后细节最后分享一个面试技巧是我带过的候选人里反馈最好的一个回答场景题时不要一上来就报技术名词。比如面试官问“你怎么解决重复支付”你直接回答“用Redis分布式锁加幂等表”虽然没错但显得像是背题。更好的节奏是分三步先描述业务背景再提出候选方案最后讲方案的取舍。比如“用户付款时可能同时点了两次按钮而且支付平台回调会有重试机制所以我的核心目标是保证同一个支付单只被处理一次。我用了支付状态机加数据库唯一索引的幂等表方案状态机保证只有待支付和支付中能迁移到已支付唯一索引保证并发插入时只有一个能成功。这个方案的好处是不依赖Redis的可用性即使Redis挂了数据库也能兜底。”这段话没有堆砌任何生僻技术名词但把业务、方案、容灾设计都讲清楚了。面试官真正想看到的就是你这种“把技术装进业务”里的能力。我在实际项目里实践下来最深的体会是微服务和缓存方案没有绝对的对错只有和业务需求的匹配度。你研发的时候以为“用消息队列就行”但真正上线后你才发现消息的乱序、重复、积压每一个都是新坑。文里写的这些经验不是标准答案更像是一张“避坑地图”希望大家在面试时能用自己的话说出来而不是背我的答案。毕竟面试官要的不是一个复读机而是一个能独立解决问题的工程师。