电商平台秒杀系统架构设计实战

一、项目概述

1.1 业务背景与流量特征

电商平台的秒杀活动是拉新促活的核心手段，但秒杀带来的流量特征与常规业务截然不同。双十一零点开抢的瞬间，流量会在毫秒级内从日常的几万QPS暴涨至千万级，并在5-30分钟内迅速回落。这种"瞬间洪峰"对系统的每个环节都构成极大压力——数据库连接池耗尽、缓存击穿、CDN回源风暴，任何一个环节的疏漏都可能引发系统性崩溃。

系统需要支撑的典型场景包括：

• 限量抢购：1万件茅台/茅台/iPhone/演唱会门票，5分钟内售罄，数百万用户同时涌入
• 整点秒杀：京东/天猫整点秒杀频道，准点开放，流量瞬间拉升
• 阶梯团购：拼多多式成团玩法，达到人数阈值后发货
• 新人专享：首单新用户限购一件，需要与老用户严格隔离

1.2 核心业务指标

其中"零超卖"是秒杀系统的绝对红线——多卖出去的订单在支付时发现无货，要么退款补偿，要么引发客诉，一旦出现就是重大生产事故，直接影响平台信誉和财务损失。

1.3 核心矛盾分析

秒杀系统的本质矛盾是：超高并发读（商品详情页刷新）和严格一致性写（库存扣减）的流量差异，以及两者对系统资源的完全不同的压力特征。

1.4 动静分离决策

秒杀商品的详情页，99%以上的内容是静态的——商品名称、图片、描述、秒杀规则。而真正需要实时获取的只有"当前库存数量"和"秒杀开始时间"两个动态字段。如果所有请求都打到后端服务器，即便是展示商品详情页，也足以把后端服务打爆。

因此，我们对商品详情页做了彻底的动静分离：

• 静态内容（商品名称、图片、描述、秒杀规则）：编译为静态HTML，上传到CDN，TTL设置为30秒。99%的用户请求由CDN直接响应，后端QPS接近0。
• 动态接口（库存数量、秒杀开始时间）：独立部署限流保护，不与商品详情页共享带宽，使用独立的Redis连接池。
• HTML5推送：秒杀开始前5分钟，将最新的静态HTML推送到CDN所有边缘节点，避免冷启动。

1.5 为什么选择Redis做库存扣减

库存扣减的核心要求是：同一时刻只有一个请求能成功扣减同一件库存。这在Redis中天然成立——Redis采用单线程事件循环模型，所有命令在执行期间都是串行的，没有任何并发冲突。

相比之下，MySQL的行锁方案在10万QPS的扣减请求下，数据库连接池会在毫秒内耗尽，即使加上了连接池排队和超时机制，整体QPS也会从10万跌到几百，系统陷入不可用状态。

二、技术架构设计

2.1 五层漏斗拦截模型

整个秒杀系统的核心思想是"逐层拦截无效流量"——在每一层尽可能早地过滤掉无效请求，最大限度保护下游资源。每一层都根据当前系统的承载能力和业务规则，丢弃不符合条件的请求。下图展示了从用户发起请求到最终下单成功的完整漏斗链路，每一层都有明确的拦截目标和所使用的核心技术组件。

2.2 完整流量漏斗计算

以双十一iPhone 15 首发为例，展示五层漏斗的实际效果：

2.3 动静分离架构

2.4 Canal实时同步MySQL库存到Redis

Redis库存是缓存，必须与MySQL主库存保持最终一致性。采用阿里开源的Canal监听MySQL binlog，实时同步库存变更：

• 管理员加库存：MySQL UPDATE → Canal监听binlog → Redis同步更新
• 秒杀结束后回补：未付款订单超时 → MySQL回滚库存 → Canal同步 → Redis恢复
• Canal可靠性：Canal Server支持集群部署，通过ZooKeeper做Leader选举，避免单点

2.5 分桶库存设计

即使使用了五层漏斗，单个热点商品的库存Key仍然是Redis中最热的Key。在1000万QPS下，即使只有1%穿透到Redis，也是10万QPS对单Key的操作。采用分桶策略将单个热Key打散为多个Key：

// 分桶策略：将单Key库存拆分为N个桶，每个桶独立扣减
// 原：seckill:stock:goods_123 （单Key，QPS=100000）
// 分桶后：
// seckill:stock:goods_123:bucket_0  (库存 2000)
// seckill:stock:goods_123:bucket_1  (库存 2000)
// seckill:stock:goods_123:bucket_2  (库存 2000)
// ...
// seckill:stock:goods_123:bucket_4  (库存 2000)

// 扣减时：根据 userId 哈希选择分桶
bucketIndex := crc32.ChecksumIEEE([]byte(userId)) % bucketCount
stockKey := fmt.Sprintf("seckill:stock:%s:bucket_%d", goodsId, bucketIndex)

// 用户维度限购Key也需要对应分桶
orderKey := fmt.Sprintf("seckill:orders:%s:bucket_%d", goodsId, bucketIndex)

三、核心技术挑战与解决方案

# Redis Keyspace通知配置（redis.conf）
notify-keyspace-events Ex
# E = Keyevent事件，x = 过期事件

# 订单消费者订阅过期事件
SUBSCRIBE __keyevent@0__:expired
# 收到消息：order:timeout:ORDER123
# 消费者处理：检查订单状态 → 回补库存

四、关键技术实现

4.1 Lua原子扣减脚本（核心）

这是整个秒杀系统的"心脏"。一个Lua脚本完成所有检查和扣减，保证原子性。下图展示了脚本内部的执行流程：Redis 单线程模型保证整个脚本在执行期间不会有其他命令插入，从幂等检查到库存扣减再到用户限购记录，所有操作一气呵成，绝无并发冲突。

-- seckill_decrease_stock.lua
-- 秒杀库存扣减Lua脚本（原子操作，无并发问题）
-- KEYS[1] = 库存Key，如 "seckill:stock:goods_123:bucket_0"
-- KEYS[2] = 订单用户Set Key，如 "seckill:orders:goods_123:bucket_0"
-- ARGV[1] = 用户ID（用于限购检查）
-- ARGV[2] = 扣减数量（通常为1）
-- ARGV[3] = 幂等Token（防止重复提交）

local stockKey = KEYS[1]
local orderKey = KEYS[2]
local uid = ARGV[1]
local qty = tonumber(ARGV[2])
local idempotentToken = ARGV[3]

-- ============ 1. 幂等检查 ============
local idemKey = 'seckill:idem:' .. idempotentToken
if redis.call('EXISTS', idemKey) == 1 then
    return {-3, 0}  -- 幂等Token已存在，重复提交
end

-- ============ 2. 用户限购检查 ============
if redis.call('SISMEMBER', orderKey, uid) == 1 then
    return {-2, 0}  -- 用户已购买过
end

-- ============ 3. 库存检查 ============
local stock = tonumber(redis.call('GET', stockKey) or 0)
if stock < qty then
    return {-1, 0}  -- 库存不足
end

-- ============ 4. 原子扣减 ============
redis.call('DECRBY', stockKey, qty)

-- ============ 5. 记录购买用户 ============
redis.call('SADD', orderKey, uid)

-- ============ 6. 设置幂等Token ============
redis.call('SETEX', idemKey, 600, '1')  -- 10分钟有效期

-- ============ 7. 返回结果 ============
local remainingStock = redis.call('GET', stockKey)
return {0, remainingStock}  -- 成功，返回剩余库存

4.2 Nginx/OpenResty三层限流Lua脚本

在L2网关层，用OpenResty实现高性能限流：

-- seckill_limit.lua
-- 限流策略：用户维度 + IP维度 + 全局维度三重限流

local redis = require('resty.redis')
local red = redis:new()
red:set_timeout(1000)

-- 本地共享字典：缓存限流状态，减少Redis访问
local limit_dict = ngx.shared.seckill_limit

local user_id = ngx.var.user_id or ''
local remote_ip = ngx.var.remote_addr or ''

-- ============ 1. 用户维度限流 ============
-- 每个用户每分钟最多30次下单请求
local user_key = 'limit:user:' .. user_id
local user_count = limit_dict:get(user_key)
if user_count and tonumber(user_count) >= 30 then
    ngx.exit(ngx.HTTP_FORBIDDEN)  -- 超出限流，返回429
end
if user_count then
    limit_dict:incr(user_key, 1)
else
    limit_dict:set(user_key, 1, 60)  -- TTL 60秒
end

-- ============ 2. IP维度限流 ============
-- 每个IP每分钟最多200次（防爬虫/CC攻击）
local ip_key = 'limit:ip:' .. remote_ip
local ip_count = limit_dict:get(ip_key)
if ip_count and tonumber(ip_count) >= 200 then
    ngx.exit(ngx.HTTP_TOO_MANY_REQUESTS)  -- 超出限流
end
if ip_count then
    limit_dict:incr(ip_key, 1)
else
    limit_dict:set(ip_key, 1, 60)
end

-- ============ 3. 全局限流（令牌桶算法） ============
-- 每秒发放固定数量令牌，超出则拒绝
local token_key = 'limit:token:global'
local token_rate = 100000  -- 每秒10万令牌
local tokens = tonumber(red:get(token_key)) or token_rate

if tokens <= 0 then
    ngx.exit(ngx.HTTP_SERVICE_UNAVAILABLE)  -- 令牌耗尽，服务不可用
end

-- 使用DECR保证原子性（Lua脚本或Redis MULTI/EXEC事务）
red:decr(token_key)
red:expire(token_key, 1)
red:set_keepalive(1000, 100)

4.3 Kafka可靠投递（事务模式）

Kafka消息投递使用Exactly-Once语义，保证库存扣减和消息投递的原子性：

// Kafka生产者：库存扣减成功后才发送消息（事务模式）
public class SeckillOrderProducer {

    private final KafkaTemplate kafkaTemplate;

    /**
     * 事务模式：库存扣减结果已知，消息投递必达
     * 如果消息发送失败，整个事务回滚，库存也回滚
     */
    public void sendOrderInTransaction(SeckillOrderMsg msg) {
        kafkaTemplate.executeInTransaction(operations -> {
            // 1. Redis扣减（已在Controller层完成）
            // 2. 发送订单消息
            //    - 消息key = orderId，保证同一订单的消息路由到同一Partition
            //    - 失败则事务回滚，触发库存回补
            operations.send("seckill-order",
                msg.getOrderId(),  // 分区key，同一订单的消息在同一Partition有序
                msg,
                new ProducerCallback(msg));
            return null;
        });
    }
}

// Kafka消费者：幂等处理
public class SeckillOrderConsumer {

    private final Map processedCache = Redis.getCache("order:idempotent");

    @KafkaListener(topics = "seckill-order", groupId = "seckill-order-consumer")
    public void consume(SeckillOrderMsg msg) {
        String idempotentKey = msg.getOrderId();

        // 幂等检查：已处理过的消息直接跳过
        if (processedCache.containsKey(idempotentKey)) {
            return;  // 重复消息，不处理
        }

        // 创建订单（MySQL INSERT）
        orderService.createOrder(msg);

        // 标记已处理（TTL=24h）
        processedCache.put(idempotentKey, "1", 24 * 3600);

        // 发送支付通知
        paymentService.sendPaymentNotice(msg);
    }
}

4.4 库存回补完整流程

// 库存回补服务（处理超时未支付）
@Service
public class StockRollbackService {

    @Autowired private RedisTemplate redisTemplate;
    @Autowired private OrderMapper orderMapper;

    /**
     * 定时任务：每分钟扫描超时未支付订单并回补库存
     */
    @Scheduled(cron = "0 * * * * ?")  // 每分钟执行
    public void rollbackTimeoutOrders() {
        // 1. 查询15分钟前创建的未支付订单
        List timeoutOrders = orderMapper.selectTimeoutOrders(
            LocalDateTime.now().minusMinutes(15), OrderStatus.CREATED);

        for (Order order : timeoutOrders) {
            try {
                // 2. 幂等回补：使用Lua脚本，保证原子性
                String script = """
                    local stockKey = KEYS[1]
                    local qty = tonumber(ARGV[1])
                    local orderKey = KEYS[2]
                    local uid = ARGV[2]
                    -- 加库存
                    redis.call('INCRBY', stockKey, qty)
                    -- 删除购买记录
                    redis.call('SREM', orderKey, uid)
                    return 1
                    """;
                redisTemplate.execute(
                    new DefaultRedisScript<>(script, Long.class),
                    Arrays.asList(
                        "seckill:stock:" + order.getGoodsId() + ":bucket_0",
                        "seckill:orders:" + order.getGoodsId() + ":bucket_0"
                    ),
                    String.valueOf(order.getQuantity()),
                    order.getUserId()
                );

                // 3. 更新订单状态为已取消
                orderMapper.updateStatus(order.getId(), OrderStatus.CANCELLED_TIMEOUT);

                // 4. 发送补偿通知
                smsService.send(order.getUserId(),
                    "您的订单" + order.getId() + "已超时取消，库存已释放");
            } catch (Exception e) {
                // 幂等保证：重复回补不会造成库存超量
                log.warn("回补订单失败: orderId={}, error={}", order.getId(), e.getMessage());
            }
        }
    }
}

五、性能指标与成果

5.1 双十一大促实战数据

系统上线后经历了双十一、618两次大促考验。双十一当天下午2点，iPhone 15 首发秒杀，10分钟内完成1万件销售，峰值QPS达到 873万，系统全程稳定运行。库存误差为 0（精确到个位），主库零击穿（Redis Cluster完整承接所有扣减请求），Kafka消息零丢失。

5.2 系统各层表现

5.3 业务价值

• GMV提升：双十一当天秒杀频道GMV同比增长 42%，主要得益于系统稳定性和用户体验的提升。
• 成本优化：相比之前使用Oracle数据库的方案，迁移到MySQL分库分表+Redis缓存后，数据库成本降低 75%。
• 运营效率：系统支持运营随时配置新秒杀场次（商品+时间+库存），从配置到上线只需 5 分钟，无需开发介入。

六、架构经验总结