Spring Boot+Redis+Kafka：电商高并发场景三件套的取舍逻辑与落地实践

1. 面试官真正想听的不是八股文而是你的取舍逻辑先讲一个我面试别人时遇到最多的场景候选人张口就来缓存穿透用布隆过滤器消息丢失用ACK机制但当我追问一句如果Redis本身挂了你的秒杀接口怎么办或者Kafka的Leader副本和Follower副本都断了消息到底丢没丢对面就开始语焉不详。Java大厂面试到了Spring Boot、Redis、Kafka这个组合题上考察的从来不是谁背的面试题模板更全而是你有没有在高并发场景下真实处理过问题。这也是为什么电商高并发这个限定词如此重要——它逼着你在一个具体业务语境里把三件套各自承担的职责讲清楚把数据流串起来把极端情况下哪一步会先挂、挂了以后怎么降级说透彻。1.1 电商高并发场景为什么偏偏是这三件套电商业务的高并发本质上是三种压力的叠加读压力商品详情页、首页、写压力下单、扣库存、异步处理压力订单状态流转、通知、对账。一套技术栈能不能扛住大促关键看这三种压力是否被合理分流。Spring Boot在其中的角色最轻但也最容易答偏。它不是高并发的核心武器而是你的调度中枢层——负责接收请求、串联组件、管理线程池。面试官问Spring Boot实际上是在问你知道怎么把Tomcat的线程池配置和业务特性对齐吗你知道Async的线程池默认配置在大促时会出什么问题吗这些细节比Spring Boot自动配置原理更接地气。Redis承担的是读多写少场景的挡流层以及极端并发下的原子操作层。商品数据、库存预热、用户维度限流、分布式锁基本都在Redis这一层解决。它的价值是把请求挡在数据库之外让关系型数据库只处理真正需要落盘的写操作。Kafka承担的是削峰填谷和系统解耦。等真正的大流量进来接口层只负责把请求快速写入Kafka下游消费端按自己的节奏处理。没有这一层数据库在峰值时刻就会被瞬时打满而有了消息队列你才可能在几十秒内把几百万的请求慢慢消化掉。1.2 从背答案到讲方案的关键转变我常见到两类面试回答风格。第一类人讲Redis穿透、击穿、雪崩能背出三种定义和对应方案但说不清楚击穿和穿透在生产中如何区分定位——其实杀手锏就是看key是否存在这叫理解。第二类人讲方案时永远只有加缓存、加队列、加机器这句话给不出任何一个落地细节这叫空话。大厂面试官真正想看到的是你把三件套串成一个分级防御的闭环。举个例子秒杀场景下业务请求进来先过Nginx做限流再进Spring Boot的本地Guava Cache过滤接着去Redis检查库存水分Redis扣库存成功后才把命令投递到Kafka由下游订单服务异步创建订单。在这个链路里每一层都在过滤请求每一层的失败都有明确的兜底策略。你能把这个过程讲完整讲清楚每一层宕掉时怎么办面试基本就稳了。2. Redis层缓存热点与数据一致性的深水区Redis这部分面试官翻来覆去就考三层东西缓存异常场景的处理、分布式锁的可靠性以及缓存与数据库的一致性。这三层背后其实是同一个问题——在高并发下缓存层引入之后系统出了故障或者状态不一致你能不能在第一时间兜住。2.1 缓存穿透、击穿、雪崩一字之差处理方式天差地别很多面试者能把三个名词背得滚瓜烂熟但问一句你在代码里是怎么判断击穿和穿透的就开始含糊。先说穿透。穿透指查询一个根本不存在的数据比如商品ID是-1或者被人恶意构造了一批ID缓存查不到DB也查不到每次请求都透传到DB。高并发时DB连接池瞬间被打满。主流做法是两种一是布隆过滤器前置过滤把所有商品ID预加载进布隆过滤器二是缓存空值设置较短的过期时间比如60秒防止恶意流量反复透传。更实际的做法是两者结合——入口处做参数校验非法ID直接拒绝再叠一层空值缓存。击穿不一样它是某个热点key在过期瞬间大量请求发现缓存没命中同时涌入数据库。区别在于key在缓存中原本是存在的只是正好到期。处理核心是当缓存失效时让只有一个请求去DB加载其他请求等这个请求的结果。实践中用的是互斥锁获取到锁的线程查DB回填缓存没获取到的线程sleep一小段时间后重新查缓存。另一种做法是逻辑过期——缓存里不设过期时间而是存一个逻辑过期时间戳后台异步线程负责刷新数据。两种方案各有取舍互斥锁实现简单但可能让请求产生短暂等待逻辑过期响应快但实现复杂且可能出现短暂的数据不一致。雪崩则是大面积key同时失效或者Redis节点整体宕机。前者解决办法很粗暴——过期时间加一个随机值避免同一秒内大量key集体到期后者则涉及Redis高可用架构主从、哨兵、集群。面试时我会建议候选人主动提到一个细节雪崩不只是key集体失效更怕的是Redis挂了之后所有请求直接打到DB上所以一定要有本地缓存比如Caffeine做二级兜底这样Redis短暂不可用时请求至少有一层本地缓冲。2.2 分布式锁选型Redis分布式锁的坑与Redisson的底气电商场景里用分布式锁的地方不少库存扣减、订单号生成、积分发放、优惠券领用。面试中我最常让候选人手写一个Redis分布式锁这一步能筛掉一大批只会背概念的人。最基础的版本是SET NX EX执行SET key value NX PX 30000保证加锁和设置过期时间的原子性。但光有这个还远远不够——如果业务执行时间超过了锁的过期时间怎么办锁自动释放了另一个线程拿到锁进入临界区原来的线程执行完又手动释放锁把别人的锁给删了。这是经典的生产事故。要解决这个问题需要引入看门狗机制也就是Redisson做的事加锁成功后后台起一个定时任务在锁过期前自动续期默认每10秒检查一次如果业务还在执行就把锁的过期时间续到30秒业务执行完主动释放锁同时关闭续期任务。另外删除锁时要先判断value是否是自己加的用Lua脚本保证判断删除的原子性避免删掉别人的锁。还有主从切换的坑Redis主节点刚写入锁还没同步到从节点主节点就挂了从节点顶上后锁丢失。这就引出了RedLock——向多个独立的Redis节点同时加锁超过半数成功才算获取成功。但RedLock本身也有争议它不能保证绝对安全。我见过很多架构师的取舍是业务系统默认用Redisson单节点或主从模式如果允许锁偶尔失效用看门狗就够了如果金库级别不允许失效那么干脆避免分布式锁改用数据库乐观锁或ZooKeeper实现强一致。面试时能把这个取舍讲出来比盲吹RedLock高级得多。2.3 缓存与数据库一致性缓存先更新还是先删除这个问题的标准答案很多人知道是Cache Aside模式读缓存缓存没命中就读DB然后回填缓存写请求则更新DB然后删除缓存。但面试官紧接着就会问删除缓存这一步如果失败了怎么办直接更新缓存还是删除缓存选更新缓存的问题是如果两个线程同时更新同一份数据后更新的线程可能把旧数据写回缓存导致新旧混杂。选删除缓存的问题是删除后到下一次重建缓存的窗口期内读请求会打到DB上。两种方案在高并发下各有各的坑但实践中删除缓存更常见原因是它更简单而且缓存重建成本通常可控。删除失败怎么补救生产里有几条常规链路第一条是消息队列补偿把删除缓存的操作封装成一条消息发送到Kafka消费端去删除缓存并做重试第二条是订阅MySQL的binlog通过Canal把变更事件同步出去触发缓存重建第三条是延迟双删——先删除缓存再更新DB隔几百毫秒再删一次缓存从时间上规避并发读请求把旧数据写回缓存的窗口。但说实话延迟双删也只能降低概率不能根治因为同步窗口和主从延迟没法完全消除。我在实际项目里的经验是先更新数据库然后删除缓存并在代码里对删除动作做失败重试。与其追求极端的一致性我更愿意在面试里把这句话讲出来我们保证最终一致且把这个不一致窗口控制在毫秒级别核心场景下用消息队列补偿绝不追求用复杂的分布式事务去解决缓存一致性问题因为那不是缓存该承担的事情。3. Kafka层消息队列的可靠性、顺序性与积压治理Kafka在面试里的分量一直被低估。很多人只背了高吞吐、分布式、持久化、多副本几个词但真到了电商场景消息队列的核心命题全是边界条件消息丢了怎么办、消息重复了怎么办、消息成堆积压了怎么办、同一个订单的消息顺序乱了怎么办。只有把这些问题想清楚才算是真的会用Kafka。3.1 为什么选Kafka而不是RabbitMQ吞吐量与日志语义面试里经常出现一个对比题你们为什么用Kafka不用RabbitMQ或者RocketMQ很多人的回答是Kafka吞吐量高但深度不够。Kafka高吞吐的来源一是顺序写磁盘二是分区并行三是零拷贝sendfile系统调用。它的消息模型本质上是一个可回放的日志消费者通过位移记录自己想读到哪一条因此Kafka允许消费者从任意历史位置重新读取消息这个特性让它非常适合做数据管道、日志收集、异步入库。RabbitMQ在这方面的定位则完全不同——它更像一个可靠的传输管道消息投递的语义更丰富支持多种路由模式适合处理需要灵活路由的短消息任务但对海量日志的回溯能力很弱。电商场景选Kafka还有一个重要原因下游可能会出现延迟或者故障Kafka通过持久化和多副本能保证消息不丢而且消费端可以挂起等待它天然支持削峰填谷。如果选RabbitMQ当生产速率远大于消费速率时Queue会迅速膨胀内存堆积会造成节点压力处理起来比Kafka麻烦得多。面试官想听的差别就在这——Kafka适合海量、顺序、回放、允许多消费者组独立消费的场景RabbitMQ适合灵活路由、低延迟、并发量相对适中的场景选型逻辑要跟着业务走。3.2 订单流程中的消息可靠性ack、重试与幂等消费电商订单链路中Kafka最常见的使用方式是这样的订单服务收到用户下单请求后先写业务库再发送一条创建订单的消息到Kafka支付回调、库存变更、积分发放、短信通知等模块各自订阅相关消息。这个链路里最核心的三个问题分别是生产端消息不丢、消费端消息不丢、消费端重复消息不导致脏数据。生产端不丢要靠acks参数。默认是acksall表示Leader和所有ISR内的Follower都写完才算成功这是最安全的选择。同时生产端还要开启enable.idempotencetrue让生产者具备幂等能力——即使重试也不会在分区里写入重复消息。如果连这些都做了还要注意一个容易被忽略的点max.in.flight.requests.per.connection设为5在幂等开启后可以保持高吞吐而不会乱序这一点很多人记混。消费端不丢相对更好理解消费成功后要提交位移。如果你用的是先处理业务再提交位移的模式至少保证处理失败时不提交位移消息可以被重新拉取。但真正的杀手是消费端的重复消费——比如业务处理成功位移还没来得及提交消费者就宕机重启了重启后会重新消费到那条消息导致订单重复创建。这一步的兜底方案只有一个幂等消费。不能把幂等寄托在消费端业务代码的偶然判断上要落到数据库唯一索引上。例如订单消息里带一个业务唯一标识如订单号或全局ID消费时以它为唯一键插入数据库重复插入触发冲突则直接忽略。这是我在生产里用过的最稳的方案不管Kafka重放多少次数据库层面都会挡住重复数据。3.3 消息积压了怎么办定位链路与应急方案面试官问到消息积压往往不是考你加消费者就行这种所有人都知道的操作而是看你会不会定位积压的根因。消息积压常见原因有三个消费端处理业务过慢比如消费逻辑里嵌套了远程HTTP调用接口响应慢拖垮了整个消费速度消费者数量少于分区数量导致消费能力不够单条消息处理阻塞比如某条消息的数据格式异常消费逻辑抛出异常又不做跳过处理消费者一直在死循环重试。最后一种最隐蔽我曾经遇到过消费端因为一段JSON反序列化失败消息一直进入重试队列导致后续几十万条消息全部卡死但监控数据显示消费者在消费非常容易忽略。积压的应急处置分三件事来做第一先把消费端入口的日志级别调高记录每条消息消费耗时找到是哪个Topic、哪个分区、哪类消息出了问题第二如果业务处理逻辑本身是瓶颈临时增加消费者实例数但要注意消费者数超过分区数是没有意义的一个分区同时只能被同组的一个消费者消费所以在增加消费者前要先评估分区数必要时创建临时Topic、增加分区数把积压的消息分流过去第三如果只是个别脏数据导致消费停滞直接查位移、跳过那几条问题消息先把积压的水位降下来再找数据问题。面试时我喜欢听候选人补一句积压不是只能被动处理还要主动防御——给消费端加熔断和降级给消费耗时做监控设置合理的重试次数和死信Topic把一直消费失败的消息转到死信队列里别再卡住主链路。这句话一出来面试官就知道你是真处理过线上问题的人。4. 串联全链路一个秒杀场景从接口到消息的完整落地前面都是按组件拆开讲这一节我们把它们串起来。我用一个电商秒杀场景作为主线这是大厂面试里最高频的综合性问题之一它能把Spring Boot的线程池配置、Redis的原子操作、Kafka的异步削峰一次性考全。4.1 请求漏斗从网关到应用的多级过滤设计假设你的商城要做一场秒杀200万用户同时抢1万台手机。如果把请求直接打到业务接口再查MySQL数据库会在几秒内崩溃。所以请求要一层一层被过滤。第一层是Nginx层按照用户IP和用户ID做限流比如某个IP每秒最多放行5个请求超出直接返回人多请稍后再试的静态页面。第二层是Spring Boot应用层的本地限流用Guava Cache或Caffeine做单机令牌桶每台机器每秒放行固定数量的请求。Nginx限流的粒度是入口应用限流的粒度是计算资源两层叠加可以挡住绝大部分无效流量。第三层是JVM本地缓存把秒杀商品的配置信息、活动名称、价格等静态字段预加载到本地缓存里秒杀请求进来时根本不查Redis直接读本地。这一层对读热点数据效果极好而且不占用网络开销。第四层才是Redis所有的库存数量都预热到Redis用Lua脚本完成扣库存的原子操作扣减成功才进入下一步。很多面试方案遗漏了一个细节为什么要用Lua脚本扣库存因为查询库存是否充足和扣减库存必须是原子操作如果先GET再DECR两个步骤之间会有其他线程插进来会出现超卖。用Redis的Lua脚本把这些操作封装成一个原子执行单元才可以从根上避免超卖。4.2 库存扣减的原子性方案Lua脚本与内存标记具体来说扣库存的Lua脚本大致是这样-- KEYS[1] 是库存keyARGV[1] 是本次扣减数量 local stock tonumber(redis.call(GET, KEYS[1])) if stock 0 then return -1 end if stock tonumber(ARGV[1]) then return -2 end redis.call(DECRBY, KEYS[1], ARGV[1]) return 1这个脚本的好处是判断和扣减全程在Redis服务端完成不会出现并发间隙。Spring Boot这边通过Redisson或者Lettuce的execute方法调用这个脚本返回1才视为扣减成功返回-1说明已售罄返回-2说明库存不足。这个点答出来基本就堵住了面试官对超卖问题的大部分追问。但还有一个更容易被忽略的细节库存扣减成功之后不能立即让所有请求都直接返回下单成功。因为如果200万用户同时下单下游订单服务根本写不过来数据库连接池会被瞬间打满。所以正确做法是扣减库存后快速返回给用户正在排队中同时把一条下单指令包含用户ID、商品ID、秒杀活动ID等信息发送到Kafka由下游订单服务异步创建订单。4.3 消息异步化保证最终一致性Kafka在此刻的关键作用秒杀场景里Kafka扮演的是蓄水池角色。上游Redis扣库存是毫秒级的下游订单创建是几十毫秒甚至几百毫秒级的两者速度不一致就需要消息队列在中间缓冲。发送消息时生产者要设置acksall并开启幂等保证消息不丢。消费者从Kafka拉取创建订单指令后还要做这些事先查一下订单是否已经创建幂等判断没有则创建订单、状态设为待支付接着发送一条支付超时关单的延迟消息再触发库存流水记录、购物车清理等操作。这里要特别注意消费端的重试机制一旦订单服务接到消息但处理失败消息会重新被拉取所以幂等判断再加数据库唯一索引双重兜底这是这个链路里绝对不能省的一环。总结下来秒杀场景的数据流向是这样的用户请求进入Nginx限流 → 进入Spring Boot本地限流和本地缓存 → 通过Redis Lua脚本扣减库存 → 扣减成功后写入Kafka → 订单服务异步消费创建订单 → 返回结果给用户。每一层都在做过滤和分流任何单点的故障都不会导致全链路不可用。这个方案的完整度在面试中就已经足以支撑起一场高质量的系统设计讨论了。5. 面试答题的节奏把控与踩坑复盘技术点讲清楚了最后聊聊面试本身。很多候选人不是不会而是不会表达要么一上来就急着给方案没有一个从业务场景出发的引入要么面试官步步追问时自己先慌了阵脚。这部分的经验是我面了上百个候选人之后最想分享的。5.1 面试官最爱的三个为什么在Spring Boot、Redis、Kafka这个组合题下面试官几乎总会围绕三个为什么继续深挖第一个为什么为什么Redis能扛住高并发你要答到单线程模型、IO多路复用、纯内存操作这几个层次还要区分Redis 6.0之后的多线程网络IO层面的多线程命令执行依然是单线程。如果你只说因为它是内存数据库就没答到点子上。第二个为什么为什么方案里要用Kafka而不是同步调用你要明确同步调用的末端是数据库数据库的写TPS通常是几百到几千而秒杀请求是几十万级两者数量级不匹配消息队列是唯一能在中间把速率错开的方案。如果只说为了削峰那还不够具体要补充削峰的代价是消息的消费端必须做幂等处理因为异步化引入了重复消费的可能性。第三个为什么这套链路里如果某一层挂了你的系统能不能优雅降级比如Redis集群出问题扣库存走不了Lua脚本了你怎么办合理的答案是秒杀前先做Redis的可用性体检秒杀期间Redis不可用时直接关闭秒杀入口普通浏览不受影响。再比如Kafka集群不可用了是继续发消息等恢复还是改为数据库直写订单但限流我倾向于第二个因为Kafka故障属于重大故障消息队列恢复后积压的数据可以再做对账和补偿。5.2 几类典型的翻车回答希望你不要踩第一类翻车全程在背作用、特点、优点没有任何业务上下文。比如被问Redis为什么快直接背单线程、IO多路复用却不加一句这在我们的场景里意味着它可以支撑每秒几万的读操作不会因为并发锁而性能下降。面试官完全可以自己查文档他需要的是你如何用这些特点去解决业务问题。第二类翻车讲方案时没有数字。只说用Redis做缓存却不说缓存多少数据、最大QPS大概多少、过期时间多长、命中率预期多高。真正有经验的候选人会在方案里给出量级估算哪怕估算不够精确也能反映你对系统的把控程度。第三类翻车被问到极端情况时只会说我们当时没遇到。比如问消费者重启后重复消费怎么办答我们的场景不会重复。这类回答基本判死刑。正确的姿态是承认问题存在然后讲清楚你的幂等设计或补偿方案。面试官想听的不是你从未出错而是你为可能出错做了哪些准备。5.3 给正在准备高并发面试的几点实操建议准备阶段不要光背面试题建议你在本机搭建一个最小可运行的秒杀Demo。用Spring Boot写一个接口Redis预热库存Kafka做下单消息队列跑一次JMeter压力测试看看当线程数从100升到1000时接口的RT和错误率分别是什么变化。你会发现很多理论上正确的方案实测中会暴露出新的问题比如Spring Boot默认的Tomcat最大线程数是200超过之后请求会排队排队的默认超时时间又很长这些参数在压测里都会原形毕露。另一个建议是动手维护一份自己的方案笔记把遇到过的问题和解决方案写下来。比如我当时记录了Redis删除缓存失败导致脏读这个问题的完整排查链路先看缓存命中率下降到80%再看日志发现删除缓存时Redis连接池抛了超时异常最后通过重试机制和队列补偿解决。这类记录在面试里讲出来比任何八股文都有说服力。最后我个人在面试时有一个固定的答题节奏先花10秒定义业务场景再讲整体架构然后自顶向下逐步展开细节。如果面试官中途打断追问说明他对你正在讲的部分感兴趣这是加分信号如果面试官听完你的整体方案后沉默几秒才开始问下一题说明你这一部分的表达已经很完整不用慌。高并发系统设计这件事本质上就是无数个边界条件的叠加你愿意提前多想几个如果就已经超过了大部分人。