背景要求

【业务背景】

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

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

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

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

• 老板要求万无一失。

【技术背景】

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

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

• 目前只有单机房。

架构设计

系统目前销售的总商品种数不超过 200，且秒杀商品为两种：1. 1000 个充电宝；2. 12 台 iPhone12。

日活用户大约 100 万，预估参与秒杀活动的用户数为平时的 3～5 倍，秒杀期间日活跃用户可达约 500 万。

【存储架构】

1. 存储性能估算

• 注册数据：百万日活用户，注册总用户量应为千万级以上。秒杀活动可能会同时吸引一些新用户注册，但主要活动群体还是老客户，所以新注册量级可忽略。

• 用户登录数据：根据秒杀峰值预估，秒杀期间按一天 500 万参与用户(包括浏览)计算。由于 App 会在一定有效时间内缓存用户登录信息，同时用户登录会主要分散在秒杀开始前，所以秒杀时登录的 QPS 不会产生太高的峰值，预估一天内大约五百万登录请求。

• 订单数据：

• 秒杀商品本身数量较少，大部分请求会被限流或拒绝，同时考虑到取消订单等情况，秒杀商品能产生的有效订单数量大约在千至万条，相对较少；

• 对于平台销售的其他商品，在秒杀活动引流的同时也会有订单增加，按 5%参与用户来计算订单量，预估一天 25 万订单数据。订单写入数据库请求 QPS 峰值可达 5～10 万(大部分请求已通过前端限流，服务器限流，以及缓存库存校验进行过滤)。

• 商品数据：预估秒杀峰值时同时活跃用户可能达 300 万左右，则商品读取 QPS 可达约 300 万(包括 Get/List 请求，其中大部分经由缓存，不会到达数据库)。

2. 存储架构设计

用户信息及订单交易信息都使用 MySQL 存储。

商品信息元数据也使用 MySQL 存储，商品信息文件数据则在分布式文件系统如 HDFS。

本系统目前不考虑发送消息等用例，交易相关数据都使用 MySQL 存储，Redis 则主要做分布式缓存。

MySQL 集群：主备复制+分库分表

【计算架构】

1. 负载均衡

采用多级负载均衡架构，考虑到创业公司背景及业务量级，暂不使用 F5/LVS，使用多个 Nginx 配合多个虚拟 IP。

2. 缓存

只有下载 App 才能参与活动，对于本次秒杀活动可以主要采用 App 内缓存，配合 Web 容器缓存和分布式缓存。同时，对于上架商品的各种图文视频信息等静态资源，可以使用 CDN。

3. 接口高可用

• 限流：在 App UI 上进行秒杀请求限流；在接入端限制用户请求频率；同时允许服务器根据处理能力进行限流。

• 排队：引入队列，将秒杀请求进行异步处理。

• 降级：故障应急时降级其他相对非核心业务，如日志服务，或秒杀高峰期暂停退货请求等。

• 熔断：下游接口故障时，一定时期不再调用，防止链式效应。

【微服务架构】

团队已经落地微服务架构。拆分出新的秒杀服务以便于对商品秒杀活动进行单独管理(另一个可选方案是合并至商品服务)，并且与已有的订单等服务进行交互，配套使用已有的微服务基础设施。

【高可用架构】

目前是单机房。由于项目预期可靠性要求较高，根据目前用户量级，可以先演进为同城双活。同时后续考虑在业务增长过程中有需要时进一步演变为异地多活。

【大数据架构】

使用 ClickHouse 进行交易和浏览等综合数据分析，兼容 SQL，使用和维护相对较简单。(可考虑团队具体背景，已有其他平台的情况下使用团队现有平台。)