秒杀系统设计可遵循分层过滤、层层限流的核心思路应对瞬时流量冲击。前端流量过滤浏览器和 App 端秒杀开始前按钮置灰点击一次即禁用页面动静分离静态数据提前推至 CDN商品详情页提前渲染仅留秒杀按钮到点亮起。网关层限流采用令牌桶算法每秒仅放行 1 万个请求多余请求返回活动提示设置黑名单对短时间内重复请求过多的 IP 或用户 ID 进行临时拉黑。业务层扣库存秒杀前将库存预热加载至 Redis用 Lua 脚本完成判断库存与扣减的原子操作Redis 扣减成功仅代表用户获得下单资格。消息队列削峰Redis 扣减成功后将下单消息送入消息队列给用户返回排队提示订单服务从队列取消息后再创建订单、扣减数据库库存。额外加分要点添加验证码或预约码防刷设置超时回退库存、对账任务保证数据一致性秒杀时降级非核心服务活动前完成缓存预热与全链路压测。秒杀系统设计本质是逐层过滤、快速失败的架构以小部分成功请求保障系统稳定。部分摘抄tcilay秒杀系统技术拆解从架构设计到落地优化的全流程指南https://cloud.tencent.cn/developer/article/25704381.1 秒杀系统的核心难点秒杀场景的本质技术挑战是用常规系统应对非常规流量:当10万用户在10秒内同时抢购100件商品时常规业务系统会瞬间陷入页面卡死、订单超卖、数据错乱的困境。秒杀系统的设计目标可以概括为三大难点:瞬时高并发流量峰值是日常的100-1000倍例如某电商大促秒杀QPS可从日常500飙升至50万数据一致性需解决库存超卖库存100却被下单120和订单重复创建恶意请求防御黄牛脚本、秒杀器占用大量资源需确保系统稳定。面试加分点可补充淘宝双十一的真实数据——前端峰值有效请求约60w QPS后端Cache集群峰值近2000w/s最高下单减库存TPS达到1500/s。1.2 四层漏斗架构模型秒杀系统的核心架构思想是分层拦截流量层层过滤从前端到数据库形成流量漏斗:全部请求 → 合法性校验 → 库存校验 → 频率控制 → 实际下单 100万 50万 10万 5万 1万每一层都将绝大多数的无效流量拦截在外最终只有极少量有效请求打到数据库。第一层:客户端前端层页面静态化 CDN加速:将商品详情、图片、样式等静态资源全部缓存在CDN节点用户访问时直接从就近CDN获取。90%的静态数据无需请求服务端秒杀时用户仅需点击刷新抢宝按钮交互数据量减少3倍以上按钮防刷控制:活动开始前按钮置灰无法点击点击后立即禁用按钮并限制时长后才能再次点击人机验证:加入答题验证或滑动验证防止秒杀器脚本同时将下单峰值从1秒延长到2-10秒将秒杀器下单比例降至5%以下。第二层:接入层负载均衡:采用Nginx或云服务商的负载均衡服务如阿里云SLB将流量均匀分发到多个应用服务器流量控制:通过令牌桶算法或漏桶算法限制单IP或单用户的请求频率如每秒最多5次某电商平台配置后无效请求占比从60%降至15%独立域名部署:秒杀申请单独的域名将请求分流到不同的集群中与常规业务做系统隔离。第三层:业务服务层服务拆分独立部署:将秒杀模块独立为单独的微服务集群与常规业务服务订单、支付隔离部署避免秒杀流量影响其他业务异步化处理:用户抢购点击后不直接调用数据库下单而是将请求发送到消息队列RocketMQ/Kafka由消费者异步处理下单逻辑无状态服务设计:秒杀服务集群保持无状态便于水平弹性扩容阿里在双十一期间可实现Kubernetes分钟级扩容1000个Pod。第四层:数据层缓存优先:使用Redis集群存储热点数据库存预热、用户抢购记录命中率高减轻数据库压力读写分离:主从数据库部署查询走从库减轻主库压力分库分表:秒杀相关表秒杀商品表、秒杀订单表独立部署与常规业务表分库分表同时对订单表的用户ID商品ID建立联合索引。1.3 核心技术实现方案方案1:流量削峰与限流层级关键技术作用前端答题机制延缓峰值下单请求从1s延长到2-10s接入层NginxLua限流单IP限频拦截大量无效请求服务层消息队列异步解耦RocketMQ实现削峰填谷数据层降级策略系统容量达到瓶颈时关闭非核心功能面试加分点可补充在RPC框架中将部分服务节点设置成秒杀组实现分组隔离不让1%的秒杀请求影响其他99%的正常业务。方案2:库存扣减与超卖防止在大厂秒杀实践中超卖问题通过三级防御层层递进实现Redis预减Lua原子保证lualocal stock redis.call(get, stock:1001) if stock and tonumber(stock) 0 then redis.call(decr, stock:1001) return 1 -- 成功 end return 0 -- 库存不足执行期间不会被其他命令抢占从根本上杜绝超卖。数据库乐观锁兜底UPDATE products SET stock stock - 1, version version 1 WHERE id ? AND stock 0 AND version ?消息队列异步同步Redis预扣减成功后发送MQ消息消费者批量更新数据库库存实现最终一致性。死锁处理加锁顺序保持一致先主键后唯一索引基于主键或唯一索引更新数据。MySQL自动检测死锁并回滚其中一个事务通常为更新行数最少的事务。方案3:全局唯一ID生成秒杀场景中数据库自增ID不足分库分表后无法保证全局唯一自增ID容易暴露业务量。推荐方案:Redis自增 日期前缀javaString key order:id: LocalDate.now(); Long id redisTemplate.opsForValue().increment(key);生成的ID示例:20250421 000001全局唯一、趋势递增。其他方案:雪花算法(Snowflake时间戳机器ID序列号)或数据库号段模式一次取一批ID到本地缓存。方案4:热点隔离分库分表策略当数据量激增时分库分表是关键。秒杀系统需实现三层次隔离业务隔离:秒杀作为独立营销活动提前预热已知热点系统隔离:通过分组部署与90%常规业务分开单独域名独立集群数据隔离:热点数据启用独立cache集群或MySQL数据库防止0.01%的数据影响99.99%的业务。1.4 数据一致性保障场景解决方案实现方式库存超卖Redis原子扣减 数据库乐观锁三级防御架构确保数据一致性重复下单分布式锁 唯一约束(用户商品)「一人一单」逻辑使用Redisson或Lua脚本保证原子性缓存与DB不一致延迟双删策略 消息队列异步同步Redis库存预减后MQ异步通知同步到数据库MQ消费失败死信队列 人工干预 库存回滚若数据库写入失败要求回滚Redis库存保持最终一致性面试常见追问与回答思路Q1: 我们公司不用这些大厂技术栈怎么办A: 中小项目最小可用方案:前端按钮置灰限点击频次 Nginx单IP限频 Redis(Lua)扣库存 MQ异步下单 数据库乐观锁兜底。用最少的代码实现核心秒杀功能符合80%业务场景需求。Q2: 缓存穿透/缓存雪崩怎么处理A: 穿透对空结果缓存一个短时间标记(1分钟)雪崩设置不同的key过期时间(随机偏移)同时高可用部署Redis Cluster。热点数据手动预热。Q3: 超卖防止的逻辑能用纯数据库实现吗A: 纯数据库乐观锁可实现但性能极低仅适合并发不高的场景。大促高并发(1000QPS)必须用RedisLua原子扣减 RabbitMQ异步处理用缓存和消息队列解决并发瓶颈。缓存穿透用户请求“不存在的商品”如商品 ID99999缓存和数据库都无数据导致请求直接打向数据库。解决方案用布隆过滤器Bloom Filter在缓存前过滤无效商品 ID不存在的 ID 直接返回同时对不存在的商品在 Redis 设置“空值缓存”如SETEX seckill:stock:99999 60 0避免重复请求数据库缓存击穿某热门商品的缓存过期瞬间大量请求打向数据库。解决方案对热门商品设置 “永不过期” 的本地缓存Caffeine同时 Redis 缓存过期前 10 分钟通过定时任务主动更新缓存或用 “互斥锁”当缓存失效时只允许 1 个线程查询数据库并更新缓存其他线程等待缓存雪崩大量缓存同时过期或 Redis 集群故障导致所有请求打向数据库。解决方案缓存过期时间加 “随机值”如基础过期时间 1 小时加 0-30 分钟随机值避免同时过期Redis 采用集群架构如 3 主 3 从避免单点故障同时配置 “缓存降级”当 Redis 不可用时直接返回 “活动繁忙请稍后再试”不请求数据库。Q4:防作弊识别 “真人” 与 “脚本”黄牛脚本的危害不仅是 “抢走商品”还会占用大量带宽和服务器资源需从 “设备、行为、数据” 三个维度防控设备指纹识别通过前端采集用户设备信息如浏览器 UA、屏幕分辨率、操作系统版本、设备唯一标识生成 “设备指纹”。若某设备指纹短期内多次请求或与黑名单指纹匹配直接拦截行为分析真人用户的操作有 “时间间隔” 和 “正常轨迹”如先浏览商品、再加入购物车、最后抢购而脚本是 “瞬时连续点击”。通过后端分析用户行为若从进入页面到点击抢购的时间1 秒或同一用户 1 分钟内点击抢购10 次标记为疑似作弊要求完成 “滑块验证码” 或 “图文验证码”黑名单机制将历史作弊用户如用脚本下单的用户、多次取消秒杀订单的用户的 ID、IP、设备指纹加入黑名单后续请求直接拒绝。某平台通过黑名单机制减少了 40% 的作弊请求。Q5:性能优化让系统 “更快、更稳”1. 代码层面优化减少 IO 操作避免在秒杀核心流程中调用外部接口如用户积分查询、物流接口非核心逻辑异步处理线程池优化应用层使用自定义线程池核心线程数设为 “CPU 核心数 1”最大线程数控制在 200 以内避免线程过多导致上下文切换耗时避免锁竞争核心代码块如库存扣减尽量减少同步锁范围用 “CASCompare and Swap” 替代 synchronized 锁减少锁等待时间。2. 数据库层面优化分库分表对秒杀订单表按 “用户 ID 哈希” 分库按 “创建时间” 分表如每月一张表避免单表数据量过大建议单表数据量控制在 1000 万以内禁用事务秒杀下单流程中若无需多表操作禁用数据库事务事务会加行锁影响并发用 “最终一致性” 替代强一致性批量操作若需批量处理数据如批量更新库存用UPDATE ... IN语句替代循环单条更新减少数据库连接次数。3. 消息队列优化队列分区将秒杀订单消息按 “商品 ID 哈希” 分配到不同队列避免单队列拥堵消费端扩容根据秒杀流量预估提前扩容消息队列消费端实例数确保消费速度大于生产速度死信队列对消费失败的消息如数据库暂时不可用放入死信队列定时重试避免消息丢失。Q6:容灾与监控确保 “故障可发现、可恢复”1. 容灾策略降级策略当系统 QPS 超过阈值如预设的 50 万 QPS或核心服务如 Redis故障时触发降级关闭 “商品详情页评论”“相关推荐” 等非核心功能只保留 “抢购” 核心流程甚至对部分用户返回 “限流提示”如 “当前人数过多请稍后再试”确保核心功能可用熔断机制用 Sentinel 或 Hystrix 监控服务调用情况当某服务如支付服务调用失败率超过 50%自动熔断暂时停止调用该服务返回默认结果如 “支付暂时不可用请稍后重试”避免连锁故障多活架构将秒杀系统部署在多个地域的机房如华东、华北通过 DNS 解析将用户流量引导到就近机房若某机房故障自动将流量切换到其他机房实现 “异地多活”。2. 监控告警核心指标监控用 PrometheusGrafana 监控 QPS、响应时间、错误率、库存剩余量、消息队列堆积数等指标设置阈值告警如 QPS 超过 50 万、错误率超过 1% 时通过短信 / 邮件告警全链路追踪用 SkyWalking 或 Zipkin 追踪秒杀请求的全链路接入层→应用层→数据层快速定位耗时节点如某环节耗时超过 100ms日志分析用 ELKElasticsearchLogstashKibana收集系统日志实时分析 “超卖日志”“作弊请求日志”“缓存失效日志”及时发现异常。实战案例某电商秒杀系统的技术落地某电商平台在 618 大促中针对 “1 元秒杀手机” 活动设计了秒杀系统核心技术选型与效果如下架构选型接入层NginxCDN、应用层Spring BootSentinel、数据层Redis ClusterMySQL 分库分表、消息队列Kafka核心优化Redis 三级缓存本地 Caffeine 分布式 Redis 数据库、Redlock 分布式锁、布隆过滤器防穿透、设备指纹 行为分析防作弊最终效果成功承载 80 万 QPS 的瞬时流量系统响应时间稳定在 150ms 以内库存超卖率为 0作弊订单占比低于 3%无任何服务宕机情况。#如何系统性回答“秒杀系统设计”这类面试题的完整框架在面试中要体现从“全链路”和“分层隔离”的视角来拆解问题层层递进地给出一个高内聚、低耦合的架构方案。 面试的核心思路分而治之层层过滤设计秒杀系统的核心并非追求某个单一技术的极致而是遵循“分而治之层层过滤”的原则。这个过程的最终目标是将尽可能多的无效请求拦截在最上游只让极少数真正能成交的请求以可控的方式透传到下游数据库。️ “全链路”五层防御体系一个完整的回答通常会从下到上从最基础的代码层面开始逐层构建一个稳固的“防御体系”。这套体系为我们从面试官的角度梳理了一个相当清晰的回答结构第一层防线前提——数据与接口的一致性保障回答时先阐明这部分是基石。核心技术点包括使用Redis预减库存扛住高并发并配合Lua脚本或分布式锁保证扣减的原子性同时通过唯一索引或Token机制确保接口幂等性。第二层前端与网络层第一道闸门接着往上走来到直面用户的第一道防线。核心策略是极致压缩动态请求可以利用页面静态化 CDN加速拦截绝大部分流量同时在用户操作上做文章比如抢购按钮置灰控制和加入简单验证码。第三层接入层第二道闸门流量到达后端前的第二道闸门。可以在Nginx等网关层进行IP级别的限流如令牌桶/漏桶算法并通过黑名单机制直接拦截恶意或刷单的IP有效减轻下游压力。第四层业务逻辑层核心战场穿过层层闸门后这里是真正的核心战场。继续使用Redis预减库存进行高效拦截配合Lua脚本的原子性操作保障数据一致。通过将下单等请求发送至消息队列异步处理实现削峰填谷。同时还可以引入服务熔断与降级在高负载时保障核心下单链路。第五层数据层最终防线负责最终的数据持久化。通过数据库乐观锁或悲观锁做最后的库存检查并利用唯一索引彻底防止超卖和重复下单。
