16 秒杀场景如何保证命中的存储分片不挂

从“第 12 讲”到“第 14 讲”，我们介绍了可以应对百万并发扣减请求，以及同时能够保障高性能的架构方案。此外，上述的架构方案还具备水平扩展能力，即当流量增加后，可以通过扩容底层存储和应用服务器来应对。

但面对百万并发的极端场景，比如大量用户在同一时间内抢购同一商品，前几讲介绍的几种方案就不能有效地应对了。此外，我们在“第 06 讲”里，介绍过热点查询的应对方案，是否可以直接复制来应对热点扣减呢？答案显然是不能的。

因此，在本讲里，我将先向你介绍热点扣减的业务特点，以及它与热点查询的区别，然后再循序渐进地介绍热点扣减的有效应对方案。

热点扣减的典型业务场景

热点扣减有一个被大家熟知的名称，叫作秒杀。其实，秒杀并不等同于热点扣减，只是因为商品秒杀是热点扣减里最具有代表性、也最能体现热点扣减特点的场景，所以我们常常以秒杀代指热点扣减。秒杀的特点主要有以下两点。

首先，秒杀带来的热点量非常大，其他热点场景很难比拟。比如，在刚过去的 2020 年，大家在电商平台里准点抢购口罩，上百万人同时在线抢购同一商品，此时就带来了超大并发量。

其次，秒杀对于扣减的准确性要求极高。秒杀在绝大部分场景里是一种营销手段，如一元抢 iPhone。商家对有限的商品设置一个亏本价，吸引用户下载或注册 App，达到拉新、提升知名度等目的。因为是亏本营销，如果出现了大面积的超卖，业务上是绝不允许的。

除了秒杀之外，其余的扣减场景，如账户金额的扣减、收费文章免费试读次数的扣减等场景，均很难同时满足上述两个要求，所以它们不是热点扣减的代表性场景。

在如何保障不超卖的问题上，