摘要
限时秒杀是电商平台拉动销量、提升用户活跃度的核心营销活动，属于典型瞬时高并发业务场景。短时间爆发的海量流量极易击穿后端服务，引发系统超时、库存超卖、服务雪崩等稳定性问题。本文以我参与开发的社区生鲜电商秒杀营销系统为实例，介绍本人作为架构设计师，负责秒杀整体架构规划、高并发方案选型以及落地优化等工作。针对秒杀流量洪峰、库存一致性难保障等痛点，本文围绕扩容、动静分离、缓存、限流、服务降级五大核心技术展开论述，讲解各项技术 "分流‑提速‑减压‑兜底" 的协同方案，阐述项目落地选型难点、应对策略与上线效果，总结秒杀高并发架构设计的实践经验。
正文
一、项目概述
我于 2024 年 4 月‑2024 年 9 月参与了某社区生鲜电商平台秒杀模块的迭代升级项目。平台主要面向周边社区居民售卖生鲜果蔬、日用商品，注册用户约 300 万，每周定期开展 3‑5 场限时秒杀活动。改造前秒杀业务和普通下单业务耦合在单体项目中，所有抢购请求直接访问 MySQL 数据库。在上次周年大促秒杀活动中，开场瞬间大量用户同时下单，数据库压力陡增，接口大面积超时，还出现了库存超卖，平台被迫补发优惠券安抚用户，造成了一定的经济损失和口碑下滑。
本次项目目标就是重构秒杀业务架构，搭建一套高可用秒杀系统，支撑峰值 5000QPS 的抢购请求，严格保障库存数据一致，做到秒杀流量隔离，不能影响平台其他业务正常运行。我在项目中担任系统架构设计师，主要负责秒杀整体架构方案设计、高并发技术选型、核心模块评审、性能压测以及上线后的调优工作。
二、秒杀场景核心挑战与关键技术方案
秒杀场景核心技术挑战
秒杀业务和普通商品下单业务差异较大，主要面临四项技术挑战。 第一，瞬时流量洪峰冲击。秒杀开启的几秒内，大量用户集中点击抢购按钮，访问流量瞬间暴涨数十倍，远超系统日常负载，很容易压垮后端服务。 第二，库存超卖风险。库存属于共享资源，当多个请求同时读取到剩余库存大于 0，就会并发执行扣减操作，最终实际下单量大于商品库存，引发超卖事故。 第三，数据库性能瓶颈。数据库磁盘 IO、连接数资源有限，如果每一条抢购请求都访问数据库执行库存查询与扣减，高并发场景下数据库很快就会到达性能上限，成为整个系统最大短板。
针对以上问题，我们选用扩容、动静分离、缓存、限流、服务降级五大技术，按照分流‑提速‑减压‑兜底的分层防护思路，构建秒杀高并发架构。
扩容
扩容是提升系统并发能力最基础的手段，分为垂直扩容与水平扩容。 垂直扩容即升级单台服务器硬件配置，增加 CPU、内存资源。但垂直扩容存在硬件天花板，成本高，无法长期应对流量上涨。 水平扩容也就是横向扩展，新增多台秒杀应用实例，通过网关负载均衡，将流量分发到不同节点分摊压力。
动静分离
动静分离主要实现前端流量的第一层分流。我们将秒杀页面资源划分为静态资源与动态请求。 图片、页面样式、商品介绍等不经常变动的静态资源，提前放到 CDN 分发节点。用户访问秒杀活动页面时，直接从就近的 CDN 节点加载页面资源，请求不会到达后端业务服务器。 只有用户点击抢购按钮提交下单这类动态请求，才转发至后端秒杀服务。动静分离拦截了绝大多数页面浏览流量，大幅减少后端收到的请求数量，实现前端分流减压。
缓存
缓存是秒杀提速减压的核心手段，项目中我们选用 Redis 分布式缓存存放热点商品库存。 秒杀预热阶段，运营人员开启活动前，后台程序提前将秒杀商品库存加载进 Redis 缓存。用户发起抢购时优先在缓存层完成库存预扣减。Redis 基于内存运行，读写性能优秀，可以轻松承载上万次并发请求，把绝大多数流量拦截在缓存层，避免请求直达数据库。 为了防止并发扣减库存出现超卖，我们使用 Lua 脚本封装库存判断、扣减逻辑，保证两条操作原子执行。库存扣减成功之后，发送消息至消息队列异步生成订单，再异步扣减 MySQL 数据库库存，进一步削峰填谷，减轻数据库压力。缓存起到提速、减压的核心作用。
限流
即使经过 CDN 分流、缓存过滤，依旧会有大量抢购请求到达后端服务。一旦请求量超过系统处理上限，系统就有崩溃风险，所以必须引入限流机制，主动拦截超额流量。 项目中我们在网关层基于 Sentinel 组件，采用令牌桶算法实现限流。一方面针对单用户设置频率限制，防止恶意用户高频刷接口；另一方面对秒杀接口设置全局 QPS 阈值。当并发请求超过阈值，系统直接快速返回 "抢购繁忙，请稍后重试"，拒绝多余请求。限流属于主动减压的防护手段，避免系统被突发流量打垮。
服务降级
服务降级属于秒杀架构最后的兜底防护策略。当流量超出预期峰值，系统资源紧张的时候，主动关闭秒杀链路中非核心业务，释放服务器资源保障下单主流程优先运行。 秒杀核心业务链路为：用户资格校验‑扣减库存‑生成订单。而抢购成功推送营销短信、赠送积分、商品推荐等功能属于非核心附属业务。流量高峰期，我们暂时关闭这类非核心功能，等系统压力回落之后再恢复。即便后续出现部分附属功能短暂不可用，也不会影响用户抢购下单的核心体验。
多项技术的协同逻辑
五大技术形成一条层层防护的完整链路：动静分离在前端实现流量分流；扩容提升后端集群处理上限；缓存承担高并发读写，提升接口响应速度，减轻数据库压力；限流拦截超额流量，削峰减压；服务降级作为兜底防护，保障核心业务可用。各项技术相互配合，共同抵御秒杀瞬时高并发带来的风险。
三、项目落地选型难点、应对措施与实施效果
选型思路
在方案选型阶段，我们优先选择水平扩容方案，方便后续根据活动流量弹性伸缩；静态资源交由商用 CDN 处理，实现动静分离；缓存中间件对比 Memcached 与 Redis，由于 Redis 支持 Lua 脚本、集群部署和持久化，更适合库存原子扣减场景，最终选定 Redis 集群；限流、降级能力选用阿里 Sentinel 组件快速实现；使用 RocketMQ 消息队列实现异步下单，隔离缓存层与数据库，进一步削峰。整套架构流量逐层过滤：CDN‑网关限流‑秒杀服务‑Redis‑消息队列‑MySQL，层层拦截无效请求，保护底层数据库。
落地关键难点以及应对措施
项目实施阶段遇到两处关键难点： 第一，Redis 缓存库存与 MySQL 数据库库存数据不一致。Redis 预扣库存成功后，如果消息队列消息丢失，数据库库存无法同步扣减，就会造成两边库存数值不一致。我们增加库存定时校验任务，定时比对 Redis 与 MySQL 库存，发现偏差自动补偿；同时开启消息重试、死信队列机制，处理异常失败订单，最终实现库存数据最终一致性。 第二，热点商品缓存击穿风险。秒杀商品缓存过期瞬间，海量请求同时穿透缓存打到数据库。我们采取秒杀库存缓存永不过期策略，库存数值变更时主动更新缓存，彻底规避缓存击穿问题。
实施效果
系统上线后先后支撑 10 场限时秒杀营销活动，峰值 QPS 达到 4800，整体运行平稳。页面平均响应时间下降至 150ms 以内，彻底杜绝库存超卖问题；秒杀流量被完全隔离，没有再出现秒杀业务拖垮其他业务的故障；页面报错率从改造前 26% 下降至 0.8%，用户抢购体验得到明显改善。
通过本次生鲜电商秒杀系统改造项目，我意识到秒杀高并发架构不能依靠单一技术解决问题，而是一套分层防御、多项技术协同配合的综合方案。