秒杀系统的业务架构与流量架构本文是「10Wqps 秒杀架构」系列的第一篇聚焦秒杀系统的业务特征和流量模型——这是所有架构决策的起点。后续文章将逐一展开缓存、异步、高可用等核心技术方案。一、开篇假设你负责一个日活 6000 万的电商平台运营团队策划了一场秒杀活动某款热门商品以市场价 3 折限量 10 万件发售活动时间定在上午 10:00。活动开始前三分钟已有 200 万用户停留在活动页面反复刷新。10:00 整点下单请求瞬间涌入——QPS 峰值达到 20000。这就是典型的秒杀场景。而设计一个能扛住 10Wqps 的秒杀系统第一步不是选型中间件而是理解秒杀的业务特征和流量特征。只有把这两个问题吃透了后续的缓存、异步、高可用方案才有据可依。本文从三个维度拆解第一秒杀的业务架构——包括业务特点、前端控制、验证码机制第二秒杀的流量架构——包括流量突刺模型、QPS 漏斗预估、二八定律和全链路压测第三将这些分析转化为架构设计的约束条件。二、问题拆解2.1 秒杀为什么难秒杀活动具备六个核心特征每一项都对系统提出了不同维度的挑战特征描述架构挑战时间紧迫活动窗口通常仅几分钟到半小时必须在极短时间内完成所有下单处理数量有限商品数量远少于用户数如 10 万 vs 200 万大量无效请求需要在前置层拦截价格极低远低于市场价甚至低于成本价羊毛党、黄牛、恶意刷单的防控压力竞争激烈用户使用抢购软件、多设备同时操作需要防脚本、防自动化攻击营销效果强活动期间流量是平时的 10-50 倍系统需要弹性伸缩能力社交传播秒杀信息在社交媒体快速扩散流量预测难度增加突增更剧烈这六个特征叠加在一起形成了一个瞬时高并发、海量无效请求、强一致性要求的混合挑战。传统的同步架构在这种场景下会直接崩溃——但这属于后续异步架构篇的范畴。2.2 用户端的第一道防线秒杀的请求洪流中相当一部分是无效请求——活动未开始的、已经抢完的、重复提交的。如果这些请求全部打到服务端资源浪费是灾难性的。因此在客户端就需要构建三道防线第一道秒杀按钮的生命周期管理大部分用户会在活动开始前就进入页面此时秒杀按钮是置灰、不可点击的。这里的核心问题是静态页面如何感知秒杀开始时间答案是exposed-key 机制。秒杀未开始时后端不暴露下单 URL页面上的按钮处于禁用状态。到了秒杀时间点系统定时任务生成一个具备时效性的exposed-key前端通过动态 JS 异步获取该 key验证通过后才点亮按钮并露出下单 URL。[时间轴] 09:55 用户涌入活动页 → 按钮置灰URL 不可见页面为静态 HTML缓存在 CDN 10:00 系统生成 exposed-key → JS 异步获取 → 按钮点亮 → URL 可见 10:00 用户点击下单 → 按钮再次置灰60 秒内不可重复点击第二道前端频率控制用户点击下单后按钮立即置灰60 秒内不可再次点击。这由前端定时器控制本质是将重复请求拦截在用户浏览器内。即使有用户尝试绕过前端限制直接调用接口服务端还有独立的限流机制将在高可用篇详述。第三道URL 延迟暴露秒杀 URL 在活动开始前不呈现于 HTML 源码中而是通过 JS 文件在活动开始时动态注入。这能有效防止脚本在活动前批量抓取 URL 并提前构造请求。2.3 验证码比限流更精准的防刷手段限流可以控制请求频率但存在误杀风险——正常用户快速点击也可能触发限流。验证码则不同它直接区别人和机器几乎不存在误杀。秒杀场景下验证码的设计要点一次性使用同一验证码只允许使用一次防止重放攻击。类型选择普通数字/字母验证码生成快但安全性低易被 OCR 破解移动滑块验证码虽然生成稍慢但安全性显著更高是目前主流电商平台的首选。位置放置验证码校验应放在请求链路的早期——在库存扣减之前避免恶意请求消耗缓存和数据库资源。三、核心方案流量架构3.1 秒杀的流量特征瞬时凸峰秒杀流量不是均匀的而是呈现出鲜明的流量突刺Traffic Spike特征流量 ↑ | █ | █ | █ ← 秒杀开始瞬间10Wqps | ____ █ | / \ █ |_____/ \_______█__________→ 时间 预热期 ↑ 活动结束 秒杀开始以某米秒杀系统为例活动前09:50-09:59访问量平稳10:00 整点并发量瞬间飙升可达平时的 50-100 倍。这个峰值持续时间极短——因为商品通常在几秒内售罄用户收到已抢完提示后迅速离开。这个特征与 12306 春运抢票高度类似平时流量平稳节假日瞬间激增。两者的共同应对策略是不在峰值段做重操作——异步、削峰、前置拦截。3.2 QPS 漏斗模型一个真实的秒杀请求从浏览器到数据库会依次经过多个层级。每一层都会过滤掉一部分无效请求形成天然的漏斗形状用户请求总量: 100W qps (进入活动页) ↓ CDN / 静态资源: 90W qps (缓存命中未达服务端) ↓ Nginx 接入层: 10W qps (动态请求到达) ↓ Gateway 限流/认证: 8W qps (限流过滤约 20%) ↓ 业务校验层: 5W qps (黑名单、活动校验过滤约 37%) ↓ Redis 库存预扣: 2W qps (库存不足直接返回) ↓ MQ 异步下单: 5000 qps (预扣成功异步处理) ↓ MySQL 订单入库: 5000 qps (最终落地远低于接入层)漏斗模型的核心价值在于容量规划你需要明确每一层的并发上限并在上游就把超限的请求拦截掉而不是让无效请求层层穿透到底层。各层并发能力参考组件单机/单集群 QPS 上限扩展方式Nginx10W增加节点Tomcat业务服务800-1000增加实例Redis Cluster5W增加分片MySQL主库写1000-2000读写分离 分库分表可以看到Tomcat 和 MySQL 是瓶颈所在所以架构设计的关键就是尽可能减少打到这两层的请求量。3.3 用二八定律做流量预估对于新系统没有历史数据可以参考需要借助二八定律进行粗略估算。基本思路是80% 的流量集中在 20% 的时间窗口内。假设运营团队预估活动期间 UV独立访客为 500 万活动持续 10 分钟600 秒总请求量 ≈ 500 万 × 平均请求数约 5 次/人 2500 万请求二八分布80%2000 万集中在 20% 时间120 秒内峰值 QPS ≈ 2000 万 / 120 ≈ 16.7 万 qps这意味着系统至少需要以 16 万 qps 为峰值做容量规划再根据漏斗模型推导各层需要承载的量级进而确定每层需要多少台机器、多少 Redis 分片、多大的数据库连接池。这种估算不是精确的但它给出了一个数量级参考足够支撑架构选型。3.4 性能压测验证容量规划的唯一手段容量规划是基于经验的推断而全链路压测是验证推断是否正确的唯一手段。压测的关键指标QPS各层实际能承载的请求量是否符合规划响应时间RTP99 延迟是否在可接受范围内秒杀场景通常要求 200ms错误率在峰值 QPS 下的错误率是否 0.1%压测步骤单模块压测先对各组件Nginx、Gateway、业务服务、Redis、MySQL单独施压找到各自的性能拐点。全链路压测模拟真实流量从接入层贯穿到数据层的完整链路。阶梯加压从 1000 qps 开始逐步提升至目标峰值的 1.5 倍观察系统在哪个点出现性能拐点。长稳测试在目标 QPS 下持续施压 30 分钟以上确保系统不会因内存泄漏、连接池耗尽等问题逐渐劣化。全链路压测的核心价值是提前发现瓶颈。如果一个系统从未经过压测就上线应对 10Wqps相当于闭着眼睛开车——不出事故是运气。四、边界与异常4.1 按钮控制被绕过如果用户禁用 JavaScript 或使用抓包工具直接调用下单接口前端按钮置灰形同虚设。因此服务端必须独立实现限流逻辑不依赖前端的约束。4.2 时间同步问题exposed-key 的发放依赖服务端时间。如果服务端时钟不准可能在活动前就发放 key导致提前秒杀。解决方案使用 NTP 时钟同步key 生成逻辑中加入服务器时间的多重校验。4.3 验证码服务不可用验证码服务是秒杀链路的强依赖。如果验证码服务宕机所有正常用户都无法下单。应对方案验证码服务集群部署 熔断降级——当验证码服务不可用时临时降级为纯限流策略确保核心链路可用。4.4 压测结果偏差压测环境和生产环境存在差异网络拓扑、硬件型号、数据量压测结果可能偏高。建议压测结果打 8 折作为容量上限预留 20% 的缓冲余量。五、总结业务特征决定架构方向秒杀的六项业务特征直接推导出对异步、缓存、限流、高可用的需求后续所有技术方案都以此为起点。客户端是第一道防线通过按钮控制、URL 延迟暴露、验证码将大量无效请求拦截在浏览器端降低后端压力。漏斗模型是容量规划的基石Nginx(10W) → Gateway(8W) → 业务层(5W) → Redis(2W) → MySQL(5K)每一层都要明确自己能扛多少、要拦多少。二八定律给出数量级参考峰值 QPS ≈ (UV × 5 × 80%) / (活动时长 × 20%)简单但有效。压测是唯一验证手段没有经过全链路压测的架构方案不能称为设计方案最多只能叫假设。