秒杀系统限流架构设计：应对100万QPS的Redis漏斗模型与避坑指南

在双十一等大促场景中，秒杀活动往往面临极高的并发压力。例如，某个爆款商品预估每秒会收到100万次请求（QPS），而库存仅100件。如何设计一个稳健的限流方案，是后端架构中的经典难题。

一种常见的思路是直接使用Redis进行分布式限流，例如通过INCR命令或Lua脚本实现令牌桶算法，每秒发放100个令牌，未抢到令牌的请求直接返回失败。然而，在100万QPS的洪峰下，将所有请求都导向Redis进行令牌校验，会立即引发严重的性能瓶颈。

Redis并非银弹：直面100万QPS的热点Key挑战

首先进行简单的估算。100万QPS意味着每秒有100万个“抢购”请求需要处理。如果让所有这些请求都访问Redis（即使只是执行一个简单的读取命令），就会形成典型的热点Key问题。

Redis性能虽强，但单节点处理简单命令或Lua脚本的极限吞吐通常在8-10万QPS左右。要承载100万QPS，需要部署庞大的Redis集群。更关键的是，由于所有请求都针对同一个商品（Key如seckill:sku:1001），根据哈希分片规则，这些请求最终会全部落在一个Redis分片节点上。

结果就是：该分片CPU利用率飙升至100%，整个缓存集群响应延迟激增，进而拖垮所有依赖缓存的后端服务（如订单、用户信息），导致全站服务不可用。

因此，在真实的秒杀场景中，绝不能将所有流量都直接引向Redis层。

核心架构：漏斗式限流模型

应对海量并发的正确心法是“层层削减，将流量拦截在最外层”。就像漏斗一样，让100万请求逐层过滤，最终到达底层进行库存操作的请求应控制在极低数量。

漏斗模型通常包含以下四层：

第0层：客户端/前端限流（从源头削减请求）

这是成本最低、效果最显著的一层。如果100万用户同时点击按钮，前端不加控制，瞬间爆发的HTTP请求仅建立TCP连接的开销就足以压垮网络入口。

1. 按钮防抖：活动开始前按钮置灰，点击后强制置灰数秒，防止用户高频重复点击。
2. 随机丢弃：在极端场景下，前端JavaScript或App本地可执行随机丢弃逻辑。例如，100万人抢100件商品，前端可随机丢弃90%的请求，直接向用户提示“活动太火爆”，仅让10%的请求真正发出。
3. 验证码错峰：引入滑动拼图、算术题等交互式验证码。用户完成验证需要数秒时间，从而将原本集中在1秒内的瞬时并发，平滑分散到一个更长的时间窗口内，实现请求削峰。

第1层：网关/接入层限流（拦截非法与溢出流量）

这一层是服务端的“门神”，在流量到达业务应用服务器之前进行拦截。通常利用Nginx配合Lua模块（如OpenResty）实现。

• 手段：使用limit_req_zone模块或编写自定义Lua脚本。
• 逻辑：实施IP级限流或全局总流控。
• 优势：Nginx基于C语言开发，处理此类静态规则的性能极高，远超Java等应用层。在此层直接返回503等状态码，对后端资源消耗几乎为零。

第2层：单机应用内限流（保护微服务实例）

穿透了网关层的请求，会到达具体的Java应用实例。此时，不应立即访问Redis，而应先在JVM进程内部进行一道限流。

• 实现：使用Guava RateLimiter或Sentinel等工具在内存中实现速率限制。
• 策略：假设后端集群有100台实例，计划总共放行5000个请求。则每台机器设置单机限流阈值，例如50 QPS。
• 优势：纯内存操作，无任何网络开销，性能极高，是保护单个服务实例不被击垮的关键。

第3层：分布式精准限流（Redis兜底）

只有成功通过前面三层拦截的少量“幸存”请求（例如上文举例的5000 QPS），才有资格进入最终的分布式校验环节——访问Redis进行精准的库存扣减或令牌扣减。此时Redis面临的压力已从百万级别降至数千，处理起来游刃有余。

限流算法选择：结合业务体验

当被问及限流算法时，不应仅背诵概念，而需结合秒杀的业务特点进行分析。

1. 漏桶算法（Leaky Bucket）

   • 特点：以恒定速率处理请求（出水），超出速率的请求会被丢弃或排队。
   • 缺点：处理速率固定，无法应对秒杀开始时短暂的突发流量，可能导致用户体验不佳（感觉系统“慢吞吞”）。

2. 令牌桶算法（Token Bucket）

   • 特点：以恒定速率生成令牌放入桶中，请求需获取令牌才能通过。允许短时间内消耗桶内积累的令牌，从而处理突发流量。
   • 秒杀适用性：允许系统在活动开始瞬间处理一波高峰请求，更符合秒杀“瞬时爆发”的业务特征，通常是更优选择。

高阶场景与避坑指南

在阐述完整漏斗模型后，可能需要应对更深入的挑战。

挑战一：单机限流导致集群流量不均？

• 问题：如果负载均衡不均，可能导致某些实例负载过高触发限流，而其他实例闲置，使得整体通过量低于预期。
• 应对：在秒杀场景下，系统存活优先级高于绝对的流量控制精度。可以通过优化负载均衡策略（如使用最小连接数策略）来改善分布。同时，接受微小的精度误差，以换取整个集群的稳定性。

挑战二：最终层的Redis热点Key写入压力依旧很大？

• 问题：即使只有几千QPS对同一个Key进行写操作（扣库存），Redis的单线程模型也可能成为瓶颈。
• 应对：采用 “本地售罄标记” 策略。当某个商品的库存通过Redis扣减至零后，将“售罄”状态通过消息中间件或配置中心广播给所有应用实例。实例在本地内存（如一个AtomicBoolean）中缓存此标记。后续请求在应用层直接检查本地标记，若已售罄则立即返回失败，无需再访问Redis。这样，Redis仅需处理库存售罄前最后的有效请求，后续海量无效流量被高效拦截在Java应用层。

挑战三：如何防止恶意脚本刷接口？

• 澄清：限流主要解决“流量过大”问题，而防刷需要解决“恶意请求”问题。两者需结合使用。
• 补充措施：必须在限流层之前，部署风控系统、Web应用防火墙（WAF）、请求指纹识别、复杂动态验证码等手段，从业务逻辑上识别和拦截羊毛党与机器人。

总结

设计秒杀系统的限流方案，关键在于构建一个多层次的防御体系：

1. 否定单点方案：明确拒绝将所有流量直接压向Redis或数据库的简单方案。
2. 推行漏斗模型：遵循从客户端、网关、应用到分布式中间件的层层过滤策略，确保每一层都分担压力。
3. 预备高级策略：针对热点Key等极端情况，准备好如“本地售罄标记”等优化方案，确保系统在极限压力下仍能保持核心服务可用。

秒杀系统的设计目标，并非保证每个用户都能成功下单，而是在面对瞬间流量洪峰时，保障整个平台能够稳定、可控地运行。