之前的文章中我们已经演练了缓存的三种“招式”：用读缓存化解数据库查询压力，靠写缓存扛住流量洪峰，再通过消息队列从容同步数据。这套组合拳——先缓冲、再异步、平稳落库——正是接下来面对真刀真枪的秒杀场景时，我们要继续运用的核心战术。
1 业务场景：设计秒杀架构必知必会的那些事
想象这样一个场面：某天，公司决定拿出100件“骨折价”商品，在10月10日晚上10点10分准时开抢。而这时候，平台已经坐拥几千万用户，哪怕只吸引来几十万想捡便宜的，也意味着 —— 开抢那一两秒，流量会像演唱会放票般瞬间冲顶，之后秒光，只剩“已售罄”的页面迎接后来者。
更“刺激”的是，领导发话：这是个临时活动，服务器不能大动，架构别大改，要求我们“精打细算”地接住这股洪流，别让系统被冲垮。
所以问题来了：如何用最小代价，设计一套秒杀架构？
核心原则其实就这四条，咱们得牢牢守住：
货不能多卖——说好100件就100件；
订单不能丢——抢成功的必须算数；
系统不能挂——服务器和数据库得稳住；
尽量防住机器人——把货留给真人用户。
那具体怎么实现？咱们接下来就聊聊整体设计思路。
2 整体思路
秒杀架构的本质，就像一个精心设计的“流量漏斗”——它的核心策略是层层设卡，逐级过滤，让越多的请求在上游就被消化或拦截，尽量不让压力渗透到系统底层。
从架构分层的视角看，我们的目标很明确：把请求尽可能拦在上游，别放它往下游冲。系统越靠下游，往往越脆弱、越昂贵，保护数据库和核心服务是重中之重。
那具体怎么拦？不能光靠想象。因为秒杀本身是一连串用户操作（浏览、点击、下单、支付…），所以必须结合完整的业务流程来设计拦截点。每一个用户动作，都是一个可能设防的关卡。下图更直观地展现这个“何处设卡、如何引导”的过程，
接下来就按照秒杀系统的业务流程，来一步步讲解如何将请求拦截在系统上游。
2.1 浏览页面如何将请求拦截在上游
踩过坑才懂，设计秒杀时就算算力绰绰有余，也千万别忽略一个隐形杀手——带宽。我们曾有一个活动，上线后监控一切正常，唯独出口带宽被瞬间占满，结果页面卡成“PPT”，用户体验一落千丈。
吃一堑长一智，从那之后我们学乖了：所有静态资源一律走 CDN，PC 网站也必须做前后端分离。简单来说，CDN 就是把你的图片、样式等文件缓存到全国各地的节点服务器上，用户访问时，由 CDN 智能调度到最近的节点返回资源，又快又省自家服务器的流量和带宽。
这样一来，静态请求的压力基本被挡在系统之外。那么动态请求怎么处理？这里有三种常见思路：
动态数据静态化
比如商品详情、评论等，可通过 JavaScript 动态获取。更好做法是：直接生成静态页面推送到 CDN；如果改造量大，至少放进 Redis。个人更倾向走 CDN，彻底分离压力。
秒杀时间判断轻量化
页面上通过 JS 获取服务器时间来控制“立即抢购”按钮的可用状态。这个“获取时间”的请求完全可以放在负载均衡或静态资源层处理，不必进入业务后台。
结束标识前置校验
在 Cookie 或前端存储中记录秒杀是否结束。如果未结束，请求才会进入后台，后台再依次检查本地内存 → 缓存，确认活动状态。这样可以避免无效请求。
总结一下原则：
用户浏览类行为，尽量在 CDN、静态服务或负载均衡层完成拦截；实在不行，也必须在缓存层解决，绝不轻易放行到下游数据库。
2.2 下单页面如何将请求拦截在上游
好，我们直击秒杀最核心的战场——下单与提交。这里的设计，直接决定系统是平稳着陆还是瞬间崩塌。
第一关：下单页面的“防刷”策略
为了防止“黄牛”或爬虫直接刷爆下单页，我们设下两道防线：
动态URL，绝不提前暴露
活动开始前，下单页面的真实地址是“机密”。页面只在秒杀开启瞬间，由前端JS向后台动态获取。想提前刷？门儿都没有。前面介绍了JS可以用来判断秒杀开始时间，秒杀时间一到，它便可以通过另一个请求获取这个URL。
按钮“一击即废”
用户点击“购买”后，按钮立即变为不可用（Disable）。简单粗暴，有效防止疯狂连点给后台送“人头”。
第二关：提交订单——流量漏斗的终极过滤
页面展示可以用CDN扛，但提交订单涉及复杂逻辑与数据一致性，是整套架构的“心脏”。原则是：在请求抵达数据库前，层层设卡，能拦则拦。
（一）网关层：第一道也是最狠的防线
目标：用最小代价，在系统最外围拦截掉95%以上的无效或恶意流量。主要三板斧：
用户限频：比如同一用户每5秒只能提交一次。
IP限频：防止机器人集群攻击，但需谨慎避免误伤真实用户（例如同一公司出口IP）。
总量限流：采用漏桶/令牌桶等算法，严格控制每秒进入后台的请求数量。
前两种限制比较简单，在nginx上就能快速完成配置，第3种限流方式也不复杂，相关的原理在后面的
（二）后台服务器：精准处理与数据保卫战
能到达这里的请求已是“幸运儿”，我们的目标转为：保证不超卖、不丢单。
库存决胜在缓存
商品库存提前预热至Redis。下单时，使用 decr 进行原子性扣减：
扣后结果≥0：秒杀成功，进入创建订单流程。
扣后结果<0：秒杀失败，立即用 incr 回滚库存。
关键约定：秒杀期间，禁止任何其他途径修改库存（如后台编辑），通过业务流程保障缓存作为“唯一真相源”。
订单先写缓存，异步落库
为保护数据库，订单创建后先写入Redis。用户进入“等待页面”，前端轮询查询结果。后台则：
优先查Redis订单。
若Redis没有，说明已异步持久化到数据库，再去库中查询并返回给用户。这套流程与“写缓存”章节思路一脉相承。
批量落库与库存同步
独立进程定期（如每100毫秒）将缓存中的订单批量插入数据库，并同步扣减数据库库存。实现数据最终一致性。
极端情况：Redis挂了怎么办？
幸亏网关层已经挡住了大部分流量，进入后台的请求不多。此时预案很简单：
读/扣库存失败：直接降级到数据库，在数据库中完成库存校验与扣减。
写订单缓存失败：直接写入数据库，跳过批量落库环节。
系统虽性能下降，但功能依然可用，保障了基本业务。
总结一下：秒杀提交的设计，是外围狠心限流与内部精心守护的结合。核心思想是：利用缓存扛住并发读写，通过异步化解耦压力，最终以可控的流量与数据库平稳交互。只要守住不超卖、不丢单的底线，这场战役就赢了九成。
2.3 付款页面如何将请求拦截在上游
来到付款环节，请求的洪峰早已在之前层层关卡被充分过滤。此时的重点不再是拦截，而是稳妥地完成交易闭环。
核心就两件事：
确保最终一致性：支付状态、库存、订单数据必须准确同步。（数据一致性具体如何实现，我们留到后续章节深入探讨。）
处理好订单取消：若发生超时未支付等业务取消逻辑，务必记得将释放的库存，同时回补至数据库和 Redis。这一步是防止资源被“锁死”的关键，相当于把回收的“弹药”重新填回弹舱。
至此，秒杀流程从流量过滤到交易完结，形成一个完整且有韧性的闭环。
2.4 整体服务器架构
要构建真正扛得住秒杀的“铁桶阵”，高可用设计必须贯穿每一道防线。如图上所示，从上到下，每一层都不能是单点。简单来说，你需要：
前置防线集群化：静态资源服务器、网关、后台服务，统统通过负载均衡来部署，让流量“雨露均沾”，任何一台实例挂掉都无缝切换。
核心存储分布式化：缓存（Redis）和数据库（DB），必须采用集群模式。数据分片、主从备份、故障自动切换（Failover），一个都不能少，这是系统不垮的基石。
别忘了“幕后英雄”MQ：虽然前面的分层设计里它没直接出场，但服务间异步通知、流量削峰都离不开它。消息队列本身也要高可用配置——主从、分片、故障转移机制都得安排上，确保消息不丢、服务不中断。
层层设防，环环相扣，才是高可用的精髓。
3.小结
好了，关于秒杀架构的核心要点，我们已从头到尾梳理了一遍。由于很多策略在前面的“缓存实战”中已有铺垫，本章更像一次聚焦的综合应用。
为了方便你后续设计与自查，我将关键注意事项整理为一份 《秒杀系统设计Checklist》 ，供你参考：
流程 事 项
浏览页面 静态资源放CDN
浏览页面 秒杀期间的一些动态数据请求放入静态页面
浏览页面 秒杀开始的时间获取依赖服务端
浏览页面 秒杀结束的标识放在各个地方
下单页面 下单URL动态后台获取
下单页面 购买按钮点击后置灰（Disable） 网关从3个方面过滤请求
下单页面 1）用户访问频率 2）IP访问频率 3）整体流量控制
下单页面 库存放在Redis 中，在每次下单操作中判断其是否为0，以防止超卖
下单页面 订单先入缓存再批量落库
付款页面 订单取消时记得将商品量加回数据库和Redis 中的库存
服务器架构 静态资源服务器负载均衡
服务器架构 网关负载均衡
服务器架构 后台服务器负载均衡
服务器架构 Redis 集群
服务器架构 MQ集群
服务器架构 数据库集群
此外，还有三个重要话题我们将在后续章节展开：
服务雪崩防护——万一某个服务挂掉，如何避免连锁反应？（后续讲熔断的时候详细讲解）
网关限流实战——具体如何配置与实现？
支付数据一致性——怎样确保交易闭环严谨可靠？
这三点每一点都需要细致考虑，将在后续文章中详细讲解。
这次架构上线后，我们通过多方监控与数据核对，验证了库存与订单完全匹配，系统运行平稳。这与此前一段“血泪史”形成鲜明对比：早期我们曾设计“保证前100名下单成功”的方案，不做限流，结果后台压力巨大且体验不公——毕竟网速和手速并非公平竞技，普通用户很难拼过“专业选手”。如今通用做法是在网关层做科学限流，让系统在可控压力下随机公平处理请求。有些方案在前端JS随机丢弃请求，虽也算“限流”，但属于不可靠的“小聪明”，应尽量避免。
秒杀场景至此告一段落。接下来，我们将进入下一部分：基于常见组件的微服务场景实战，从最简单的服务治理开始，由浅入深，一步步拆解微服务的核心知识与实践。
为您推荐
