电商秒杀系统

需求/分析

需求：

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

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

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

• 老板要求万无一失。

• 为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动

重点需求分析：

• 秒杀 1000 个充电宝，10 台 iPhone 12 ；

• 设计成 0、9、12、15、20 整点秒杀；

• 预计估算 6.18 当天日活大约 100 * 5 万用户；

• 高可用、高性能、可伸缩满足老板的万无一失；

核心功能复杂度分析

登录

• 6.18 秒杀活动，登录的用户预计会高于平常的 5 倍，50%在活动 6.18 之前就登录，50%会当天登录。所有大概登录量为：500w * 50% = 250w，平均每秒钟为 250w / 活动前 4 小时内 * 60 * 60 ≈ 200 用户

下单

• 由 6.18 秒杀活动带来其他商品的下单量，假设平均 1 个用户购买 2 件商品，时间分别在高峰期 8：00 —10：00，12：00 — 14：00,20:00 — 22:00，所以下单量预估为,500w * 2 = 1000w，分别在不同时间段的订单量为 350w；所以订单量： 350w / 2 * 60 * 60 ≈ 500 笔/s

支付

• 下单后不一定支付，预估 90%都会支付，因此支付量为 1000w * 90% = 900w 笔，每秒 450 笔

商品浏览

• 浏览商品是必须的功能 ，预计所有用户都会至少浏览 10 件商品，则大约请求量为： 500w * 10 = 5000w，按照高峰 6 小时计算，大约每秒请求为：5000w / 6 * 60 * 60 ≈ 2500 笔/s

秒杀

• 设计成 0、9、12、15、20 整点秒杀；假设每次参与秒杀的人数为 80%，那么下单量为 500w * 80% = 400w/s

存储性能预估

登录

• 预计存储量为：用户 ID（20bytes） + 姓名（50bytes） + 电话（20bytes） + 登录方式（2bytes） + 登录时间（8bytes） + 登录状态（1bytes） + 其他信息（50bytes） = 160bytes

• 6.18 当天登录记录 500W（包括新下载 APP 用户），存储量约 800MB。

订单

• 商品 ID、支付状态、发货状态、订单状态、收货信息、创建时间等，大约占 300bytes

• 6.18 当天订单记录 1000w,存储量大概位 3GB

商品信息

• 商品描述、图片，10 个种类 * 20 个 = 200 个商品，该存储量描述信息可以忽略、图片按 1 个商品 6 个 2MB 的图片计算，存储量大概位 200 * 6 * 2 ≈ 3GB。

购物车

• 选择的商品，按 1 亿客户量来预估，一个购物车平均装 5 件 50bytes 大小已选商品，大概存储占：1 亿 * 5 * 50 ≈ 25GB

用户信息

• 地址，按 1 亿客户量来预估，每个客户 2 个 200bytes 大小地址，大概存储占：1 亿 * 2 * 200 ≈ 40G

存储架构设计

redis:

其他子系统：

订单系统：

数据量：登录：500w,800MB、订单：1000W，3GB

之所以订单的存储架构位 mysql 分片，主要考虑到订单系统数据量比较大，增长速度会日益增加。所以采用分片架构， 而其他数据量比较小的就按主备，以后可以考虑切换位分片。

redis 主要用来实现秒杀业务，可以通过它实现分布式锁、缓冲用户秒杀请求。

计算架构负载均衡

按照核心功能的分析，采用 nginx，每台最大承载量为 5 万，那就需要 80 台。

计算架构缓存架构

应用接收到请求后，缓冲用户的秒杀请求。