聊到互联网大厂面试特别是到了二面这个环节面试官基本不会再让你背概念八股而是直接拿一个真实的高压场景来试探你的系统设计功底。我身边一个朋友去阿里二面面试官问的就是这么一道经典题千万级并发秒杀抢卷热点Key已经打到了Redis和数据库上怎么优化性能这题表面上是问缓存和数据库实际上考的是你有没有真正在流量洪峰下踩过坑对热点Key的发现、拆解、兜底有没有一套完整的治理思路。今天我不聊虚的就把这套我在实战里反复用过、也被面试官反复追问过的方案完整讲一遍从原理到代码到避坑一次性说透。1. 先把问题看清楚热点Key是怎么形成的破坏力有多大1.1 热点Key的典型形成过程秒杀抢卷的场景里热点Key几乎是活动一开闸就必然出现的东西。比如平台放出一张限量优惠券券的编号、库存余量、抢购状态这些数据都存在Redis里Key大概长这样coupon:10001:stock、coupon:10001:detail。活动开始那一秒几万个实例上的请求全部涌向同一个Key读详情的、查库存的、扣减的全都集中在这一两个Key上。数据库侧同样存在一个热点行——库存表里那行coupon_id10001的记录所有事务都要去更新它行锁竞争瞬间拉满。我习惯把热点Key的判定标准说清楚单一Key的访问量在短时间内远超集群平均值。比如平时单个Key QPS只有几百活动开始以后一个Key冲到几十万甚至上百万Redis单实例单线程的处理能力就到极限了。注意判断热点不能只看绝对值要看它相对整体基线的偏离程度一个每秒1万QPS的Key在一个每秒百万级总流量的集群里可能不算热点但放到一个小集群里就是毁灭性的。1.2 一个热点Key引发的连锁故障很多人以为热点Key就是Redis慢一点、CPU高一点实际上它一旦倒下去会带崩整个系统。Redis是单线程模型一个热点Key的密集访问会把主线程占满导致同一个实例上其他Key的正常读写也全部排队变慢这是“一个人堵路、整条街瘫痪”的典型场景。接着缓存层扛不住就会出现击穿原本在缓存里的数据突然失效请求直穿数据库。数据库那边库存行被大量事务排队锁住行锁等待时间越拖越长连接池被占满新的请求进不来最后整条链路雪崩用户看到的就是无限转圈、下单失败。这里我总结了一条故障传递链做优化之前一定要先背下来热点Key → Redis实例CPU打满 → 其他Key读写变慢 → 热点数据过期导致缓存击穿 → 数据库热点行锁竞争 → 连接池耗尽 → 服务不可用理解了这条链再看后面所有优化方案你就知道每一招到底是在打断链条的哪个环节。2. 面试官真正想考察的三个层次别只盯着Redis这种二面题大多数候选人能说出“加本地缓存”“做热点Key散列”“数据库分库分表”这类点但面试官真正想看的是你有没有系统性的分析框架。我把这道题拆成三个层次每一层都有对应的考察点你能答到第几层基本就决定了这场面试的走向。2.1 第一层能不能先发现热点方案再多第一步永远是识别。流量还没上来的时候你怎么知道哪个Key会成为热点活动运营一般能提前给出预期热点比如某个爆款SKU、某张限量券这是人工预判靠的是运营经验。但更可靠的是线上实时统计在客户端访问Redis前后埋点用一个滑动窗口计数器记录每个Key的访问频率超过阈值的自动上报。集群代理层也可以做全局统计比如自建环境里的Proxy日志分析、云上Redis自带的热点Key监控都能告诉你热点在哪。很多候选人一上来就讲解决方案忽略了“发现”这一步面试官会追问“你怎么知道是哪个Key热”答不上来就会显得方案是背的。这一层考的是你对可观测性的理解先有监控再有治理。2.2 第二层有没有一套分层防御体系识别出热点之后正解不是把所有流量都压在Redis上而是让流量在到达Redis之前就被逐层消化。完整的防御链路是CDN和页面静态化挡掉大部分静态请求 → 网关限流挡住无意义的重复请求 → 应用层本地缓存拦住热点读 → Redis承担被削减后的读写 → 数据库只接收异步批量写。每一层都在做“减量”到了数据库这一层真正落库的请求可能连总流量的百分之一都不到。能把这个分层链路讲清楚就说明你有过真实的高并发设计经验而不是零散地背了一堆优化名词。我特别强调一下分层思维很多人觉得热点Key是Redis的问题于是把所有招都用在Redis上这是典型的头痛医头。真正扛过流量的人都明白热点要在它还没到达瓶颈层之前就被拆掉。2.3 第三层能不能兜住最终一致性秒杀类业务最大的难点不是“扛住高并发”而是“高并发之下数据还不能错”。Redis扣库存是高性能的但Redis不是事务数据的最终存储。如果Redis扣减成功而数据库落库失败或者用户抢到券但订单没生成那就是实打实的资金和权益问题。所以完整方案里必须有异步队列落库、幂等控制、对账补偿这几样东西。面试官追问“缓存和数据库不一致怎么办”的时候就是在考这一层。能答出“预扣异步落库对账补偿”的闭环基本就过了因为这说明你不只考虑了性能还考虑了数据正确性和系统可维护性这正是大厂二面想筛出来的能力。3. Redis侧的四板斧把热点Key从性能瓶颈变成普通KeyRedis侧的优化我总结成四板斧按流量到达的顺序排列本地缓存挡读、实时识别预热、热点散列摊压力、连接池调优固基础。四招配合着用一个热点Key基本就不再是瓶颈了。3.1 第一板斧JVM本地缓存把第一波读流量拦在应用层热点场景里读多写少。写是扣减库存读是查券详情、抢购状态。对于读数据最简单有效的手段是在应用进程里加一层Caffeine本地缓存。JVM缓存和Redis最大的区别是它不经过网络单次读取是纳秒级别而且每个应用实例都有自己的一份相当于把热点读流量按实例数做了天然拆分。我有一次把热点详情接口的本地缓存加上之后Redis侧对应Key的QPS直接从80万掉到了不到10万效果立竿见影。我常用的配置是maximumSize设成10000左右expireAfterWrite设2到3秒。注意秒杀场景下本地缓存的时间不能设太长因为库存、抢购状态这类数据变化极快本地缓存时间过长会让用户看到“还有库存”实际却抢不到引发大量无效提交。代码大致是这样CacheString, CouponDetail localCache Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(Duration.ofSeconds(2)) .build(); CouponDetail detail localCache.get(coupon:10001:detail, key - { // 回源到Redis加载 return loadFromRedis(key); });这里有个细节很多人忽略本地缓存只解决“读”绝不碰“写”。库存扣减必须走Redis的原子操作不能用本地缓存里的值直接做减法再写回否则并发下一定会超卖。这个原则我在代码评审里反复强调所有把本地缓存当写缓存的方案到线上就是事故。3.2 第二板斧热点Key的实时识别与动态预热人工预判能覆盖活动主推的商品和券但用户行为经常出人意料可能某个隐藏款突然爆单运营根本想不到。所以我都会在客户端的Redis访问组件里做一个简单的热点统计器用ConcurrentHashMap加AtomicLong记录每个Key在每一秒内的访问次数定时任务每秒扫描一次访问频率超过阈值比如5000次/秒的Key就上报到监控和配置中心同时触发本地缓存预热。核心伪代码思路是这样// 每次访问Key时计数 ConcurrentHashMapString, AtomicLong counterMap new ConcurrentHashMap(); // 定时任务每1秒执行一次 void reportHotKeys() { counterMap.forEach((key, counter) - { long count counter.getAndSet(0); if (count HOT_THRESHOLD) { notifyCenter(key, count); } }); }识别到热点Key之后干什么动态把它的详情数据提前加载到各实例的本地缓存里让流量还没打到Redis之前就被消化掉。这个“预热”动作要配合配置中心做比如Nacos或Apollo里配一个热点Key清单应用监听配置变更实时更新本地缓存。实测下来这个机制能把热点Key在Redis侧的QPS降低一个数量级以上而且它是自动化运转的不需要人工盯着监控去加缓存。3.3 第三板斧热点Key散列把单Key压力分摊到多Key本地缓存拦掉了大部分读流量但扣减库存这类写请求还是要打到Redis。一个Key再快单实例单线程下每秒能处理的也就十万级千万级并发根本不可能由一个Key扛下来。这时候就要做热点Key散列业内也管这叫“热点副本”。做法很简单把原来的Key拆成N个带随机后缀的子Key。比如coupon:10001:stock原本是1个Key拆成coupon:10001:stock:0到coupon:10001:stock:9一共10个Key分别存一部分库存。请求进来时随机选一个子Key做扣减Redis侧的压力就均匀分摊到了10个Key上。如果用的是Redis Cluster还可以借助集群的槽位分配把这些子Key分散到不同分片单个实例的压力就变成了整集群分担。散列方案在RedisCluster下有个特殊问题RedisCluster按CRC16对Key做哈希分片同一业务的其他关联Key如果分散到不同节点跨节点操作就会失败。所以散列后的子Key命名要注意要么只处理单个Key的原子操作要么用{hashTag}把相关Key固定到同一分片。库存扣减这种单Key操作不受影响但如果你后面还要用mget批量查就要格外小心别因为散列把批量操作搞出问题。3.4 第四板斧客户端连接池与Redis端参数的细节调优热点Key优化不止在Key层面连接管理同样重要。很多高并发场景Redis没被打垮客户端连接池先崩了。我的实践经验是连接池参数不能盲目调大过大只会让Redis维护更多空闲连接反而增加内存和CPU开销。以Jedis为例比较合理的配置是maxTotal根据应用实例的并发线程数来定一般是50到200maxIdle和minIdle保持在10到20连接超时设200ms以内读取超时设500ms到1s。关键一点是testOnBorrow在性能敏感场景下要设false每借一次连接都做一次PING验证在高并发下就是巨大的额外开销。如果用Lettuce它是线程安全的共享连接模型不需要像Jedis那样开大量连接高并发下是更优的选择Spring Boot默认用的就是它。4. 数据库侧的保命措施连接池、库存扣减与热点行拆分Redis扛住了大头数据库这边的压力主要来自写路径库存扣减和订单落库。这一层处理不好前面缓存优化做得再好也会被拖垮。我重点讲三个必须落地的点全都是真实项目里验证过的。4.1 连接池参数先搞清楚你数据库的真实承载能力数据库连接池最忌讳拍脑袋调参。以HikariCP为例maximumPoolSize的计算业界有一个常用参考思路核心数乘以2加上磁盘数比如8核16G的实例推荐连接数是16到20。很多人的误区是以为连接数越大越好实际数据库的并发能力受CPU和IO限制连接数超过承载上限后大量连接在争抢数据库资源每个请求的响应时间反而上升吞吐量不升反降。我维护过的系统里一个4核8G的MySQL实例承接的峰值写入TPS是有限的。合理的HikariCP配置参考如下maximumPoolSize204核8G的库保守值minimumIdle10connectionTimeout30000msidleTimeout600000msmaxLifetime1800000msleakDetectionThreshold60000ms这里说一个我踩过的坑maxLifetime一定要小于数据库wait_timeout否则连接被数据库端回收后连接池里的连接还认为自己活着下一次请求会拿到一个失效连接报奇怪的通信异常。把wait_timeout设成8小时maxLifetime设成30分钟给连接池留下足够的提前回收时间。这个细节我在不止一个项目里遇到过排查起来很费劲因为报错信息根本不指向问题根源。4.2 库存扣减从数据库行锁迁移到Redis原子减秒杀的核心写操作是扣库存。最粗的方案是直接发SQLUPDATE stock SET stock stock - 1 WHERE coupon_id ? AND stock 0。这个方案在低并发下没问题但千万级并发场景下所有事务都去更新同一行行锁竞争会让数据库的TPS断崖式下跌连接池迅速占满。所以实践中我会把库存扣减前置到Redis用Lua脚本保证原子性local stock tonumber(redis.call(get, KEYS[1])) if stock nil then return -1 end if stock 0 then redis.call(decr, KEYS[1]) return 1 end return 0Redis扣减成功返回1才允许用户进入下单流程扣减失败直接返回“已抢完”。但注意这只是“预扣”真正的数据落库要异步做。我的做法是Redis扣减成功后把一个扣减消息发给消息队列下游消费者拿到消息后批量更新数据库一次事务处理一批把数据库的写次数降低一个量级以上。这个方案里有一个必须处理的边界Redis如果宕机或者扣减之后消息丢失库存账就会和数据库对不上。因此要加一个对账任务定期拿Redis的库存快照和数据库实际库存做比对发现差异按数据库为准进行修正。对账的频率不用太高活动结束后做全量对账活动中每小时做一次抽样对账就够了。很多人在面试里只讲预扣和异步落库不提对账补偿这就是方案完整性上的一个明显缺口。4.3 热点行拆分让数据库的行锁竞争变成分散竞争就算写数据库的次数已经被异步消息大幅削减热门券的库存行仍然是数据库里的热点行。数据库对单行的修改是串行化的无论前面接了多少层缓冲这一行始终是物理瓶颈。所以对超高热的库存数据我会在数据库层也做拆分。方案一是分段库存把总库存划分成多段每一段对应一个独立的行比如coupon_id10001的库存分成100段每段10件用户扣减时先随机选段再对该段所在行执行UPDATE。注意力分布到100行上行锁的竞争就摊薄了。方案二是在极端情况下直接把库存表按优惠券维度分表比如用券ID哈希分到10张表每张表只承载一部分券的库存热点天然被物理隔离。这里提醒一句分段库存带来的副作用是库存汇总变复杂查询总余量需要SUM聚合。秒杀场景下余量展示是弱一致性的用户看到“还有货”但点进去抢不到是正常的不用为了展示精确把聚合逻辑搞得太重。聚合可以用Redis维护一个总库存数各分段扣减后再异步累加展示层读这个近似值就够千万别为此引入分布式事务得不偿失。5. 从入口到闭环一条完整可落地的秒杀链路前面分别讲了Redis和数据库的优化但面试官喜欢追问“你把这些组合在一起是怎么设计的”。我把一套验证过的完整链路讲清楚你可以照着搭也可以在面试时作为一个整体方案输出。5.1 流量入口的第一道闸门CDN、静态化和网关限流秒杀页面的绝大部分内容是静态的商品图、文案、按钮样式几乎不变只有“剩余库存”“是否可抢”是动态的。所以第一步是把页面静态化推送到CDN用户刷页面时根本没有请求打到后端。唯一的动态接口是“查询抢购状态”和“提交抢购”可以单独抽成轻量接口加上版本号参数做缓存控制把动态请求量进一步压缩。网关层必须做流量整形。常用的是Sentinel或Nginx的limit_req按用户维度限流比如每个用户每秒最多1次提交同一设备ID、同一IP再做更严格的限制防止脚本刷。秒杀场景里真正的自然人流量远没有想象中恐怖脚本和机器人才是流量大头先把这部分挡掉后端压力立刻小一个量级。我记得有一次线上秒杀网关层拦掉的请求占总请求的九成以上真正进到业务层的都是有效流量。5.2 提交抢购请求的异步化与排队用户点击抢购后请求进入下单链路此时不需要同步把订单写完。我的方案是网关校验通过 → 生成一个抢购凭证token写入Redis并设置短过期 → 用户拿着token进入排队队列返回“正在排队中”的提示。队列可以用消息队列实现比如RocketMQ的普通消息消费者异步处理订单创建。这样用户侧体验是“请求没丢”后端则把突发流量削成了平稳的消费流。排队凭证的设计有个细节token要绑定用户ID和券ID并且用Redis的SETNX加过期时间做一次性校验防止用户拿同一个token重复下单也防止用户绕过排队直接调下单接口。这套机制还能顺带解决接口被刷的问题因为每个token都是服务端下发的没有token的请求一律拒绝。5.3 数据闭环Redis预扣、异步落库、对账补偿把整条链路串起来看是这样的用户提交后先执行Redis的Lua脚本做库存预扣扣减成功则生成token并投递消息消息消费者在数据库执行库存扣减和订单创建如果数据库扣减失败触发补偿逻辑回滚Redis库存并释放token活动结束后对账任务核对两边的库存发现差异以数据库账目为准修正。这套闭环的核心思想是Redis管性能数据库管正确性消息队列做解耦对账任务做最终兜底。面试时把这四者的角色讲清楚比背一百个优化点都管用。实际项目里我还会在Redis和数据库之间加一层操作流水表每条扣减流水都有唯一编号消费端按唯一编号做幂等这样即使消息重复投递也不会导致库存多扣。这层幂等设计在活动高峰期特别重要因为业务量一大消息重复几乎是必然的。6. 实战避坑实录这些问题我全踩过写在最后的一些经验都是我在真实项目里付出过代价才记下来的面试时如果能主动说出来是很大的加分项因为细节最能体现真实性。6.1 缓存三大顽疾穿透、击穿、雪崩的一次性梳理这三兄弟经常被混淆我做一个速查表方便你对照排查。问题触发场景典型表现我的处理方案缓存穿透查询不存在的Key缓存和数据库都没有大量空查询打到数据库DB压力激增布隆过滤器前置过滤空值也写入缓存设短过期1到2分钟缓存击穿单个热点Key过期瞬间大量请求同时回源热点Key对应的DB行被打爆热点Key不设过期或设置逻辑过期互斥锁只放一个请求去重建缓存本地缓存兜底层缓存雪崩大量Key同时过期数据库瞬间被所有回源流量打穿过期时间加随机值打散多级缓存Redis高可用部署避免单点宕机秒杀场景里重点防的是击穿因为热点Key集中且流量巨大。我通常给热点Key设置“逻辑过期”值里带一个过期时间戳读的时候发现过期不是直接删除重建而是先返回旧值同时异步发起一个重建任务只让一个线程去回源数据库更新缓存。这个方案能保证过期瞬间不会出现回源尖峰用户体验上几乎无感。6.2 本地缓存和散列Key的副作用本地缓存时间设置过长我遇到过用户端集中投诉“明明显示有货但抢不到”。后来我把详情类数据的本地缓存统一控制在2秒以内并且用强制刷新机制活动开始和库存临界时通过配置中心主动通知各实例清空对应Key的本地缓存。这个强制刷新机制是本地缓存能不能用的关键没有它就不要在秒杀场景里用长TTL的本地缓存宁可多打一点Redis也不能让用户看到过期数据。热点Key散列也有一个容易被忽略的坑如果库存子Key数量设成10个但总库存只有5件那么前几次扣减就把其中几个子Key扣成负数了后续请求随机选到负数子Key会直接返回失败但实际上其他子Key可能还有余量。所以子Key数量的设置要远大于单Key可能被扣减的并发片段数或者扣减失败后做一个“随机重试几次”的逻辑换别的子Key再试一次。我在代码里通常会允许用户在一次请求里重试3次散列子Key性能损耗极小但对整体成功率提升很明显这个细节能体现你真的处理过边界条件。6.3 关于这道面试题的答题节奏最后聊一点应试经验。这种题不要上来就报技术名词我的建议是按“识别问题→分析瓶颈→分层解决→兜底一致性”的顺序展开。先承认这个场景下热点Key是必然现象再把故障链路理一遍让面试官看到你的分析路径。技术方案部分把本地缓存、热点散列、Redis预扣、异步落库、对账补偿这些点组合成一条完整链路来讲而不是零散地列技巧。最后主动提坑比如本地缓存的强制刷新、散列Key的重试机制、连接池参数的边界这些细节是区分“背过答案”和“真的干过”的关键。我个人在实际项目里最深的一条体会是高并发优化的本质不是在Redis和数据库之间选边站而是让每一层只干自己最擅长的事同时把层与层之间的失败情况都用补偿机制兜住。热点Key治理也是一样它不是某一天上线某个功能就能一劳永逸的它应该是系统从设计之初就带有的能力。你如果能把这道题理解到这一层面试结果基本不会差。