秒杀令牌发放看似只是生成一个随机数，但真正压垮后端服务的，是瞬间涌入的流量对存储层和网络带宽的集中冲击，核心解法是把令牌发放从同步瓶颈改造成异步削峰的前置闸门。
令牌发放为什么成了秒杀系统的第一道坎
做过秒杀的后端同学都有这种体验：活动开始前十分钟，一切正常；活动开始那一秒，监控面板上的请求曲线直接拉成一条垂直线。令牌发放接口作为用户请求的第一站，承担了全量流量的首轮冲击，它一旦响应变慢,整个秒杀链路都会跟着雪崩。
突发负载的三个典型特征
秒杀令牌场景下的突发流量，跟日常业务流量完全不是一个物种，日常流量是缓慢爬坡的，秒杀流量是瞬间打满的,具体来说有三个特征：
- 瞬时性：大量请求在开售后的几百毫秒内同时到达，没有预热过程
- 聚集性：所有请求都打在同一个接口、同一批热点商品上，Redis中少数几个key承受绝大部分访问
- 不可预测性：虽然知道大促时间点，但实际流量峰值往往超出预估的几倍
令牌接口被打垮的连锁反应
令牌发放接口一旦出问题，不会只影响它自己，典型故障链路是：令牌接口超时 → 前端重试 → 重试流量叠加 → 数据库连接池被占满 → 整个服务不可用。多数情况下，秒杀系统崩溃不是被用户量打垮的，而是被自己的重试机制打垮的。
行业共识认为，秒杀系统的设计原则应该是“前端拦截、后端兜底”，令牌发放恰恰是前端拦截的最后一道防线,也是后端兜底的第一道关卡。
秒杀令牌方案对比：本地生成还是Redis集中发放
很多团队在令牌方案选型上反复纠结，其实判断标准很简单：看你的令牌需不需要全局唯一性校验。
两种方案的适用场景
| 对比维度 | 本地生成令牌 | Redis集中发放 |
|---|---|---|
| 性能表现 | 极高，无网络开销 | 受限于Redis吞吐，但足够支撑十万级QPS |
| 全局唯一性 | 无法保证，需靠算法规避 | 天然支持，原子操作保证 |
| 一致性风险 | 多实例间可能重复 | 无重复风险 |
| 实现复杂度 | 低 | 中等 |
| 适用场景 | 纯验签型令牌，不依赖库存 | 需要绑定库存、用户维度的令牌 |
本地生成令牌的适用条件
如果你的令牌只是一个防伪造的凭证，比如用JWT或HMAC签名生成，不涉及库存扣减，那完全可以在本地生成。这种情况下，令牌发放接口的瓶颈根本不在生成逻辑，而在网络IO和序列化开销。
Redis集中发放的适用条件
当令牌需要绑定具体商品库存、用户ID或订单维度时，就必须走集中式发放，业内专家指出，用Redis的Lua脚本保证“检查库存-生成令牌-标记占用”三步的原子性,是当前生产环境中最稳妥的做法。
实操路径是：提前把库存预热到Redis，用DECR或Lua脚本扣减，扣减成功才返回令牌，这个方案的QPS上限取决于Redis单实例性能，但配合集群和分片,撑住主流电商大促的峰值流量没有问题。
秒杀系统限流Redis怎么做：令牌桶与漏桶的取舍
令牌发放环节本身也需要限流保护，否则上游流量再大，下游也扛不住，Redis在限流场景中扮演的是“集中计数器”的角色。
令牌桶算法的Redis实现思路
令牌桶允许一定程度的突发流量，适合秒杀这种“允许短时间冲高但总量可控”的场景,实现思路是：
- 用Redis的
HASH结构存储令牌桶状态，字段包括tokens和last_refill_time - 每次请求进来，用Lua脚本计算当前应补的令牌数
- 令牌充足则扣减并放行，不足则直接拒绝
漏桶算法与令牌桶的核心差异
漏桶强制平滑流量，不管上游怎么突发，下游收到的速率恒定。在秒杀场景中，漏桶反而可能导致请求排队时间过长，用户体验更差，所以多数团队选择令牌桶，配合前端限流，给用户一个“抢到了”的即时反馈,而不是让用户一直转圈等待。
Redis限流的具体配置建议
- 单个Redis实例建议将QPS控制在10万以内，超过这个量级考虑读写分离或集群分片
- 限流key要带上商品维度或活动维度，避免全局共用一把锁
- 限流阈值设置为预估峰值的5到2倍，留出冗余空间
高并发秒杀后端服务怎么扛住：削峰、排队与缓存
令牌发放只是第一步，真正的挑战在于整个链路如何协同。秒杀系统的核心思路是“把瞬时流量转化为异步任务”,让后端服务在一个可控的速率下处理请求。
削峰：把同步请求变成异步消息
令牌发放成功后，不要同步去扣库存、生成订单,正确做法是：
- 令牌发放接口只做校验和标记，返回一个“资格凭证”
- 用户拿到令牌后，再调用下单接口
- 下单接口将请求写入消息队列，由消费者异步处理
- 前端轮询订单状态，给用户最终反馈
这样做的直接好处是，后端服务的压力峰值被拉平了,不再依赖于数据库的瞬间吞吐能力。
缓存分层：别让所有请求都打到Redis
虽然Redis很快，但面对百万级并发，单靠Redis也不现实,合理的分层是：
- 本地缓存层：把商品状态、活动开关等低频变化的数据放在JVM内存中
- Redis层：存放令牌、库存等需要全局一致性的数据
- 数据库层：只接收异步落地的最终结果
热点key的防护策略
秒杀场景下，同一个商品的库存key会承受极大访问量，如果这个key刚好在某一时刻过期，大量请求会同时穿透到数据库，这就是缓存雪崩,解决办法是：
- 给热点key设置永不过期，由后台任务主动更新
- 或者设置随机过期时间，避免同一时刻集体失效
- 在应用层加互斥锁，只允许一个请求去重建缓存
突发负载来临前的三项准备工作
秒杀系统不像日常业务，出了问题还有时间排查。必须在活动开始前把所有预案演练到位。
第一项：全链路压测
压测不是简单拿JMeter打几个接口就完事，要模拟真实用户行为：登录、浏览、领取令牌、下单、支付，全链路走一遍,压测结果要关注两个指标：
- P99响应时间：99%的请求在多少毫秒内完成
- 错误率：超过0.1%就要排查瓶颈
第二项：限流阈值和降级开关
提前在配置中心设置好各级限流阈值，并准备好降级预案。降级不是失败，而是保护，当检测到后端服务出现异常时，自动触发降级逻辑，比如直接返回“活动太火爆，请稍后再试”,而不是让请求继续堆积。
第三项：监控告警的粒度
监控不能只看平均响应时间，要看分位值和错误码分布，同时要对Redis的内存使用率、连接数、慢查询数设置独立告警，据统计，相当一部分秒杀事故的根因是Redis连接池被打满,而不是Redis本身性能不够。
秒杀令牌过期时间设置多少合适
这个问题没有标准答案，但有一个经验区间：令牌有效期建议设置在30秒到5分钟之间，太短，用户还没来得及下单就过期了；太长,黄牛有充足时间囤积令牌。
具体设置要考虑业务类型：
- 普通商品秒杀：建议1到2分钟，给用户足够的决策时间
- 限量抢购（如演唱会门票）：建议30到60秒，营造紧迫感
- 需要跳转支付的场景：建议3到5分钟，覆盖完整支付流程
秒杀场景下Redis缓存雪崩怎么解决
缓存雪崩的根源是批量key同时过期，除了前面提到的随机过期时间,还有两个实操手段：
- 多级缓存：Redis之上再加一层本地缓存，即使Redis中的key失效，本地缓存还能兜底
- 熔断降级：当Redis的异常比例超过阈值时，直接熔断对Redis的访问，返回默认值或空结果
另外一个容易被忽略的点是：Redis的持久化策略，秒杀场景下数据变化极快，如果开启AOF持久化且刷盘策略过于频繁，Redis主线程会被阻塞，建议使用everysec策略,兼顾安全性和性能。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e7%a7%92%e6%9d%80%e4%bb%a4%e7%89%8c%e5%8f%91%e6%94%be%e4%b8%ba%e4%bd%95%e5%af%bc%e8%87%b4%e5%90%8e%e7%ab%af%e6%9c%8d%e5%8a%a1%e7%aa%81%e5%8f%91%e8%b4%9f%e8%bd%bd%ef%bc%8c%e6%80%8e%e4%b9%88%e8%a7%a3/
