秒杀活动的基础设施准备

秒杀的难度集中在开抢后的十几秒，之后的流量和平日没什么两样。基础设施准备得好不好，就看这十几秒里系统是在排队消化还是直接躺倒。 先把容量算清楚 备货一千件的活动，有效请求其实就一千多个，其余全是陪跑。活动前做压测：把下单接口压到预期峰值的两倍，观察错误率和响应时间，连接池大小、超时参数照结果调。活动页静态化，图片和脚本走 CDN，让下单接口只接真正的业务请求，入口带宽能省一大半。 队列削峰的落点 请求先进消息队列再处理是标准做法：入口只做校验和入队，立即返回排队中，后端按库存数量放行消费，超出部分直接告知已抢完。队列长度设成库存的一点五倍封顶，后面的请求在入口就拒绝，机器资源不会跟着无效流量一起膨胀。客户端拿排队号轮询结果页，体验上比白屏和报错好得多。 库存扣减防超卖 超卖的根源是先查后改：两个请求同时读到库存剩 1，各自扣减，就卖出两件。扣减必须原子化，缓存里用原子递减，数据库里用条件更新，减出负数就回滚。库存特别热时可以分桶，一个热点键拆成十个子库存轮流扣，争抢立刻缓解。 防刷的三层过滤 第一层在入口：单 IP、单账号限频，超频直接进黑名单。第二层放验证码或答题，把请求在时间轴上打散，顺带挡掉大部分脚本。第三层在业务侧：下单账号要求完成注册时长或消费记录校验，批量注册的小号过不了这一关。 部署上建议临时扩容：平时 4 核 8G，活动日升配或加一台分流，活动结束释放。顺云的高防云服务器 S4 加临时升配足够覆盖中型活动，入口机的防御能力要在活动前确认到位，防刷挡得住人，防不住流量打。 秒杀系统的原则是让多余请求尽早失败，入口拒绝得越早，后面每一层都越安全。