百万电商秒杀架构设计

【业务背景】

你作为一个电商创业公司的架构师，负责设计 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. 日活用户 100 万，在秒杀活动期间，至少会有 3~5 倍的用户参与，架构设计至少参照百万级别架构设计。

3. 老板要求万无一失，要考虑高可用，目前只有一个机房，所以需要申请云资源。

4. 团队已经落地微服务，而秒杀活动的流量很高，所以在原有的 spring Cloud 基础上，单独开一些服务，专门做秒杀。

5. 创业型公司，技术人员不会太多，作为业务重点的秒杀活动，可用根据需求找 12 个人做后端，andorid3 个，ios3 个。

总体架构思路

1. 正常日活用户 100 万用户，大概有 60%~120%的用户会参与秒杀活动，所以架构按照百万用户级别参与秒杀设计，适应最大业务需求。

2. 客户端只有下载 App 才能参加秒杀活动，所以架构设计只考虑 App 的情况。

3. 秒杀活动不经常有，保持单机房不变。

存储架构设计

• 日活用户 100W，假设每个用户每天晚上 8 点-12 点之间下单一次，那么每天就有 100W 数据，从数据量上来看，存储需要分库分表，读写分离。

  TPS:100W/4/3600=69.4。

  活动当天，推断用户数量增加，那么假设为平日的 3 倍，那么就有 300W 用户参与当天的 618 活动。

  TPS:100W/4/3600*3=208.33。

  秒杀商品只有 1000 个充电宝，10 台 iPhone 12，由于只有 APP 用户才能参与秒杀，所以并不是人人都会参与秒杀，故假定参与秒杀的人数为 1/3，那么就有 100W 人参与秒杀。

  由于是电商系统，有许多的商品图片等，可以采用图片服务器来单独存放商品图片。

  秒杀系统部分使用 redis cluster 作为库存部分。

• 秒杀开始时，为了支撑大量高并发的商品库存查询，用 Redis Cluster 支持。

• 商品库存扣减和订单操作数据量不大，依旧用 MySQL 支持。

计算架构设计

• 登录

估计有 60~120 万用户登录，考虑到 50%用户可能会集中在秒杀时间前 1 个小时登录，登录的 TPS 值：

50 万/3600 ≈ 140

• 秒杀

估计有 60~120 万用户会在前 2 秒内参与秒杀，绝大部分是读请求。秒杀的 QPS 值：30 万~60 万

计算架构设计之负载均衡

计算架构设计之缓存架构

• App 缓存+web 容器缓存+分布式缓存

• 使用 APP 缓存和 WEB 缓存将大量静态页面保存起来，秒杀时静态页面从 APP 或 Web 获取，减轻后端压力。

• 秒杀开始后，为支持大量库存查询请求，使用 redis 保存库存，分布式缓存使用 redis，为应对大流量，redis 采用 redis cluster 方式部署