构建一个高可用的、层层递进的秒杀系统

构建一个高可用的、层层递进的秒杀系统

层次一：用户交互层 (Browser/App) - 体验与防御的起点

目标：在用户端完成极致的体验优化和初级流量过滤。

  1. **动态CDN与边缘计算 (Edge Computing)**：

    • 页面静态化：商品详情页、活动规则页等静态资源，全部推送到全球CDN节点，利用用户本地DNS实现最优线路访问。

    • 边缘节点动态逻辑：

      • 权威时间服务：通过 CDN 的边缘节点（如 Cloudflare Workers, AWS Lambda@Edge）提供一个全球同步的、低延迟的权威时间接口，供客户端校准倒计时。
      • 动态Token下发：秒杀开始的瞬间，由边缘节点直接下发访问令牌（JWT），而不是所有请求都回源到中心机房。这能将第一波流量洪峰分散到全球。

  2. 客户端智能：

    • 人机验证：引入无感知的滑动验证、设备指纹、行为分析等高级人机验证手段，而不是简单的图形验证码，在不牺牲体验的前提下，精准识别并拦截机器人流量。
    • 精细化防抖：按钮点击后，不仅是简单置灰，还会启动一个本地的、带状态的请求控制器。它负责管理Token的获取、使用，并以指数退避策略处理“排队中”、“已售罄”等状态，避免客户端进行无效的轮询。
    • 答案隐藏：秒杀的核心接口地址或参数，在秒杀开始前是加密或隐藏的，通过上述动态Token下发时一并返回，增加脚本破解难度。

层次二：接入与负载均衡层 (Gateway/SLB) - 流量的“海关”

目标：承载全部入口流量，进行全局性的安全防护和流量调度。

  1. 超大带宽的 Anti-DDoS 服务：
    • 在所有流量入口部署云厂商或专业厂商的 Anti-DDoS 服务，能够清洗 T 级别（Tbps）的流量攻击。
  2. **API 网关 / L7 负载均衡 (Nginx/APISIX)**：
    • **WAF (Web Application Firewall)**：在网关层部署 WAF，过滤 SQL 注入、XSS 等应用层攻击。
    • 全局限流与熔断：基于 IP、设备ID、用户等级 等维度，进行精细化的全局限流。例如，一个 IP 在 1 秒内只能发起 3 次秒杀请求。
    • 动态Token校验：对来自客户端的动态Token进行第一道校验，无效或过期的Token直接在此层拦截。
    • 蓝绿/金丝雀发布支持：为后续的应用层服务发布提供流量切分能力。

层次三：应用集群层 (Application Cluster) - 核心逻辑与流量整形

目标：无状态、可无限水平扩展，完成核心的业务校验和流量削峰。

  1. 流量整形：分布式排队系统

    • 问题：即使经过接入层限流，到达应用集群的流量依然是巨大的脉冲。

    • 方案：在应用层实现一个轻量级的分布式排队系统

      。

      • 当请求进入Go服务集群时，首先去一个全局的Redis计数器（使用INCR）获取一个“排队号”。
      • 只允许排队号在一定范围内的请求（例如，库存的 3-5 倍）进入后续的核心逻辑。
      • 超出范围的请求，直接返回“您正在排队中，请稍候…”，并附带一个预计等待时间，引导客户端进行智能轮询。

    • 效果：将千万级的瞬时请求，精确地“筛选”成十万或百万级的有效请求，进入下一环节。

  2. 多级缓存校验与库存预扣减

    • 本地缓存 (In-Memory Cache - BigCache/FreeCache)：在每个Go服务实例中，用本地缓存存储“商品已售罄”的标志位（1-2秒过期）。这是最快的一道防线，可以避免对Redis的无效请求。

    • 分布式缓存 (Redis Cluster)：

      • 库存分桶/分片 (Stock Sharding)：这是应对单品超高并发的“核武器”。将 1 万件库存，分散到 100 个 Redis Key 中（stock:pid:shard_1 … stock:pid:shard_100），每个 Key 存 100 件。用户请求被哈希到随机一个分片进行扣减。这能将单个热点 Key 的写压力分散 100 倍。

      • 原子化校验 (Lua 脚本)：使用 Lua 脚本将“风控校验 + 限购检查 + 库存分片扣减”封装成一个原子操作。脚本会更复杂，可能包含：

        1. 从风控Set中检查用户/设备是否被临时封禁。
        2. 从已购用户Set中检查是否重复购买。
        3. 随机选择一个库存分片。
        4. 检查分片库存并扣减。如果该分片已空，则重试几次其他分片。
        5. 记录用户到已购Set。

  3. 异步下单 (高可靠消息队列)

    • 抢购成功的请求，封装成包含幂等性Token的消息，发送到高可靠的 Kafka / Pulsar 集群。
    • 指定 Partition Key：必须使用 user_id 作为消息的 Partition Key，保证同一个用户的多次（可能重复的）请求被顺序处理。
    • 消息发送确认：使用生产端的 acks=all (Kafka) 或类似机制，确保消息被多个Broker副本确认后再返回成功，保证消息不丢失。

层次四：后台核心服务层 - 最终一致性与履约

目标：稳定、可靠地处理已成功的请求，完成交易闭环。

  1. **订单消费者服务 (Order Consumer)**：

    • 采用消费者组模式，可以水平扩展实例来提升消费速度。

    • 批量消费：一次拉取一批消息进行处理，提升吞吐量。

    • 幂等性保证：在创建订单前，先检查本次操作的幂等性Token是否已被处理过，防止因MQ重试导致重复下单。

    • 分布式事务：创建订单和扣减数据库库存，如果涉及跨库操作，必须引入分布式事务方案。可靠消息最终一致性是这里的常用模式：

      1. 先创建订单，状态为“待出库”。
      2. 成功后，再发送一条“订单已创建”的消息。
      3. 由库存服务消费该消息，去扣减数据库库存。

  2. 死信队列与自动化补偿：

    • 为订单主题配置**死信队列 (DLQ)**。
    • 一个独立的、低速的补偿服务会消费DLQ中的消息，进行梯度退避重试。
    • 多次重试仍失败的，记录到“异常订单表”，并触发P1级告警，通知人工介入。

层次五：数据与运维保障体系

目标：保证数据的最终准确性，并为整个系统提供可观测性和韧性。

  1. **数据核对 (Reconciliation)**：
    • 一个离线的、基于大数据平台 (Spark/Flink) 的对账系统。
    • 在秒杀结束后，它会 T+1 地对比 Redis 成功记录数、MQ 消息数、数据库订单数、数据库库存流水，确保所有数字完全吻合，并自动修复微小差异。
  2. **全链路可观测性 (Observability)**：
    • 监控与告警：一个实时的秒杀大盘，展示从前端到数据库所有关键节点的性能指标（QPS, Latency, Error Rate）、业务指标（下单成功率）和资源指标（CPU, Mem）。
    • **分布式链路追踪 (Tracing)**：使用 Jaeger/SkyWalking 等，可以追踪任何一个请求的全生命周期，快速定位性能瓶颈和错误根源。
    • **日志聚合 (Logging)**：使用 ELK/Loki 等，集中管理所有服务的日志。
  3. **预案与混沌工程 (Resilience)**：
    • 所有关键组件（Redis, MQ, DB）都有跨机房/跨可用区的容灾部署。
    • 所有外部依赖调用，都必须有熔断、降级、超时配置，并通过配置中心动态调整。
    • 定期进行混沌工程演练：主动地在预发布或生产环境中注入故障（如模拟Redis节点宕机、网络延迟），来验证系统的自动故障转移和降级预案是否有效。

QPS 承载能力估算

“这套极致优化的系统，其瓶颈被设计在了前端接入层的带宽和CPU，以及Redis集群的整体吞吐能力上。”

“通过库存分片，我们将单个热点商品的写压力分散到了整个Redis集群。假设我们使用一个有10个主节点的Redis集群，每个节点能承载4万QPS的Lua脚本执行，那么仅Redis层，我们就能支撑40万的秒杀请求QPS。”

“同时，应用层的Go服务集群可以线性扩展。假设单机处理能力为2万QPS，部署一个50台机器的集群，就能承载100万QPS的入口流量。前端的分布式排队系统和本地缓存，能确保只有有效流量会穿透到Redis。”

“因此，这套架构在经过充分的压力测试和容量规划后，稳定支撑单品秒杀的百万级QPS是完全可行的。系统的可扩展性允许我们在未来通过增加机器来应对更高的流量挑战。”

可完善的细节与思考点

1. 接入层/应用层：进一步提升韧性与安全性

现有方案：内存排队、本地缓存、Redis Lua、库存分片。
完善点：

  • 对“内存排队系统”的深化思考：
    • 公平性问题：简单的内存队列是先进先出（FIFO），可能会让一些响应快的“机器人”抢占所有名额。可以引入分桶的用户优先级队列，例如，为首次参与秒杀的用户或高等级会员设置一个独立的、优先级更高的队列，以实现业务上的公平性。
    • 分布式问题：单机内存队列在集群环境下会导致请求只在本机排队。可以引入分布式排队的思路，例如，在 Nginx+Lua 层使用 lua-resty-lock 实现一个轻量级的分布式锁或计数器，来控制进入后端应用层的总流量，让全局排队更有序。
  • 对“库存分片”的补充说明：
    • 分片库存的回滚问题：如果某个用户在一个分片上扣减成功，但后续因为风控等原因下单失败，这个分片的库存需要回滚。如何将这个回滚的库存公平地补充回去？是直接加回原分片（可能导致该分片热点持续），还是将其放入一个“补充池”再慢慢分配给其他分片？这是一个需要权衡的细节。
  • 增强安全性：风控前置
    • 问题：当前的校验（限购）是业务逻辑层面的。对于恶意攻击者，他可以用大量不同（或伪造）的 user_id 来发起请求。
    • 完善：在流量进入业务逻辑（甚至内存队列）之前，应该先经过一个实时的风控引擎。这个引擎可以基于用户的设备指纹、IP画像、历史行为等，快速判断出“机器人”或“黄牛”流量，并直接在网关层或接入层就将其拦截。这能进一步减少无效请求对核心系统的消耗。

2. 消息队列层：提升可靠性

现有方案：异步下单。
完善点：

  • 消息的顺序性与用户体验：
    • 问题：如果一个用户手速极快，连续点击了两次秒杀（假设第一次因网络原因前端没置灰），可能会产生两个请求。如果 MQ 的 Topic 有多个分区，这两个消息可能被路由到不同分区，导致消费时出现乱序。
    • 完善：在发送消息到 MQ 时，必须指定 partition key 为 user_id。这能保证同一个用户的所有请求消息，都会被发送到同一个分区中，从而保证了消费的顺序性，避免了因乱序导致的重复下单等问题。
  • 死信队列（DLQ）的自动化处理：
    • 问题：方案提到了死信队列和人工介入，但可以更自动化。
    • 完善：为死信队列配置一个独立的、低速的消费者。这个消费者可以尝试对死信进行多次、梯度退避的重试（例如，1分钟后、5分钟后、30分钟后…）。对于某些可恢复的错误（如数据库瞬时抖动），这样可以自动“治愈”大部分失败的订单。只有当多次重试后仍然失败的消息，才最终进入“需要人工干预”的告警流程。

3. 后台服务与数据库层：明确一致性边界

现有方案：乐观锁、数据核对。
完善点：

  • 数据库事务粒度的讨论：
    • 问题：消费者服务中，“扣减数据库库存”和“创建订单”是在一个事务里。如果订单表和商品库存表被分到了不同的数据库实例（这是非常常见的），如何保证事务性？
    • 完善：明确指出这里需要引入分布式事务解决方案。
      • **TCC (Try-Confirm-Cancel)**：性能好，但对业务代码侵入性强。
      • **SAGA (长事务)**：通过一系列本地事务和补偿操作来实现，对业务侵入小，但一致性稍弱。
      • 可靠消息最终一致性：这是最常用的。消费者先成功创建订单（状态：处理中），再发送一条“订单已创建”的消息，由库存服务消费来扣减库存。整个流程是最终一致的。需要根据业务对一致性的要求来选择方案。

4. 整体架构的非功能性完善

这是让方案从“优秀”走向“卓越”的关键。

  • 全链路压测与容量规划：
    • “在上线前，我们会对整个系统进行全链路压力测试，从前端模拟真实用户请求，一直压到数据库层。通过压测，我们可以精确地找到系统的瓶颈点，并进行容量规划，确定在目标QPS下，每个服务（Nginx, Go应用, Redis, MQ）需要部署多少个实例。”
  • 可观测性 (Observability) 的具体化：
    • “我们会构建一个实时的秒杀大盘。这个大盘通过 Prometheus 和 Grafana 展示所有关键指标：前端请求数、Nginx拦截数、应用层排队数、Redis命中/失败数、MQ积压数、订单创建成功/失败数、各环节延迟等。通过**分布式链路追踪 (Jaeger)**，我们可以快速定位任何一个慢请求或错误请求的根源。”
  • **预案与演练 (Contingency Plan & Drills)**：
    • “我们设计了详细的降级、熔断和限流预案，并通过配置中心实现动态开关。例如，可以一键降级，跳过复杂的风控和排队逻辑，直接进入Redis层；或者在Redis集群故障时，一键切换到备用集群或降级到数据库。所有这些预案，我们都会定期进行混沌工程演练，确保在真实故障发生时，预案是有效的。”

完善后的项目能够抗多少 QPS？

这个问题的回答方式，关键在于展示你的分析过程和对瓶颈的理解，而不是给出一个固定的数字。

回答模板：

“这套经过深度优化的系统，其最终的QPS瓶颈取决于承担核心原子操作的Redis集群的性能，以及前端接入层服务器集群的总处理能力。”

1. 瓶颈分析：
“经过层层过滤，数据库已不再是瓶颈。核心压力点在于应用层的Redis Lua脚本执行。一个高性能的Redis实例，处理我们设计的这个包含SISMEMBER、GET、DECR、SADD的Lua脚本，保守估计其QPS可以在 4-5万 左右。这是单个热点商品的理论瓶颈。”

2. 水平扩展能力：
“这套架构的真正威力在于其极佳的水平扩展能力。

    • 应用层：是无状态的，可以通过增加机器数量线性地扩展。如果我们部署20台应用服务器，整个应用集群就能轻松处理数十万甚至上百万的入口QPS。

  • Redis层：

    • 对于多商品秒杀：我们可以将不同的秒杀商品通过 Hash Tag 分配到Redis集群的不同节点上，实现并发处理多个秒杀活动，总QPS就是集群中节点数 * 单节点QPS。
    • 对于单商品超高并发秒杀：我们会启用库存分片策略。将1000件库存分散到10个Redis节点上，每个节点负责100件。这样，单个商品的QPS瓶颈就被放大了10倍，理论上可以达到 40-50万。

3. 最终结论：
“综上所述，通过合理的容量规划和水平扩展：

  • 对于单个热点商品的秒杀，通过库存分片，这套架构可以稳定支撑 数十万级别（例如30-50万）的有效秒杀QPS。
  • 对于平台级的多商品同时秒杀，通过横向扩展应用服务器和Redis集群，整个系统的QPS承载能力可以轻松扩展到百万级别。”
#原创 #系统设计
构建一个高可用的、层层递进的秒杀系统
https://blog.longpi1.com/2025/09/16/构建一个高可用的、层层递进的秒杀系统/