秒杀系统与 CAP 理论解构

发表于 分类于 本文字数： 1.2k 阅读时长 ≈ 4 分钟

秒杀系统因承接天量请求采用分布式，多节点导致网络分区（P），下单阶段用 AP 保可用、付款阶段用 CP 保一致性，业务上两种模式兼顾。

一、CAP 理论理解

在分布式系统中，CAP 理论表明：

  • C（Consistency）：所有节点看到的数据是一致的
  • A（Availability）：每个请求都能得到响应
  • P（Partition tolerance）：系统能够容忍网络分区

核心理解：

在网络分区不可避免的前提下，系统如果保证所有请求都能及时响应（A），就无法保证所有节点的数据实时一致（C）；反之，如果要保证实时一致（C），就必须在分区时拒绝或阻塞部分请求，从而牺牲可用性（A）。

工程上，网络分区是常态，而不是异常；P 是前提条件，不可选择，只能在 A 与 C 之间做取舍。

二、秒杀系统理解

秒杀系统的核心特性如下：

  1. 流量暴涨
    • 特定活动截止前请求量激增，单台服务器无法承受，需要分布式架构。
  2. 票据不能超卖
    • 座位有限，每个座位只能售出一次，最终一致性约束不可妥协。
  3. 付款成功才算真正成功
    • 下单与付款是两个阶段，下单只是获得付款资格，最终付款才是真正资源分配。

结合 CAP 理论：

  • 系统必须分布式（满足条件 1），因此存在 C 与 A 的选择。
  • 由于票据唯一性（条件 2），最终票务分配必须保证 C。
  • 下单阶段的可用性（条件 3）允许选择 A，以承接高并发请求。

三、秒杀系统的阶段拆解

根据业务约束和 CAP 理论，可以将秒杀系统拆解为两个阶段：

阶段 目标 CAP选择 特点
下单（AP阶段） 承接洪峰、快速响应 AP 弱一致、允许超卖、异步处理
付款（CP阶段） 确保票据唯一、支付一致 CP 强一致、阻塞或拒绝冲突、最终裁定资源归属

核心思想：AP 阶段先过滤和承接流量，CP 阶段裁定最终结果。
AP 阶段只是“获得付款资格”，CP 阶段才是真正票的归属。

四、下单阶段（AP）的经典实现方式

目标

  • 承受高并发流量
  • 快速响应用户
  • 尽量提前过滤掉大量不可能成功的请求

核心手段

  1. 无状态服务
    • 多节点承接请求，节点间不做同步，易于水平扩展。
  2. 缓存库存
    • Redis 或本地缓存保存剩余票数
    • 使用原子操作（Lua 脚本或 Redis INCR/DECR）快速扣减
  3. 削峰与限流
    • Nginx / Gateway 限流
    • 本地队列排队，提前拒绝不可能成功的请求
  4. 异步写入
    • 下单记录可写入 MQ 异步落库
  5. 允许短暂不一致
    • 超卖或重复请求可以存在，最终在 CP 阶段裁定

特点总结

  • 高可用：请求快速响应
  • 弱一致：库存可能超卖或重复
  • 技术核心：缓存原子操作、异步队列、无状态服务、削峰限流

五、付款阶段（CP）的经典实现方式

目标

  • 保证票据唯一
  • 确保支付与座位状态一致
  • 不追求极致吞吐，但必须保证强一致性

核心手段

  1. 单点/分片强一致写入
    • 座位表或票据表使用唯一索引
    • 付款时使用事务操作：检查是否售出、锁定座位、写订单/付款记录
  2. 行级锁或 CAS 原子操作
    • 保证同一座位只能被一个事务成功操作
  3. 幂等处理
    • 防止重复支付或重复请求
  4. 事务边界尽量小
    • 仅锁核心资源，避免长事务阻塞
  5. 错误与补偿机制
    • 支付失败或回调异常时，异步回滚座位锁定或库存

特点总结

  • 强一致：票据唯一、支付与座位严格绑定
  • 可控吞吐：并发量远低于 AP 阶段
  • 技术核心：事务、行级锁、唯一索引、幂等、补偿机制

六、AP 与 CP 的衔接

  1. AP 阶段承接洪峰，快速过滤请求，允许超卖和重复。
  2. CP 阶段裁定最终票据归属，确保资源唯一性与支付一致性。
  3. CAP 选择在业务关键点发生：
    • AP 阶段选择可用性（A）
    • CP 阶段选择一致性（C）

核心思想：在网络分区不可避免的前提下，系统通过延迟一致性约束而不是放弃一致性，实现整体高可用。