1 概述

【业务背景】

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

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

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

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

4. 老板要求秒杀活动万无一失。

【技术背景】

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

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

3. 目前只有单机房。

2 架构概览

3 存储架构

3.1 存储性能估算

【注册】

近 300 万的注册用户注册用户。

【登录】

平日用户登录约 30%，近 90 万的日活用户。

【秒杀】

• 商品查看：秒杀当日，活动开始前后的 30 分钟，用户登录约 80%，秒杀期间访问 TPS： 240 万/3600 约等于 600+QPS。

• 购买商品：瞬时抢购，带来的瞬时 TPS 最大为 1000；所有秒杀请求进入消息队列，只有最靠前的 1000 个请求才会进入数据库。

3.2 存储架构

【关系数据】

【缓存数据】

4 计算架构

4.1 计算性能估算

【注册】

每日注册新用户不到 1 万，可以忽略不计。

【登录】

平日用户登录约 30%，近 90 万的日活用户。

【秒杀】

• 商品查看：秒杀当日，活动开始前后的 30 分钟，用户登录约 80%，秒杀期间访问 TPS： 240 万/3600 约等于 600+QPS。

• 购买商品：瞬时抢购，带来的瞬时 TPS 最大为 1000；所有秒杀请求进入消息队列，只有最靠前的 1000 个请求才会进入数据库，约 1000TPS。

4.2 计算性能架构

4.3 计算性能缓存架构

5 可扩展架构

【微服务拆分】

6 高可用架构

【同城灾备架构】

7 大数据架构

在百万架构数据分析选择 ClickHouse，可以支撑各种场景数据统计分析

• 支持类 SQL 查询

• 支持繁多的库函数

• 支持数据异地复制与部署

• 满足大数据运营场景