模块九 电商秒杀系统设计

【业务背景】

你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：

1. 你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类；

2. 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone 12 作为秒杀商品；

3. 正常的日活大约 100 万用户；

4. 老板要求万无一失。

【技术背景】

1. 技术团队以 Java 为主，已经落地了微服务架构；

2. 主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；

3. 目前只有单机房。

业务基本场景

对前面的业务背景描述，进行核心业务场景假设，秒杀系统核心系统包括：

1. 秒杀商品详情系统，

2. 秒杀交易系统

3. 商品库存系统

4. 支付系统

存储架构设计

存储性能估算

1. 用户信息

日活 100W 的系统，假设日活用户占 10%，注册用户有 100/10% = 1000W

1. 商品信息

正常售卖商品数：10 个品类，每个品类不超过 20 个商品，总商品数目为：10*20=200 个商品，假设定期会对这些热销和好评的商品进行更新，更新评率为每周更新所有 200 个商品，为满足未来 2 年的增长，200*52*2=20000+商品

由于秒杀系统仅 618 使用，因此无需隔离热点商品信息，如后续需要演进为每日秒杀的系统，则可以做单独的热点商品存储和正常商品隔离

1. 库存信息

假设每个上架的商品都是有库存的，库存记录数大致 20000+

秒杀库存，是否需要设计隔离的热点商品库存也看是否会演进每日秒杀的系统

1. 订单信息

假设该电商系统 100W 日活用户，实际每日下单的用户占 50%，每日产生 50W 订单，满足未来 2 年增长 365*2*50=3.65 亿订单数据

1. 支付信息

假设下单的用户都进行了支付，少量因为订单因为各种填写错误等原因未支付的订单，因此支付账单约 3.65 亿

存储架构设计

数据特点分析：

1. 商品信息相对固定，包含商品介绍，图片等静态资源信息，读多写少，适合通过读写分离的方式，提高读性能的支撑，

2. 库存数据，频繁读写，对应秒杀场景，单库无法支撑写请求时，可通过库存拆分的方式分担写压力

3. 订单数据，支付数据未来可能持续增长，且数据量较大（上亿记录），存在明显的冷热特性，因此考虑对数据进行分片，按月拆分, 先做水平分表，后续再考虑分库

根据上面的分析，存储架构设计包括

1. 分为商品、库存数据库、订单库、支付账单库，可先采用 MySQL 主从架构

2. 商品详情页动静资源分离，静态资源通过引入 CDN 存储进行加速

3. 用户信息、一些动态缓存的内容，以及秒杀过程中排队，可以考虑引入 Redis, 采用多机的 Cluster 架构

计算架构设计

计算性能估算

1. 查看商品详情：假设 100W 用户全部参与秒杀，查看商品的 QPS 为 100W

2. 下单秒杀：比如增加答题等设计拦截下单请求，下单过程分散到 1~3 秒，下单 TPS 大致到 30W

3. 支付：支付过程由于一般较长，假设一般要 10 秒完成，支付 TPS 为 10W

计算架构-负载均衡设计

采用多级负载均衡架构

1. 第一级 DNS 采用专门的秒杀域名，和主站分离

2. 第二级采用 LVS 集群，第三级采用 nginx 集群

计算架构-缓存设计

采用多级缓存架构设计

1.CDN 缓存静态商品信息，拦截大部分商品 QPS

2.APP 端缓存，秒杀预告预先放出了商品信息，可缓存部分资源到 APP 内部缓存

3.应用程序本地缓存，可存商品信息等

4.分布式缓存 RedisCluster 集群，存储用户信息，商品信息，秒杀限流任务队列