Arch Day 76: 高并发秒杀系统设计

日期: 2026-06-14 (Day 76) 阶段: 第三阶段 - 零售域深度 标签: #电商 #秒杀 #高并发 #Redis #限流 #削峰 #架构设计

---

核心概念

一句话定义

秒杀是面试"必考题"，也是架构设计的极限挑战——在极短时间内（秒级），大量用户（百万级）争抢极少量商品（几十~几千件），要求系统在不超卖的前提下保证高可用和用户体验。

为什么关注

秒杀是电商大促的核心引流工具——阿里双11零点峰值QPS超过百万，京东618秒杀系统单品QPS可达数十万。秒杀系统的设计是系统架构能力的"试金石"，它综合考验了高并发处理、分布式一致性、缓存策略、流量管控、降级容灾等核心能力。无论是面试还是实战，秒杀系统都是最能体现架构功底的题目。

阿里云Redis实例可支撑10万+QPS（单实例），通过Lua脚本实现原子操作确保库存扣减的准确性和一致性。2025年腾讯云方案进一步提出"四层库存扣减"策略：简单场景用DECR，复杂逻辑用Lua，长任务用Redisson，超高并发用消息队列。

误区与反模式

---

知识点详解

一、秒杀系统全链路

T-24h  T-1h  T-10min  T-0     T+0~T+5min    T+15min
  │      │      │       │          │             │
预热    预热   预热    开抢      支付窗口        结束
  │      │      │       │          │             │
  ▼      ▼      ▼       ▼          ▼             ▼
商品    缓存   页面   放行→     用户支付→      超时释放
上架    预热   预加载  抢购→    确认订单→      库存回补
配置    库存   CDN    下单→     发货准备       活动结束
       加载   部署   支付

二、前端优化

2.1 静态化 + CDN

秒杀商品页面:
  ├── 静态部分(CDN缓存): 商品图片/描述/参数
  ├── 动态部分(Ajax): 库存/价格/倒计时/按钮状态
  └── 交互部分(JS): 防抖/表单/Loading

秒杀页面 = 静态HTML(CDN) + 动态接口(少量后端请求)

2.2 前端限流策略

// 前端防刷策略
class FlashSaleClient {
    constructor() {
        this.clickCount = 0;
        this.lastClickTime = 0;
        this.maxClicksPerSecond = 1; // 每秒最多1次
    }

    async attemptPurchase(seckillId) {
        // 1. 按钮防抖（点击后禁用3秒）
        if (Date.now() - this.lastClickTime < 3000) {
            return { success: false, msg: '操作过于频繁' };
        }
        this.lastClickTime = Date.now();

        // 2. 倒计时未结束不允许点击
        if (this.countdownRemaining > 0) {
            return { success: false, msg: '活动尚未开始' };
        }

        // 3. 答题/滑块验证（人机校验）
        const captchaToken = await this.showCaptcha();
        if (!captchaToken) {
            return { success: false, msg: '验证失败' };
        }

        // 4. 生成幂等requestId
        const requestId = `${userId}_${seckillId}_${Date.now()}`;

        // 5. 发送请求
        const result = await fetch('/api/seckill/submit', {
            method: 'POST',
            headers: {
                'X-Request-Id': requestId,
                'X-Captcha-Token': captchaToken,
            },
            body: JSON.stringify({ seckillId, quantity: 1 }),
        });

        // 6. 根据结果展示
        if (result.status === 'QUEUED') {
            this.startPolling(result.orderToken);  // 轮询结果
        }

        return result;
    }
}

三、后端优化

3.1 多级限流

                    100万请求/秒
                         │
    ┌────────────────────▼────────────────────┐
    │            CDN/WAF层限流                  │
    │  IP限流(单IP 10次/s) + 地区限制            │
    │  过滤: 约50%恶意流量                       │
    └────────────────────┬────────────────────┘
                         │ 50万请求/秒
    ┌────────────────────▼────────────────────┐
    │            网关层限流                      │
    │  令牌桶(全局10万QPS) + 用户级限流(1次/s)   │
    │  答题验证Token校验                         │
    │  过滤: 约80%请求                           │
    └────────────────────┬────────────────────┘
                         │ 10万请求/秒
    ┌────────────────────▼────────────────────┐
    │            服务层限流                      │
    │  本地内存校验(库存是否>0)                   │
    │  用户资格校验(黑名单/已购买)                │
    │  过滤: 约90%请求                           │
    └────────────────────┬────────────────────┘
                         │ 1万请求/秒
    ┌────────────────────▼────────────────────┐
    │            Redis层                        │
    │  Lua脚本原子扣库存                         │
    │  成功率: 约1%(取决于库存量)                 │
    └────────────────────┬────────────────────┘
                         │ 100~1000请求
    ┌────────────────────▼────────────────────┐
    │            MQ → DB                        │
    │  创建订单 + 等待支付                       │
    └─────────────────────────────────────────┘

3.2 Redis库存扣减（Lua原子操作）

-- Redis Lua脚本：秒杀原子操作
-- KEYS[1] = stock:{seckillId}       库存key
-- KEYS[2] = bought:{seckillId}      已购买用户集合
-- ARGV[1] = userId
-- ARGV[2] = quantity (通常为1)

-- 1. 检查用户是否已购买（限购1件）
local hasBought = redis.call('SISMEMBER', KEYS[2], ARGV[1])
if hasBought == 1 then
    return -1  -- 已购买
end

-- 2. 检查库存
local stock = tonumber(redis.call('GET', KEYS[1]))
if stock == nil or stock <= 0 then
    return 0  -- 库存不足
end

local quantity = tonumber(ARGV[2])
if stock < quantity then
    return 0  -- 库存不足
end

-- 3. 扣减库存 + 记录已购买（原子操作）
redis.call('DECRBY', KEYS[1], quantity)
redis.call('SADD', KEYS[2], ARGV[1])

return 1  -- 扣减成功

// Java调用Lua脚本
@Service
public class SeckillService {

    private static final String SECKILL_LUA_SCRIPT = "..."; // 上面的Lua脚本

    public SeckillResult seckill(String seckillId, String userId) {
        // 1. 本地缓存快速判断(内存标记)
        if (localSoldOutCache.isSoldOut(seckillId)) {
            return SeckillResult.SOLD_OUT;
        }

        // 2. Redis Lua原子扣减
        Long result = redisTemplate.execute(
            new DefaultRedisScript<>(SECKILL_LUA_SCRIPT, Long.class),
            Arrays.asList(
                "stock:" + seckillId,
                "bought:" + seckillId
            ),
            userId, "1"
        );

        if (result == -1) {
            return SeckillResult.ALREADY_BOUGHT;
        }
        if (result == 0) {
            // 标记本地缓存已售罄（后续请求直接拒绝，不打Redis）
            localSoldOutCache.markSoldOut(seckillId);
            return SeckillResult.SOLD_OUT;
        }

        // 3. 发送到MQ异步创建订单
        String orderToken = UUID.randomUUID().toString();
        orderMQ.send(new CreateSeckillOrderMessage(
            seckillId, userId, orderToken
        ));

        // 4. 返回排队Token（用户凭此轮询结果）
        return SeckillResult.queued(orderToken);
    }
}

3.3 四层库存扣减方案（2025最佳实践）

四、流量削峰

4.1 排队机制

class SeckillQueueService:
    """秒杀排队服务"""

    def enqueue(self, seckill_id, user_id):
        """
        用户进入排队队列
        """
        queue_key = f"seckill:queue:{seckill_id}"

        # 1. 检查队列是否已满（库存的N倍，如10倍）
        queue_size = self.redis.llen(queue_key)
        max_queue_size = self.get_stock(seckill_id) * 10
        if queue_size >= max_queue_size:
            return {'status': 'FULL', 'msg': '活动太火爆，请稍后再试'}

        # 2. 检查是否已在队列中
        if self.redis.sismember(f"seckill:queued:{seckill_id}", user_id):
            return {'status': 'ALREADY_QUEUED', 'msg': '您已在排队中'}

        # 3. 入队
        self.redis.rpush(queue_key, user_id)
        self.redis.sadd(f"seckill:queued:{seckill_id}", user_id)

        # 4. 返回队列位置
        position = self.redis.llen(queue_key)
        return {
            'status': 'QUEUED',
            'position': position,
            'estimated_wait': position * 0.1,  # 预估等待秒数
        }

    def process_queue(self, seckill_id):
        """
        后台消费排队队列（定时任务，每100ms执行一次）
        """
        queue_key = f"seckill:queue:{seckill_id}"
        batch_size = 100  # 每次处理100个

        for _ in range(batch_size):
            user_id = self.redis.lpop(queue_key)
            if not user_id:
                break

            # 尝试扣库存
            result = self.seckill_service.try_deduct(seckill_id, user_id)
            if result.success:
                # 通知用户抢购成功
                self.notify_user(user_id, 'SUCCESS', result.order_token)
            else:
                # 通知用户抢购失败
                self.notify_user(user_id, 'FAILED', '库存不足')

4.2 令牌桶 + 漏斗

令牌桶(Token Bucket):
  ┌───────────────────────────┐
  │  桶容量: 10000 tokens      │
  │  填充速率: 1000 tokens/s   │
  │                           │
  │  请求进入 → 取1个token      │
  │  有token → 放行             │
  │  无token → 拒绝(429)       │
  └───────────────────────────┘

  适用: 允许短暂突发(桶满时可瞬间放行10000请求)

漏斗(Leaky Bucket):
  ┌───────────────────────────┐
  │  桶容量: 10000 requests    │
  │  漏出速率: 1000 req/s      │
  │                           │
  │  请求进入 → 入桶排队        │
  │  桶未满 → 入桶等待          │
  │  桶已满 → 拒绝(429)        │
  │  匀速漏出处理               │
  └───────────────────────────┘

  适用: 严格匀速(保护下游)

五、热点数据隔离

问题: 秒杀商品是超级热点Key，所有请求打同一个Redis节点

方案1: 本地缓存(JVM级)
  - 应用启动时加载秒杀商品信息到本地内存
  - 库存用AtomicInteger本地判断(>0才去Redis)
  - 售罄后本地标记，不再请求Redis

方案2: Redis热点Key分散
  - 将stock:{seckillId} 分散为 stock:{seckillId}:0~99
  - 100份库存分散到100个Key
  - 随机选一个Key扣减
  - 优点: 避免单Key热点
  - 缺点: 最后几件可能分散在多个Key中(需要合并)

方案3: 独立Redis实例
  - 秒杀专用Redis集群，与正常业务隔离
  - 避免秒杀流量影响正常购物

class HotKeyDistributor:
    """热点Key分散器"""

    def __init__(self, seckill_id, total_stock, shard_count=100):
        self.seckill_id = seckill_id
        self.shard_count = shard_count

        # 初始化: 将库存均分到多个shard
        per_shard = total_stock // shard_count
        remainder = total_stock % shard_count
        for i in range(shard_count):
            stock = per_shard + (1 if i < remainder else 0)
            self.redis.set(f"stock:{seckill_id}:{i}", stock)

    def try_deduct(self, user_id):
        """随机选shard扣减"""
        # 随机选一个shard
        shard = hash(user_id) % self.shard_count
        attempts = 0
        max_attempts = 3

        while attempts < max_attempts:
            result = self.redis.eval(
                self.DEDUCT_LUA,
                1,
                f"stock:{self.seckill_id}:{shard}",
                1  # 扣减1件
            )
            if result == 1:
                return True
            # 当前shard没库存，尝试下一个
            shard = (shard + 1) % self.shard_count
            attempts += 1

        return False

六、降级与容灾

降级策略矩阵:
┌──────────────┬──────────────┬──────────────┐
│    正常       │    预警       │    降级       │
├──────────────┼──────────────┼──────────────┤
│ 全功能       │ 关闭非核心    │ 极简模式      │
│ 实时库存     │ 缓存库存     │ 本地标记      │
│ 促销计算     │ 跳过复杂促销  │ 固定价格      │
│ 完整风控     │ 简化风控     │ 黑名单+签名    │
│ 积分/优惠    │ 延迟发积分    │ 暂停积分      │
│ 实时推荐     │ 缓存推荐     │ 无推荐        │
└──────────────┴──────────────┴──────────────┘

触发条件:
  - CPU > 80% → 预警级
  - Redis RT > 50ms → 预警级
  - 错误率 > 5% → 降级
  - DB连接池 > 90% → 降级
  - 全链路RT > 2s → 降级

---

对比分析

秒杀架构方案对比

秒杀 vs 普通下单

---

架构设计实操

设计目标

设计一个完整秒杀系统，满足：

• 峰值100万QPS
• 库存1000件，不超卖不少卖
• 下单响应<200ms
• 高可用（秒杀不影响正常购物）

全链路方案

┌──────────────────────────────────────────────────────────────┐
│                     用户端(浏览器/APP)                         │
│  ① 页面静态化(CDN)                                           │
│  ② 倒计时(服务端时间校准)                                      │
│  ③ 答题/滑块验证(人机校验)                                     │
│  ④ 按钮防抖(点击后禁用3s)                                     │
│  ⑤ requestId幂等                                             │
└──────────────────────────┬───────────────────────────────────┘
                           │ HTTPS
┌──────────────────────────▼───────────────────────────────────┐
│                     CDN/WAF层                                │
│  静态资源CDN加速 │ IP限流(10次/s) │ CC防护                     │
└──────────────────────────┬───────────────────────────────────┘
                           │ (过滤50%恶意流量)
┌──────────────────────────▼───────────────────────────────────┐
│                     API Gateway                              │
│  令牌桶限流(全局10万QPS)                                       │
│  用户级限流(1次/s)                                            │
│  验证码Token校验                                              │
│  黑名单过滤                                                   │
└──────────────────────────┬───────────────────────────────────┘
                           │ (放行10万QPS)
┌──────────────────────────▼───────────────────────────────────┐
│                     秒杀服务(独立集群!)                         │
│                                                              │
│  ┌─────────────────────────────────────────┐                │
│  │ ⑥ 本地内存判断(已售罄? → 直接返回)        │                │
│  └────────────────────┬────────────────────┘                │
│                       │ (未售罄的请求)                         │
│  ┌────────────────────▼────────────────────┐                │
│  │ ⑦ Redis Lua原子操作                      │                │
│  │   检查限购 → 扣库存 → 记录已购            │                │
│  └────────────────────┬────────────────────┘                │
│                       │ (扣减成功)                            │
│  ┌────────────────────▼────────────────────┐                │
│  │ ⑧ 发送MQ消息(异步创建订单)                │                │
│  └────────────────────┬────────────────────┘                │
│                       │                                      │
│  ┌────────────────────▼────────────────────┐                │
│  │ ⑨ 返回"抢购成功,等待下单" + orderToken    │                │
│  └─────────────────────────────────────────┘                │
└──────────────────────────┬───────────────────────────────────┘
                           │ MQ
┌──────────────────────────▼───────────────────────────────────┐
│                     订单服务(异步处理)                          │
│  ⑩ 消费MQ → 创建订单 → 锁定优惠                               │
│  ⑪ 通知用户"请在15分钟内支付"                                  │
│  ⑫ 支付成功 → DB库存确认扣减 → 发货                            │
│  ⑬ 支付超时 → Redis库存回补 → 订单取消                         │
└──────────────────────────────────────────────────────────────┘

ADR: 秒杀系统独立部署

背景: 秒杀流量可能冲垮正常购物系统

决策: 秒杀系统完全独立部署——独立服务集群+独立Redis+独立MQ+独立域名

理由:

• 故障隔离：秒杀崩溃不影响正常购物
• 独立扩缩容：秒杀前扩容，结束后缩容
• 独立限流：秒杀限流策略与正常购物不同
• 数据隔离：秒杀热点Key不影响正常Redis

权衡:

• 优势：故障隔离、独立运维
• 劣势：资源冗余、系统间通信成本
• 替代方案：同一集群分租户隔离（通过线程池/连接池隔离）

---

AI增强实践

1. AI驱动的秒杀风控

class SeckillAntiBot:
    """秒杀反机器人系统"""

    def evaluate_request(self, request):
        """
        实时风险评估
        延迟要求: <10ms（不能影响正常用户体验）
        """
        features = {
            # 设备指纹
            'device_fingerprint': request.device_id,
            'browser_fingerprint': request.browser_fp,
            'is_emulator': self.detect_emulator(request),

            # 行为特征
            'click_interval_ms': request.click_interval,  # 点击间隔
            'mouse_entropy': request.mouse_entropy,        # 鼠标轨迹熵
            'captcha_solve_time': request.captcha_time,    # 验证码解答时间

            # 历史特征
            'account_age_days': request.user.account_age,
            'seckill_participate_count': request.user.seckill_count,
            'seckill_success_rate': request.user.seckill_success_rate,

            # 网络特征
            'ip_request_count': self.get_ip_count(request.ip),
            'is_proxy': self.detect_proxy(request.ip),
            'is_datacenter_ip': self.is_datacenter(request.ip),
        }

        # 轻量级模型实时打分（<5ms）
        risk_score = self.realtime_model.predict(features)

        if risk_score > 0.9:
            return {'action': 'BLOCK', 'reason': 'Bot detected'}
        elif risk_score > 0.6:
            return {'action': 'CHALLENGE', 'reason': 'Suspicious'}
        else:
            return {'action': 'ALLOW'}

2. AI预测与资源调度

---

与Web3/DeFi的关联

秒杀 × Web3

秒杀系统的核心挑战:
  - 公平性: 先到先得 vs 网络延迟差异
  - 防刷: 真人 vs 机器人
  - 不超卖: 分布式环境下的原子性

区块链天然解决了其中一些:
  - 公平性: 交易排序由共识协议决定(矿工/验证者)
  - 防刷: 每笔交易需要Gas费(经济成本防刷)
  - 不超卖: 智能合约原子执行(要么成功要么回滚)

但区块链也有局限:
  - 吞吐量: Ethereum ~30 TPS（秒杀需要百万级）
  - 延迟: 出块时间12s（用户等不了）
  - 成本: Gas费高（买个9.9包邮还要付10块Gas?）

折中方案:
  - L2 Rollup(如Arbitrum): 几千TPS + 秒级确认
  - 链下撮合+链上结算: 类似DEX的off-chain order book
  - NFT秒杀: 限量NFT可以直接链上mint(数量小)

NFT Mint的"秒杀"设计

// NFT限量Mint合约（简化版秒杀）
contract NFTFlashSale {
    uint256 public maxSupply = 1000;
    uint256 public minted = 0;
    uint256 public price = 0.01 ether;
    mapping(address => bool) public hasMinted;

    function mint() external payable {
        require(block.timestamp >= saleStartTime, "Not started");
        require(minted < maxSupply, "Sold out");  // 不超卖
        require(!hasMinted[msg.sender], "Already minted");  // 限购1
        require(msg.value >= price, "Insufficient payment");

        hasMinted[msg.sender] = true;
        minted++;
        _safeMint(msg.sender, minted);
    }
}
// 注意: 链上秒杀面临MEV攻击(矿工抢跑)
// 解决: Commit-Reveal模式或使用Flashbots

---

今日思考

1. 秒杀"公平性"如何保证？

纯粹"先到先得"对网络延迟高的用户不公平。改进方案：(1) 答题/抽签模式——所有人在窗口期内提交，随机抽签；(2) 预约制——提前预约，按预约时间段分批放行；(3) 排队制——所有请求入队，先进先出处理。区块链的共识机制启发：让"排序"由不可操纵的规则决定，而非单纯依赖网络速度。

2. Redis Cluster在秒杀中如何保障数据一致？

Redis Cluster的主从复制是异步的，主节点宕机时可能丢数据（已扣的库存丢失→超卖）。应对方案：(1) 多写模式（同城异地多主写入），增加同步写节点数；(2) AOF+fsync=always（牺牲性能换持久性）；(3) DB对账兜底——即使Redis丢数据，DB作为最终数据源。实践中选择"Redis做速度+DB做准确"的组合。

3. 如何做到"不少卖"——库存回补的可靠性？

"不少卖"比"不超卖"更容易被忽略。场景：用户抢到但不支付，库存应该回补。回补机制：(1) 15分钟超时定时任务扫描未支付订单→Redis INCRBY回补；(2) 回补后重新开放购买（可能已结束）；(3) 订单取消事件驱动回补（比定时扫描更及时）。关键是回补操作也要保证幂等——同一订单只回补一次。

---

面试题准备

题目1：秒杀如何保证库存不超卖？

30秒回答： Redis Lua脚本原子操作——在一个原子操作中完成"检查库存→扣减库存→记录已购"三步。Redis单线程保证原子性，Lua脚本保证多命令的事务性。成功后异步MQ创建订单，DB最终确认。

2分钟回答：

四层保障：

1. 第一层：Redis Lua原子扣减——单线程执行SISMEMBER(限购检查)+GET(库存检查)+DECRBY(扣减)+SADD(记录)，在一个Lua脚本中完成，天然不会超卖
2. 第二层：本地内存标记——库存扣完后，本地AtomicBoolean标记sold_out，后续请求直接返回，不再打Redis
3. 第三层：MQ幂等消费——消费端创建订单时用seckillId+userId做唯一键，防重复创建
4. 第四层：DB乐观锁确认——支付成功后DB扣库存用WHERE stock >= quantity兜底

额外保障：

• 超时回补：15分钟未支付→Redis INCRBY回补→重新可售
• 定时对账：每小时Redis vs DB库存比对，差异告警
• 熔断降级：Redis异常时直接返回"系统繁忙"，宁可少卖不可超卖

追问准备：

• Q: Lua脚本太长影响Redis性能？→ 保持Lua脚本简短(5-10行)，复杂逻辑放应用层
• Q: Redis挂了怎么办？→ Redis Sentinel自动主从切换(<30s)，切换期间返回"系统繁忙"

题目2：如何做到100万并发？

30秒回答： 核心思想是"漏斗型流量过滤"——CDN过滤50%→网关限流到10万→服务层过滤到1万→Redis处理1万→MQ异步创建100~1000个订单。100万请求中99.9%在到达数据库之前就被过滤了。

2分钟回答：

分层拦截:

1. CDN层(100万→50万)：静态页面CDN缓存，WAF过滤恶意IP
2. 网关层(50万→10万)：令牌桶限流(全局10万QPS)，答题验证过滤机器人
3. 服务层(10万→1万)：本地内存判断已售罄(O(1))，Redis Lua扣库存
4. MQ层(1万→1000)：成功请求入MQ，异步创建订单
5. DB层(1000)：MQ消费者批量写入DB

关键技术:

• 秒杀系统独立部署（不影响正常购物）
• 热点Key分散（库存拆100个shard）
• 三级缓存（本地Caffeine→Redis→DB）
• 异步化（同步链路只做限流+扣库存，<100ms）

资源规划（100万QPS估算）：

• CDN：至少5个节点
• 网关：50台(每台2万QPS)
• 服务：100台(每台1万QPS，只有10%能到Redis)
• Redis：独立集群(8主8从)
• MQ：Kafka集群(3-5节点)

追问准备：

• Q: 预算有限怎么办？→ 云服务弹性伸缩，秒杀前30分钟扩容，结束后缩容
• Q: 秒杀结束后的支付峰值怎么扛？→ 支付是外部系统(支付宝/微信)的瓶颈，我们的支付请求只有成功抢到的千级，不是瓶颈

---

学习资源

• 打造高性能秒杀系统 - 阿里云帮助中心
• 使用Tair设计与实现高并发秒杀系统 - 阿里云
• Redis+Lua分布式锁防超卖与库存扣减优化 - 腾讯云
• 秒杀系统技术拆解 - 腾讯云
• 秒杀系统架构解析 - Thoughtworks
• Redis Lua脚本解决高并发库存超卖 - CSDN

---

系列回顾

Day 69-76 "零售域深度"系列完结。回顾一下我们的学习路径：

这8天覆盖了零售电商领域最核心的架构主题。每个主题都从业务场景出发，深入技术实现，并结合AI增强和Web3/DeFi关联。这些知识不仅适用于电商，也是通用的分布式系统设计能力。