1. 秒杀这个场景的难点与瓶颈分析1.1 一条下单链路上的真实压力分布优惠券秒杀听起来是个很轻的功能无非就是点一下领券。但把它放到流量洪峰下它就是整套系统里最容易被打穿的一环。我做过几个类似的促销项目最开始也天真地以为加个索引、开个事务就完事了结果第一次压测就把数据库连接池打满接口平均响应从 30ms 直接飙到 8 秒以上前端大量请求超时重试压力反而被放大了一轮。问题出在链路上。一次秒杀请求正常要经过网关鉴权、活动校验、库存判断、库存扣减、生成订单、写明细、发通知这一串动作。其中真正消耗数据库资源的是库存扣减和订单落库这两步而这两步恰好都在写操作上。数据库的行锁、事务日志、索引维护每一项都在洪峰下被放大。一张几十万行的小表扛个一两千的并发写就已经很吃力何况秒杀经常是几万甚至几十万的瞬时请求。所以秒杀的优化本质不是把接口写快而是把不该到达数据库的请求提前挡掉。我在实际项目里总结下来一个完整的秒杀链路至少要做四层拦截前端按钮置灰和倒计时、网关层限流、应用层本地缓存与校验、Redis 层原子扣减。这四层每挡掉一批请求后面一层就轻松一分。1.2 为什么库存放进 Redis 只是起点很多人对秒杀的理解是库存放 Redis扣减用它就够了。这个认知只对了一半。Redis 单实例的 QPS 确实能到十万级别但秒杀请求打进来除了扣库存还要判断用户是否重复领取、要校验活动时间、要生成订单号、要通知下游。这些动作如果都塞进一次 Redis 交互里网络往返次数会成倍增长实际吞吐远低于理论值。更麻烦的是数据一致性问题。Redis 扣减成功不代表订单一定落地成功。消费者服务挂了、消息丢了、数据库主从切换任何一个环节出问题都会导致库存扣了订单没有或者订单有了库存没扣。这就是我在标题里提到的实战部分最花时间的点——扣减只是开始一致性收尾才是难点。还有一个常被忽略的细节库存预热。活动开始前要把库存从数据库同步到 Redis如果预热的时机不对比如活动前十分钟才写碰上一波提前刷新的用户就可能出现 Redis 有库存但数据库没同步完的错位。我一般会在活动开始前半小时做预热预热完成后做一次双端比对把差异记日志告警确认无误才放流量进来。1.3 适合谁来读这篇内容如果你已经能写 CRUD但对高并发原子性最终一致性这些词只有模糊印象这篇会帮你把这些概念落到具体代码和具体参数上。如果你已经做过秒杀但一直停留能跑就行的阶段文中关于 Lua 脚本缓存失效、库存回滚补偿、热点 Key 打散的几个坑应该能对上你曾经遇到过的现象。下面所有代码和配置都基于我实际调试过的环境整理参数值你可以按自己的机器规格调整但思路和顺序基本可以直接搬。2. 整体方案选型与架构分层设计2.1 为什么选择 Redis Lua 异步落库的组合秒杀库存扣减的方案市面上常见的有三种我把它们的对比整理成表格方便你按项目体量选。方案实现方式优点缺点适用场景纯数据库update 带条件扣减实现简单、天然强一致并发低行锁竞争严重小流量、内部活动Redis 同步落库扣减后立即写订单实现直观Redis 与数据库两次写成功率受数据库影响中等流量、要求强实时Redis 异步落库扣减后发消息消费者落库削峰明显、响应快需要补偿机制实现复杂大促、高并发秒杀我选第三种理由很直接秒杀的用户体验核心是点下去要有反馈响应时间必须压在百毫秒级。同步落库等于把数据库的响应时间直接暴露给用户一旦数据库抖动整个接口就跟着抖。异步化之后Redis 扣减成功就立刻返回排队中用户看到结果数据库按自己的节奏消费两边解耦。Lua 脚本的作用是把查库存、判断是否重复、扣减、记录用户这四个动作打包成一次原子执行。Redis 单线程执行 Lua中间不会插入其他命令这就从根本上杜绝了查到有库存、扣的时候没了的竞态。2.2 分层拦截的具体职责划分我习惯把整条链路拆成五层每层干什么写清楚后面排查问题的时候直接对号入座接入层按钮防抖、倒计时结束后才允许点击减少无效请求网关按用户 IP 和接口维度做令牌桶限流。应用层活动状态本地缓存用 Caffeine 之类设置 1 到 3 秒过期避免每次请求都查活动表参数合法性快速校验非法请求直接返回。Redis 层原子扣减、一人一单判定、幂等令牌校验这三件事尽量合并到一个 Lua 脚本里。消息层扣减成功后投递下单消息消息体带用户 ID、券 ID、扣减流水号。数据层消费消息落库靠唯一索引兜底一人一单靠条件更新兜底库存不为负。这套分层的关键在于越靠前的层成本越低拦截效率越高。本地缓存的一次判断是纳秒级Redis 是毫秒级数据库是十毫秒级往上走让便宜的操作先做贵的操作后做是最朴素的优化原则。2.3 库存预热与热点 Key 的取舍预热这件事我的做法是写一个独立的初始化任务把活动库存、活动起止时间、限购数量统一写进 Rediskey 的设计要带上活动维度避免不同活动互相覆盖。结构上库存用一个 String 存剩余量用DECR更快领取用户用 Set方便SISMEMBER判断。# 库存预热示例活动维度 券维度 SET seckill:stock:1001 500 SET seckill:limit:1001 1 HSET seckill:meta:1001 startAt 1735660800 endAt 1735747200 EXPIRE seckill:stock:1001 172800EXPIRE这一句千万别漏。我见过不少项目预热时忘了设过期活动结束后这些 key 一直挂在内存里日积月累把实例内存撑爆最后触发淘汰策略把别的业务热点数据挤出去故障排查了半天才发现是秒杀留下的垃圾数据。至于热点 Key单活动单库存 key 在十万级 QPS 下其实还能扛因为 Redis 单实例处理简单命令的能力足够。真正需要分桶的场景是百万级并发把 500 个库存拆成 10 个桶每个桶 50请求按用户 ID 取模落到某个桶。分桶换来的是吞吐代价是某个桶空了但整体还有库存的碎片问题需要在扣减失败时做一次跨桶重试。我的建议是没到瓶颈就别分桶分桶带来的复杂度和排查难度比它省下的那点性能更贵。3. 库存扣减的原子性实现细节3.1 为什么普通 GET DECR 一定会超卖先看一段很多人第一版都会写的代码Integer stock redisTemplate.opsForValue().get(stockKey); if (stock ! null stock 0) { redisTemplate.opsForValue().decrement(stockKey); // 继续下单 }这段代码在单线程下没问题但在并发下必然超卖。GET和DECR是两次独立的网络往返A 线程读到库存是 1B 线程同时也读到 1两边都判定有库存然后各自DECR库存变成 -1两份订单都成功。这就是典型的检查与执行分离导致的竞态。有人会说那我直接用DECR的返回值判断不就行了返回值小于 0 说明扣超了再INCR补回去。这个思路能减少超卖但仍然有问题补回去的过程中库存短暂变成负数别的请求会读到负库存而且在补回之前如果服务宕机负数就永久留在 Redis 里了。正确的解法只有一条路把判断和扣减放到 Redis 服务端的同一次执行里。Lua 脚本就是干这个的脚本执行期间 Redis 不会处理其他命令原子性天然成立。3.2 一段可以直接复用的扣减脚本下面这段脚本是我在多个项目里反复用过的版本把库存判断、重复领取判断、扣减、记录用户四件事合并成一次执行通过不同的返回值区分结果方便上层做不同处理。-- KEYS[1] 库存 key -- KEYS[2] 已领取用户 set key -- ARGV[1] 用户标识 -- ARGV[2] 限购数量当前场景固定为 1 -- 返回0 成功 -1 库存不足 -2 重复领取 -3 参数异常 local stock redis.call(GET, KEYS[1]) if not stock then return -3 end if tonumber(stock) 0 then return -1 end if redis.call(SISMEMBER, KEYS[2], ARGV[1]) 1 then return -2 end redis.call(DECR, KEYS[1]) redis.call(SADD, KEYS[2], ARGV[1]) -- 给用户集合一个比活动更长的过期时间防止无限膨胀 redis.call(EXPIRE, KEYS[2], 172800) return 0上层调用时用 Java 的DefaultRedisScript把返回类型声明成Longprivate static final DefaultRedisScriptLong SECKILL_SCRIPT; static { SECKILL_SCRIPT new DefaultRedisScript(); SECKILL_SCRIPT.setLocation(new ClassPathResource(lua/seckill.lua)); SECKILL_SCRIPT.setResultType(Long.class); } public Long trySeckill(Long couponId, Long userId) { String stockKey seckill:stock: couponId; String userKey seckill:users: couponId; return redisTemplate.execute(SECKILL_SCRIPT, Arrays.asList(stockKey, userKey), userId.toString(), 1); }返回值处理要写全很多人只判断了 0 和 -1把 -2、-3 当成失败随便返回结果用户重复提交时看到的提示是库存不足体验很差。我在日志里给每个返回码打了标签方便统计各分支的占比压测时能很直观看出限购拦截率。3.3 注意 EVALSHA 的 NOSCRIPT 陷阱脚本内容比较长的时候每次传输脚本正文会浪费带宽。Redis 提供了SCRIPT LOAD加EVALSHA的机制客户端先加载脚本拿到 SHA1后续只传 SHA1。Spring Data Redis 的DefaultRedisScript默认会尝试走这条路。坑在于Redis 重启、主从切换、或者执行了SCRIPT FLUSH缓存里的脚本就没了此时EVALSHA会抛NOSCRIPT No matching script异常。如果没有兜底秒杀接口会直接报错。try { return redisTemplate.execute(SECKILL_SCRIPT, keys, args); } catch (RedisSystemException e) { if (e.getCause() instanceof RedisCommandExecutionException e.getCause().getMessage().contains(NOSCRIPT)) { // 触发一次 EVAL 重新加载再重试 redisTemplate.execute(new DefaultRedisScript(SCRIPT_TEXT, Long.class), keys, args); return redisTemplate.execute(SECKILL_SCRIPT, keys, args); } throw e; }更省事的做法是在应用启动时主动执行一次SCRIPT LOAD同时保留上面的重试逻辑。别指望配置了就不会出问题主从切换这种事凌晨三点发生的时候你不会想爬起来改代码。4. 一人一单与幂等控制的三道防线4.1 Redis 层的快速拦截一人一单最直接的实现就是上面脚本里的SISMEMBER。用户集合用 Set 存判断和写入都在 Lua 里完成不会出现两个请求同时判断都没领过的情况。集合的膨胀问题要提前想。一张券如果有 50 万人领Set 里就是 50 万个成员按每个成员几十字节算大概十几兆到几十兆。单看不多但同时开十个活动就很可观了。我的处理是给集合设过期时间到期自动清掉另外活动结束后跑一个清理任务把结果归档到数据库Redis 里只保留活动期内的数据。还有一种实现是用SETNX建一个seckill:order:{couponId}:{userId}的 key写入成功才算领到。这种方式的优点是单 key 粒度细缺点是 key 数量多几十万用户就是几十万个 key内存碎片和 key 过期扫描都会带来额外开销。相比之下 Set 更紧凑我一般优先用 Set。4.2 幂等令牌防止重复提交前端防抖只能挡住手快的用户挡不住脚本和重放。我的做法是下单接口要求带一个客户端生成的请求令牌服务端用SETNX抢占抢到才继续抢不到直接返回请勿重复提交。SET seckill:token:{token} 1 NX EX 60NX保证只有第一个请求能成功EX 60保证令牌 60 秒后自动清理不会无限堆积。这个令牌同时起到两个作用防重放以及给下游消费者提供幂等依据——消息体里带上令牌消费端落库前先查这个令牌是否已处理过。这里有个细节值得说一下令牌的过期时间要和业务的最大处理时长匹配。设太短用户网络慢一点重试就绕过了防重设太长内存占用高。我一般按接口 P99 耗时的 10 倍左右设置秒杀场景 60 秒是个比较稳的值。4.3 数据库唯一索引的最终兜底前两道防线都在 Redis一旦 Redis 出问题或者消息重复投递还是可能产生重复订单。所以数据库层面必须有一个唯一索引兜底一般建在(user_id, coupon_id)上。ALTER TABLE coupon_order ADD UNIQUE KEY uk_user_coupon (user_id, coupon_id);消费端落库时捕获唯一键冲突异常捕获到就说明是重复消息直接确认消费不再重试。这个兜底看着笨但它是最可靠的一道因为它不依赖任何外部组件的正确性。我一直坚持一个原则分布式场景下的最终正确性一定要落在数据库约束上中间件再强也只是加速不是保证。库存扣减同理落库时用条件更新UPDATE coupon_stock SET available available - 1 WHERE coupon_id #{couponId} AND available 0;判断影响行数是否为 1为 0 说明库存已经没了此时要把 Redis 里多扣的那一份补回去INCR加SREM补偿动作放到一个专门的回滚方法里带上重试。5. 异步下单链路与最终一致性处理5.1 消息投递的时机与消息体设计Redis 扣减成功后立刻投递消息这里的关键是投递失败要能被感知。我的做法是同步发送带确认的消息发送失败就把这次扣减标记为待补偿写进一张本地补偿表由定时任务扫描重发。消息体我一般包含这些字段{ traceId: s-20250101-0001, couponId: 1001, userId: 88231, token: tk_9f3a, deductTime: 1735660800123, retry: 0 }traceId贯穿整条链路排查问题时靠它串起日志。retry记录重试次数超过阈值就进死信队列人工处理避免无限重试把队列堵死。消息的顺序性不用太纠结。同一用户的两次请求因为 Redis 层的 Set 判断本来就只有一次能通过重复消息也只会在唯一索引那里被拦掉跟顺序无关。5.2 消费端的落库与失败补偿消费端的逻辑要写得不信任任何输入。先查幂等表或令牌已处理直接返回再执行库存条件更新影响行数为 0 就说明数据库库存已经没了此时要触发 Redis 回滚然后插入订单捕获唯一键冲突当成功处理最后写一条消费记录同一个事务里提交。事务边界要划清楚库存更新和订单插入放同一个本地事务里要么都成要么都败这样不会出现订单有了库存没扣的中间态。补偿这块我踩过一个坑一开始补偿逻辑写成Redis 扣减失败就 INCR 加一但消息重试和补偿任务可能同时触发导致库存被加了两次反而超卖。后来改成每条补偿记录带一个唯一编号回滚前先SETNX一个补偿标记同一个编号只能回滚一次问题才消失。6. 压测方案与常见故障排查实录6.1 压测该看哪些指标压测不是看 QPS 数字好看就行我关注的是这几个指标关注点我常用的阈值参考接口 P99用户实际体感小于 200ms错误率是否有雪崩迹象小于 0.1%Redis CPU是否成为瓶颈持续低于 70%Redis 连接数连接池是否打满低于最大连接数的 80%消息积压消费能力是否够5 分钟内能清空数据库连接池是否被打穿活跃连接低于上限的 70%压测时我会刻意做两种场景一种是均匀流量看系统稳态另一种是脉冲流量模拟开抢瞬间的峰值。脉冲场景最容易暴露问题我在一次压测里就遇到过 Redis 响应正常但应用层线程池被打满的情况原因是异步投递消息时用了同步阻塞的线程池队列满了之后业务线程全部卡住。后来改成独立的线程池并加了拒绝策略才把这个问题解决掉。6.2 常见问题速查表现象可能原因排查方式处理办法库存出现负数判断与扣减非原子检查是否用了 Lua改用脚本禁止 GET 后再 DECR用户能领两张券一人一单判断被绕过看是否有并发窗口Set 判断放进 Lua加唯一索引接口偶发 NOSCRIPT 报错脚本缓存丢失看 Redis 是否重启或切换启动预热脚本 异常重试订单数量少于扣减数量消息投递失败无感知核对扣减日志与订单表加本地补偿表和定时重扫活动结束后内存不降预热 key 没设过期TTL检查相关 key统一加过期跑清理任务压测 QPS 上不去连接池或线程池限制看连接等待时间调大池子缩短超时6.3 我遇到过的两个真实问题第一个是Redis 扣减成功消息发出了但订单没落库也没报错。查了两个小时才发现消费者那边的反序列化配置和生产者不一致消息被当成未知类型直接 ack 丢弃了。这个坑的教训是消费端遇到无法解析的消息绝对不能静默 ack要么进死信队列要么抛异常让它重试不然数据丢了都不知道。第二个是活动刚开始几十秒内Redis 监控显示 QPS 暴涨到平时的五倍但实际成交量没变。原因是大量用户在倒计时结束后疯狂点击前端按钮置灰有 300ms 延迟后端又没有做请求去重同一个用户一秒内打进来七八个请求。加了令牌校验之后无效请求在第一层就被挡掉了Redis 压力直接降了七成。7. 几个提升稳定性的实操细节7.1 库存分桶什么时候才值得上分桶这个概念被讲得很多但真正需要它的场景没那么多。单 key 的库存在十万级 QPS 下是能扛的因为DECR是 O(1) 操作Redis 单线程处理极快。真正需要分桶是在单 key 已经打满实例 CPU、且不能水平扩容的场景。分桶的实现思路是把总库存 N 拆成 M 个桶每个桶 N/M用户按userId % M定位到桶桶内还是用 Lua 扣减。某个桶扣完了回退到其他桶再试一次。这个回退逻辑要写对我见过写成随机重试的结果在库存快耗尽时疯狂空转把 CPU 又拉高了。我的建议是先用单 key 压测看 Redis 实例 CPU 到多少。没到 70% 就别分桶。到了再考虑而且优先考虑的是加实例、读写分离这类更简单的方案。7.2 灰度与降级预案秒杀功能一定要有开关。我习惯在配置中心放一个seckill.switch默认关闭活动开始前手动打开异常时一键关闭。关闭后接口直接返回活动太火爆请稍后再试保护后端不被拖垮。降级分几档第一档关掉非核心链路比如领券后的通知、积分发放第二档把异步改成只入队不消费先把请求接住第三档直接熔断接口。每一档的触发条件写成配置靠监控自动触发不要等人来决策洪峰面前人的反应速度是不够的。7.3 数据核对不能省活动结束后我一定会跑一次核对Redis 剩余库存 已生成订单数 是否等于 初始库存。不相等就说明有漏单或者多扣需要从扣减日志里逐条对。这个核对脚本用 Python 写几十行就够但它是发现隐性问题的最后一道网。我在一个项目里靠这个核对发现了 37 笔扣了库存但订单丢了的记录都是消息投递超时没重试造成的后来补上了补偿任务才彻底解决。# 简化的核对逻辑示意 init_stock 500 redis_left int(r.get(seckill:stock:1001)) db_orders db.query(select count(*) from coupon_order where coupon_id 1001) if redis_left db_orders ! init_stock: print(f对账异常: 剩余{redis_left} 订单{db_orders} 差额{init_stock - redis_left - db_orders})说到底秒杀这个场景考的不是 Redis 用得多花哨而是你对并发下的原子性和分布式下的最终一致性这两件事理解得够不够扎实。 Lua 脚本解决的是前者补偿机制和数据库约束解决的是后者剩下的都是在这两个基础上做工程化的打磨。我在实际项目里反复验证下来只要把库存扣减的原子性、一人一单的判定、异步链路的可补偿这三件事做扎实剩下的性能问题基本都是调参数和加机器能解决的。
1. 秒杀这个场景的难点与瓶颈分析1.1 一条下单链路上的真实压力分布优惠券秒杀听起来是个很轻的功能无非就是点一下领券。但把它放到流量洪峰下它就是整套系统里最容易被打穿的一环。我做过几个类似的促销项目最开始也天真地以为加个索引、开个事务就完事了结果第一次压测就把数据库连接池打满接口平均响应从 30ms 直接飙到 8 秒以上前端大量请求超时重试压力反而被放大了一轮。问题出在链路上。一次秒杀请求正常要经过网关鉴权、活动校验、库存判断、库存扣减、生成订单、写明细、发通知这一串动作。其中真正消耗数据库资源的是库存扣减和订单落库这两步而这两步恰好都在写操作上。数据库的行锁、事务日志、索引维护每一项都在洪峰下被放大。一张几十万行的小表扛个一两千的并发写就已经很吃力何况秒杀经常是几万甚至几十万的瞬时请求。所以秒杀的优化本质不是把接口写快而是把不该到达数据库的请求提前挡掉。我在实际项目里总结下来一个完整的秒杀链路至少要做四层拦截前端按钮置灰和倒计时、网关层限流、应用层本地缓存与校验、Redis 层原子扣减。这四层每挡掉一批请求后面一层就轻松一分。1.2 为什么库存放进 Redis 只是起点很多人对秒杀的理解是库存放 Redis扣减用它就够了。这个认知只对了一半。Redis 单实例的 QPS 确实能到十万级别但秒杀请求打进来除了扣库存还要判断用户是否重复领取、要校验活动时间、要生成订单号、要通知下游。这些动作如果都塞进一次 Redis 交互里网络往返次数会成倍增长实际吞吐远低于理论值。更麻烦的是数据一致性问题。Redis 扣减成功不代表订单一定落地成功。消费者服务挂了、消息丢了、数据库主从切换任何一个环节出问题都会导致库存扣了订单没有或者订单有了库存没扣。这就是我在标题里提到的实战部分最花时间的点——扣减只是开始一致性收尾才是难点。还有一个常被忽略的细节库存预热。活动开始前要把库存从数据库同步到 Redis如果预热的时机不对比如活动前十分钟才写碰上一波提前刷新的用户就可能出现 Redis 有库存但数据库没同步完的错位。我一般会在活动开始前半小时做预热预热完成后做一次双端比对把差异记日志告警确认无误才放流量进来。1.3 适合谁来读这篇内容如果你已经能写 CRUD但对高并发原子性最终一致性这些词只有模糊印象这篇会帮你把这些概念落到具体代码和具体参数上。如果你已经做过秒杀但一直停留能跑就行的阶段文中关于 Lua 脚本缓存失效、库存回滚补偿、热点 Key 打散的几个坑应该能对上你曾经遇到过的现象。下面所有代码和配置都基于我实际调试过的环境整理参数值你可以按自己的机器规格调整但思路和顺序基本可以直接搬。2. 整体方案选型与架构分层设计2.1 为什么选择 Redis Lua 异步落库的组合秒杀库存扣减的方案市面上常见的有三种我把它们的对比整理成表格方便你按项目体量选。方案实现方式优点缺点适用场景纯数据库update 带条件扣减实现简单、天然强一致并发低行锁竞争严重小流量、内部活动Redis 同步落库扣减后立即写订单实现直观Redis 与数据库两次写成功率受数据库影响中等流量、要求强实时Redis 异步落库扣减后发消息消费者落库削峰明显、响应快需要补偿机制实现复杂大促、高并发秒杀我选第三种理由很直接秒杀的用户体验核心是点下去要有反馈响应时间必须压在百毫秒级。同步落库等于把数据库的响应时间直接暴露给用户一旦数据库抖动整个接口就跟着抖。异步化之后Redis 扣减成功就立刻返回排队中用户看到结果数据库按自己的节奏消费两边解耦。Lua 脚本的作用是把查库存、判断是否重复、扣减、记录用户这四个动作打包成一次原子执行。Redis 单线程执行 Lua中间不会插入其他命令这就从根本上杜绝了查到有库存、扣的时候没了的竞态。2.2 分层拦截的具体职责划分我习惯把整条链路拆成五层每层干什么写清楚后面排查问题的时候直接对号入座接入层按钮防抖、倒计时结束后才允许点击减少无效请求网关按用户 IP 和接口维度做令牌桶限流。应用层活动状态本地缓存用 Caffeine 之类设置 1 到 3 秒过期避免每次请求都查活动表参数合法性快速校验非法请求直接返回。Redis 层原子扣减、一人一单判定、幂等令牌校验这三件事尽量合并到一个 Lua 脚本里。消息层扣减成功后投递下单消息消息体带用户 ID、券 ID、扣减流水号。数据层消费消息落库靠唯一索引兜底一人一单靠条件更新兜底库存不为负。这套分层的关键在于越靠前的层成本越低拦截效率越高。本地缓存的一次判断是纳秒级Redis 是毫秒级数据库是十毫秒级往上走让便宜的操作先做贵的操作后做是最朴素的优化原则。2.3 库存预热与热点 Key 的取舍预热这件事我的做法是写一个独立的初始化任务把活动库存、活动起止时间、限购数量统一写进 Rediskey 的设计要带上活动维度避免不同活动互相覆盖。结构上库存用一个 String 存剩余量用DECR更快领取用户用 Set方便SISMEMBER判断。# 库存预热示例活动维度 券维度 SET seckill:stock:1001 500 SET seckill:limit:1001 1 HSET seckill:meta:1001 startAt 1735660800 endAt 1735747200 EXPIRE seckill:stock:1001 172800EXPIRE这一句千万别漏。我见过不少项目预热时忘了设过期活动结束后这些 key 一直挂在内存里日积月累把实例内存撑爆最后触发淘汰策略把别的业务热点数据挤出去故障排查了半天才发现是秒杀留下的垃圾数据。至于热点 Key单活动单库存 key 在十万级 QPS 下其实还能扛因为 Redis 单实例处理简单命令的能力足够。真正需要分桶的场景是百万级并发把 500 个库存拆成 10 个桶每个桶 50请求按用户 ID 取模落到某个桶。分桶换来的是吞吐代价是某个桶空了但整体还有库存的碎片问题需要在扣减失败时做一次跨桶重试。我的建议是没到瓶颈就别分桶分桶带来的复杂度和排查难度比它省下的那点性能更贵。3. 库存扣减的原子性实现细节3.1 为什么普通 GET DECR 一定会超卖先看一段很多人第一版都会写的代码Integer stock redisTemplate.opsForValue().get(stockKey); if (stock ! null stock 0) { redisTemplate.opsForValue().decrement(stockKey); // 继续下单 }这段代码在单线程下没问题但在并发下必然超卖。GET和DECR是两次独立的网络往返A 线程读到库存是 1B 线程同时也读到 1两边都判定有库存然后各自DECR库存变成 -1两份订单都成功。这就是典型的检查与执行分离导致的竞态。有人会说那我直接用DECR的返回值判断不就行了返回值小于 0 说明扣超了再INCR补回去。这个思路能减少超卖但仍然有问题补回去的过程中库存短暂变成负数别的请求会读到负库存而且在补回之前如果服务宕机负数就永久留在 Redis 里了。正确的解法只有一条路把判断和扣减放到 Redis 服务端的同一次执行里。Lua 脚本就是干这个的脚本执行期间 Redis 不会处理其他命令原子性天然成立。3.2 一段可以直接复用的扣减脚本下面这段脚本是我在多个项目里反复用过的版本把库存判断、重复领取判断、扣减、记录用户四件事合并成一次执行通过不同的返回值区分结果方便上层做不同处理。-- KEYS[1] 库存 key -- KEYS[2] 已领取用户 set key -- ARGV[1] 用户标识 -- ARGV[2] 限购数量当前场景固定为 1 -- 返回0 成功 -1 库存不足 -2 重复领取 -3 参数异常 local stock redis.call(GET, KEYS[1]) if not stock then return -3 end if tonumber(stock) 0 then return -1 end if redis.call(SISMEMBER, KEYS[2], ARGV[1]) 1 then return -2 end redis.call(DECR, KEYS[1]) redis.call(SADD, KEYS[2], ARGV[1]) -- 给用户集合一个比活动更长的过期时间防止无限膨胀 redis.call(EXPIRE, KEYS[2], 172800) return 0上层调用时用 Java 的DefaultRedisScript把返回类型声明成Longprivate static final DefaultRedisScriptLong SECKILL_SCRIPT; static { SECKILL_SCRIPT new DefaultRedisScript(); SECKILL_SCRIPT.setLocation(new ClassPathResource(lua/seckill.lua)); SECKILL_SCRIPT.setResultType(Long.class); } public Long trySeckill(Long couponId, Long userId) { String stockKey seckill:stock: couponId; String userKey seckill:users: couponId; return redisTemplate.execute(SECKILL_SCRIPT, Arrays.asList(stockKey, userKey), userId.toString(), 1); }返回值处理要写全很多人只判断了 0 和 -1把 -2、-3 当成失败随便返回结果用户重复提交时看到的提示是库存不足体验很差。我在日志里给每个返回码打了标签方便统计各分支的占比压测时能很直观看出限购拦截率。3.3 注意 EVALSHA 的 NOSCRIPT 陷阱脚本内容比较长的时候每次传输脚本正文会浪费带宽。Redis 提供了SCRIPT LOAD加EVALSHA的机制客户端先加载脚本拿到 SHA1后续只传 SHA1。Spring Data Redis 的DefaultRedisScript默认会尝试走这条路。坑在于Redis 重启、主从切换、或者执行了SCRIPT FLUSH缓存里的脚本就没了此时EVALSHA会抛NOSCRIPT No matching script异常。如果没有兜底秒杀接口会直接报错。try { return redisTemplate.execute(SECKILL_SCRIPT, keys, args); } catch (RedisSystemException e) { if (e.getCause() instanceof RedisCommandExecutionException e.getCause().getMessage().contains(NOSCRIPT)) { // 触发一次 EVAL 重新加载再重试 redisTemplate.execute(new DefaultRedisScript(SCRIPT_TEXT, Long.class), keys, args); return redisTemplate.execute(SECKILL_SCRIPT, keys, args); } throw e; }更省事的做法是在应用启动时主动执行一次SCRIPT LOAD同时保留上面的重试逻辑。别指望配置了就不会出问题主从切换这种事凌晨三点发生的时候你不会想爬起来改代码。4. 一人一单与幂等控制的三道防线4.1 Redis 层的快速拦截一人一单最直接的实现就是上面脚本里的SISMEMBER。用户集合用 Set 存判断和写入都在 Lua 里完成不会出现两个请求同时判断都没领过的情况。集合的膨胀问题要提前想。一张券如果有 50 万人领Set 里就是 50 万个成员按每个成员几十字节算大概十几兆到几十兆。单看不多但同时开十个活动就很可观了。我的处理是给集合设过期时间到期自动清掉另外活动结束后跑一个清理任务把结果归档到数据库Redis 里只保留活动期内的数据。还有一种实现是用SETNX建一个seckill:order:{couponId}:{userId}的 key写入成功才算领到。这种方式的优点是单 key 粒度细缺点是 key 数量多几十万用户就是几十万个 key内存碎片和 key 过期扫描都会带来额外开销。相比之下 Set 更紧凑我一般优先用 Set。4.2 幂等令牌防止重复提交前端防抖只能挡住手快的用户挡不住脚本和重放。我的做法是下单接口要求带一个客户端生成的请求令牌服务端用SETNX抢占抢到才继续抢不到直接返回请勿重复提交。SET seckill:token:{token} 1 NX EX 60NX保证只有第一个请求能成功EX 60保证令牌 60 秒后自动清理不会无限堆积。这个令牌同时起到两个作用防重放以及给下游消费者提供幂等依据——消息体里带上令牌消费端落库前先查这个令牌是否已处理过。这里有个细节值得说一下令牌的过期时间要和业务的最大处理时长匹配。设太短用户网络慢一点重试就绕过了防重设太长内存占用高。我一般按接口 P99 耗时的 10 倍左右设置秒杀场景 60 秒是个比较稳的值。4.3 数据库唯一索引的最终兜底前两道防线都在 Redis一旦 Redis 出问题或者消息重复投递还是可能产生重复订单。所以数据库层面必须有一个唯一索引兜底一般建在(user_id, coupon_id)上。ALTER TABLE coupon_order ADD UNIQUE KEY uk_user_coupon (user_id, coupon_id);消费端落库时捕获唯一键冲突异常捕获到就说明是重复消息直接确认消费不再重试。这个兜底看着笨但它是最可靠的一道因为它不依赖任何外部组件的正确性。我一直坚持一个原则分布式场景下的最终正确性一定要落在数据库约束上中间件再强也只是加速不是保证。库存扣减同理落库时用条件更新UPDATE coupon_stock SET available available - 1 WHERE coupon_id #{couponId} AND available 0;判断影响行数是否为 1为 0 说明库存已经没了此时要把 Redis 里多扣的那一份补回去INCR加SREM补偿动作放到一个专门的回滚方法里带上重试。5. 异步下单链路与最终一致性处理5.1 消息投递的时机与消息体设计Redis 扣减成功后立刻投递消息这里的关键是投递失败要能被感知。我的做法是同步发送带确认的消息发送失败就把这次扣减标记为待补偿写进一张本地补偿表由定时任务扫描重发。消息体我一般包含这些字段{ traceId: s-20250101-0001, couponId: 1001, userId: 88231, token: tk_9f3a, deductTime: 1735660800123, retry: 0 }traceId贯穿整条链路排查问题时靠它串起日志。retry记录重试次数超过阈值就进死信队列人工处理避免无限重试把队列堵死。消息的顺序性不用太纠结。同一用户的两次请求因为 Redis 层的 Set 判断本来就只有一次能通过重复消息也只会在唯一索引那里被拦掉跟顺序无关。5.2 消费端的落库与失败补偿消费端的逻辑要写得不信任任何输入。先查幂等表或令牌已处理直接返回再执行库存条件更新影响行数为 0 就说明数据库库存已经没了此时要触发 Redis 回滚然后插入订单捕获唯一键冲突当成功处理最后写一条消费记录同一个事务里提交。事务边界要划清楚库存更新和订单插入放同一个本地事务里要么都成要么都败这样不会出现订单有了库存没扣的中间态。补偿这块我踩过一个坑一开始补偿逻辑写成Redis 扣减失败就 INCR 加一但消息重试和补偿任务可能同时触发导致库存被加了两次反而超卖。后来改成每条补偿记录带一个唯一编号回滚前先SETNX一个补偿标记同一个编号只能回滚一次问题才消失。6. 压测方案与常见故障排查实录6.1 压测该看哪些指标压测不是看 QPS 数字好看就行我关注的是这几个指标关注点我常用的阈值参考接口 P99用户实际体感小于 200ms错误率是否有雪崩迹象小于 0.1%Redis CPU是否成为瓶颈持续低于 70%Redis 连接数连接池是否打满低于最大连接数的 80%消息积压消费能力是否够5 分钟内能清空数据库连接池是否被打穿活跃连接低于上限的 70%压测时我会刻意做两种场景一种是均匀流量看系统稳态另一种是脉冲流量模拟开抢瞬间的峰值。脉冲场景最容易暴露问题我在一次压测里就遇到过 Redis 响应正常但应用层线程池被打满的情况原因是异步投递消息时用了同步阻塞的线程池队列满了之后业务线程全部卡住。后来改成独立的线程池并加了拒绝策略才把这个问题解决掉。6.2 常见问题速查表现象可能原因排查方式处理办法库存出现负数判断与扣减非原子检查是否用了 Lua改用脚本禁止 GET 后再 DECR用户能领两张券一人一单判断被绕过看是否有并发窗口Set 判断放进 Lua加唯一索引接口偶发 NOSCRIPT 报错脚本缓存丢失看 Redis 是否重启或切换启动预热脚本 异常重试订单数量少于扣减数量消息投递失败无感知核对扣减日志与订单表加本地补偿表和定时重扫活动结束后内存不降预热 key 没设过期TTL检查相关 key统一加过期跑清理任务压测 QPS 上不去连接池或线程池限制看连接等待时间调大池子缩短超时6.3 我遇到过的两个真实问题第一个是Redis 扣减成功消息发出了但订单没落库也没报错。查了两个小时才发现消费者那边的反序列化配置和生产者不一致消息被当成未知类型直接 ack 丢弃了。这个坑的教训是消费端遇到无法解析的消息绝对不能静默 ack要么进死信队列要么抛异常让它重试不然数据丢了都不知道。第二个是活动刚开始几十秒内Redis 监控显示 QPS 暴涨到平时的五倍但实际成交量没变。原因是大量用户在倒计时结束后疯狂点击前端按钮置灰有 300ms 延迟后端又没有做请求去重同一个用户一秒内打进来七八个请求。加了令牌校验之后无效请求在第一层就被挡掉了Redis 压力直接降了七成。7. 几个提升稳定性的实操细节7.1 库存分桶什么时候才值得上分桶这个概念被讲得很多但真正需要它的场景没那么多。单 key 的库存在十万级 QPS 下是能扛的因为DECR是 O(1) 操作Redis 单线程处理极快。真正需要分桶是在单 key 已经打满实例 CPU、且不能水平扩容的场景。分桶的实现思路是把总库存 N 拆成 M 个桶每个桶 N/M用户按userId % M定位到桶桶内还是用 Lua 扣减。某个桶扣完了回退到其他桶再试一次。这个回退逻辑要写对我见过写成随机重试的结果在库存快耗尽时疯狂空转把 CPU 又拉高了。我的建议是先用单 key 压测看 Redis 实例 CPU 到多少。没到 70% 就别分桶。到了再考虑而且优先考虑的是加实例、读写分离这类更简单的方案。7.2 灰度与降级预案秒杀功能一定要有开关。我习惯在配置中心放一个seckill.switch默认关闭活动开始前手动打开异常时一键关闭。关闭后接口直接返回活动太火爆请稍后再试保护后端不被拖垮。降级分几档第一档关掉非核心链路比如领券后的通知、积分发放第二档把异步改成只入队不消费先把请求接住第三档直接熔断接口。每一档的触发条件写成配置靠监控自动触发不要等人来决策洪峰面前人的反应速度是不够的。7.3 数据核对不能省活动结束后我一定会跑一次核对Redis 剩余库存 已生成订单数 是否等于 初始库存。不相等就说明有漏单或者多扣需要从扣减日志里逐条对。这个核对脚本用 Python 写几十行就够但它是发现隐性问题的最后一道网。我在一个项目里靠这个核对发现了 37 笔扣了库存但订单丢了的记录都是消息投递超时没重试造成的后来补上了补偿任务才彻底解决。# 简化的核对逻辑示意 init_stock 500 redis_left int(r.get(seckill:stock:1001)) db_orders db.query(select count(*) from coupon_order where coupon_id 1001) if redis_left db_orders ! init_stock: print(f对账异常: 剩余{redis_left} 订单{db_orders} 差额{init_stock - redis_left - db_orders})说到底秒杀这个场景考的不是 Redis 用得多花哨而是你对并发下的原子性和分布式下的最终一致性这两件事理解得够不够扎实。 Lua 脚本解决的是前者补偿机制和数据库约束解决的是后者剩下的都是在这两个基础上做工程化的打磨。我在实际项目里反复验证下来只要把库存扣减的原子性、一人一单的判定、异步链路的可补偿这三件事做扎实剩下的性能问题基本都是调参数和加机器能解决的。
