设计电商秒杀系统

百万用户规模存储性能估算

注册

由于日活用户大约是 100 万，我们假设用户注册数量已经达到了 500 万

登录

假设 618 当天有 80%的用户活跃，即 618 当天登录用户量(参与 618 用户量)为 500 万 * 80% = 400 万

商品

618 当天整天都进行秒杀，假设秒杀商品有充电宝和 iphone12 两种商品

同时还有其他商品 10 万种商品进行销售，只是不做秒杀活动，即需要存储 10 万商品数据

下单

假设 1000 个充电宝和 10 台充电宝全部售罄

同时其他共计 20 万商品全部售罄(日常下单量)

下单量这里以 20 万来计算，即每天需要存储 20 万条下单数据

存储架构设计

1、500 万用户注册信息，10 万种商品，每天 20 万订单

2、由于订单量比较大，最新的订单表只存储近一个月的数据，

其他时间的订单存放到历史表，按照数据量进行分区存放，如每 500 万做一个分区

1、秒杀商品的商品数量，放在 redis 中

下单时，先从 redis 扣减库存，成功再下单

2、商品详情也放在这里，可减少数据库操作

百万用户规模计算性能估算

注册

虽然有 500 万用户注册，假设是 5 年才积累起来的，注册的 TPS 低

登录

假设有 400 万用户 618 当天都登录

假设登录时间集中在早晚 4 小时

登录 QPS 均值 = 400 万 / 14400 = 300

浏览秒杀商品页面

不做秒杀活动的商品这里不做重点考虑

我们假设用户充电宝和 iphone12 两个页面都浏览，由于 20%用户来浏览秒杀商品多次，假设平均每个用户打开 5 次页面

假设秒杀集中在早中晚三个时间段的 6 小时内

商品浏览 QPS = 400 万用户 * 20%(只有 20%用户来参加秒杀) * 2 种秒杀商品 * (每个秒杀商品看 5 次)  / (3600 * 6)= 370  我们做 5 倍左右的冗余

QPS = 2000

下订单

假设秒杀集中在早中晚三个时间段的 6 小时内

下单量这里以 50 万来计算

下单 TPS = 50 万 / (3600 * 6) = 23

这里我们做一定的冗余，取该值的大约 10 倍来计算

即 TPS = 200

假设一台业务服务器能承受 500 的请求量，我们做一定冗余，这里部署 8 台

计算架构之负载均衡

计算架构之存储架构

为了加快商品的详情访问，商品相关的照片和前端 js、html 等，使用 CDN 存放，可以加快第一次访问

高可用架构设计 – 同城双中心

虽然目前只有一个机房，按照老板的要求，要做到万无一失的话，则需要部署两个机房

这里选择同城双中心，原因是同城双中心比异地多活成本低

可扩展架构设计 – 微服务拆分

根据三个火枪手原则，由于目前开发团队只有 24 个人(12 后端 + 6 前端+ 6 测试)，因此划分为 6 个服务 (平均三个开发人员负责一个微服务，两个后端+一个前端)