秒杀系统的本质：一个把巨大预约量层层过滤成极小真实写流量的沙漏结构

秒杀系统的存在，本质上是为了解决一个规模差距悬殊的问题：假设一个商品的预约抢购人数达到1500万，如果这1500万人同一时刻的请求都不经过滤直接冲击到后端下单和库存系统，任何系统都扛不住；但真正会成交的订单量往往只是其中很小的一部分（受限于库存本身）。秒杀系统的架构思路是设计一个逐层过滤的”沙漏”结构：最外层先用IP、PIN（用户标识）等风控数据和业务规则（用户提交的频率——一秒钟提交多少次、一分钟提交多少次是否异常）过滤掉明显的异常和重复请求；再往里验证用户是否有预约资格、收货地址是否有效等业务前置条件，只有通过所有这些层层校验的请求，才会真正被放行调用到接单系统。这样设计之后，真正落到接单系统、需要执行写操作的流量，会被压缩到一个远小于最初预约量的规模——案例中提到接单提交服务甚至只需要单独两台机器承接，因为经过前面层层过滤后，真正到达这一步的流量只有几十万这个数量级，两台机器完全可以承载，后端存储也因此得到了保护。这个”沙漏”结构揭示了秒杀系统设计的核心矛盾和解法：入口端的量级和最终成交端的量级天然存在数量级差异，与其试图让整个系统的所有环节都具备承接峰值全量的能力（成本极高且大部分容量平时用不上），不如把这种数量级差异显式地设计进架构本身——让流量在向后传递的每一层都被逐步过滤收窄，只有真正有效的那一小部分才配得到后端最宝贵、最难以水平扩展的写入能力。

结构图：

flowchart TB
    A["预约抢购流量\n1500万用户同时到达"] --> B["第一层：IP+PIN风控过滤\n(提交频率异常检测)"]
    B --> C["第二层：业务规则限流\n(每商品每日订单量/每用户每日下单量)"]
    C --> D["第三层：资格验证\n(是否已预约/常用地址是否有效)"]
    D --> E["接单系统\n(仅需2台机器承接\n最终写流量仅几十万级)"]
    E --> F["存储层得到保护\n未被原始1500万流量直接冲击"]