（点个赞，算法会给你推荐更多类似干货 ~ 持续更新中，点关注，看下篇文章）
一、口诀：
秒杀系统要稳准，高可用先记分明；
动静分离 CDN，热点隔离独立群；
削峰靠排队答题，分层过滤漏斗形；
Redis 预扣防超卖，异步落库保性能；
限流熔断加兜底，三高目标准达成。
限流控入口，降级保核心；
熔断隔故障，扩容提能力；
监控加预案，高并发不惧。
设计秒杀系统需满足高可用、一致性、高性能三大目标，核心架构及关键技术如下：
二、架构原则：“4 要 1 不要”
（1）数据要尽量少：
简化秒杀页面（去掉冗余装修），减少传输数据量；系统依赖数据尽量少（如仅依赖库存、用户信息）。
（2）请求数要尽量少：
合并 CSS/JS 文件，减少浏览器额外请求；静态数据（如商品图片）缓存到 CDN，避免重复请求。
（3）路径要尽量短：
合并强依赖应用，将 RPC 调用转为 JVM 内部调用；减少中间节点（如代理服务器）。
（4）依赖要尽量少：
区分强依赖（如库存校验）和弱依赖（如优惠券），弱依赖故障时降级。
（5）不要有单点：
服务无状态化部署集群；存储（Redis、MySQL）多副本备份。
三、核心技术方案
（1）动静分离：
静态数据（商品图片、描述）通过 CDN 缓存，用户直接从 CDN 获取，不经过应用服务器。
动态数据（库存、用户状态）通过 Redis 本地缓存 + 集群缓存，减少数据库访问。
（2）热点隔离：
业务隔离：秒杀作为独立营销活动，卖家单独报名，提前识别热点商品。
系统隔离：秒杀系统独立部署集群，使用单独域名，避免流量影响主系统。
数据隔离：热点商品库存单独存放在 Redis 集群和 MySQL 热点库，与普通商品数据隔离。
（3）流量削峰：
排队：用 RocketMQ 缓冲瞬时请求，异步消费，避免数据库被冲垮。
答题 / 验证码：增加用户操作复杂度（如拼图验证），延缓请求，分散流量峰值。
分层过滤：
CDN 层：拦截 90% 静态资源请求；
前台读系统：用 Redis 过滤无效请求（如已售罄商品）；
后台写系统：二次校验（如用户资格、库存），限流保护；
数据库层：最终一致性校验（如库存不能为负）。
（4）防超卖与性能优化：
库存预扣：秒杀前将库存同步到 Redis，用decr原子操作扣减，返回值≥0 则成功，确保并发安全。
异步落库：Redis 扣减成功后，通过 RocketMQ 异步同步到 MySQL，避免直接写库阻塞。
数据库兜底：MySQL 库存字段设为无符号整数，避免负数；用UPDATE ... WHERE inventory >= xxx确保扣减安全。
（5）高可用保障：
限流：Nginx 层按 IP 限流，应用层按接口 QPS 限流（如令牌桶算法）。
熔断降级：依赖服务故障时，降级为静态页面提示 “活动拥挤”。
兜底方案：预留少量库存，当主系统故障时，手动开启静态页面引导用户，避免全量失败。
四：STAR 法则回答
（1）情境（S）：
电商平台开展 “1 元秒杀手机” 活动，预计峰值 QPS 达 100 万，需保证不超卖、系统不崩溃，支撑 10 万台手机销售。
（2）任务（T）：
设计高并发秒杀系统，满足高可用（99.99% 可用）、一致性（不超卖）、高性能（响应时间 < 500ms）。
（3）行动（A）：
架构设计：
遵循 “4 要 1 不要” 原则，静态资源放 CDN，动态数据用 Redis+MySQL；秒杀系统独立部署集群，与主系统隔离。
流量控制：
用答题验证延缓请求，RocketMQ 缓冲瞬时流量；Nginx 按 IP 限流，应用层用令牌桶算法限制 QPS 为 120 万。
库存处理：
活动前将 10 万台库存同步到 Redis，用户请求时用decr原子扣减，成功后通过 MQ 异步同步到 MySQL；MySQL 库存设为无符号整数，避免负数。
高可用保障：
弱依赖（如优惠券）故障时降级；主系统故障时，启用静态页面引导用户，预留 100 台手动发售。
（4）结果（R）：
活动期间系统稳定运行，QPS 峰值达 110 万，响应时间 < 300ms；成功售出 10 万台手机，无超卖，库存一致性 100%；仅 0.01% 请求因限流失败，用户体验良好。
五：生活例子
类比 “超市限量促销活动”：
- 超市提前贴海报（静态数据 CDN 缓存），只开放一个独立促销入口（系统隔离）；
- 顾客需先领号排队（MQ 排队），中途需填问卷（答题削峰）；
- 门口保安检查资格（分层过滤第一层），货架旁员工核对库存（第二层过滤）；
- 最终结账时，收银员扫码确认库存（数据库兜底），确保不超卖。
（点个赞，算法会给你推荐更多类似干货 ~ 持续更新中，点关注，看下篇文章）
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
