在上一讲的实现方案里我们讨论了采用纯数据库的扣减实现方案,如果以常规的机器或者 Docker 来进行评估,此方案较难实现单机过万的 TPS。之所以介绍,是想告诉你,架构是面向业务功能、成本、实现难度、时间等因素的取舍,而不是绝对地追求高性能、高并发及高可用等非功能性指标。
另外,在上一讲里介绍的扣减业务的技术实现需求点、数据库表结构信息等内容,其实是和技术无关的,它们属于通用的基本信息和标准定义。因此,今天我们讲解的方案将直接复用以上信息,不再赘述,有忘记的或者直接跳读此讲的同学可以翻到上一讲进行复习。
这一讲,我将由浅入深地介绍如何基于缓存来实现单机万级这一并发扣减目标。
纯缓存方案浅析
纯数据库的方案虽然避免了超卖与少卖的情况,但因采用了事务的方式保证一致性和原子性,所以在 SKU 数量较多时性能下降较明显。
注:事务本质上有四个特点 ACID:原子性(Atomicity)、一致性(Consistency )、隔离性(Isolation)及 持久性(Durability)。
因为扣减有一个要求即当一个 SKU 购买的数量不够时,整个批量扣减就要回滚,因此,我们需要使用类似 for 循环的方式对每一个扣减 SQL 的返回值进行检查。另外一