写点什么

电商秒杀系统架构设计

作者:AHUI
  • 2022 年 1 月 23 日
  • 本文字数:1671 字

    阅读完需:约 5 分钟

一、需求背景

1.1 业务背景

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

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

2.本次 6.18 秒杀选择了 1000 个充电宝,10 台 iPhone12 作为秒杀商品;

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

4.老板要求万无一失。

1.2 技术背景

1.技术团队以 Java 为主,已经落地了微服务架构;

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

3.目前只有单机房。

二、总体设计思路

2.1 场景分析

采用 5W 分析法,发现创业公司的电商平台主要是吸引用户下载手机 APP 来参与商品秒杀活动。正常电商平台的日活大约 100 万用户,加上平台秒杀活动推广,结合日活用户可估算秒杀时间峰值用户达到约 500 万。

用户参与商品秒杀活动,关键行为是商品浏览、商品秒杀。

三、存储架构设计

3.1 存储性能预估

3.1.1 商品浏览

已知秒杀活动开始前 60 秒,500 万用户已经登录并开始选择秒杀产品,用户通过持续刷新界面,估算 60 秒内用户会重复刷新 5 次,保证界面秒杀时间倒数正常,由于商品详情页面是静态数据,可以采用 CDN 和静态资源缓存,减少 90%的访问量。

QPS 计算如下:500W*5/60*0.1= 41000/S

商品浏览和刷新无需保存数据,只要保存充电宝和 Iphone2 种商品数据,存储量非常小。


3.1.2 商品秒杀

商品秒杀核心在于层层过滤,逐渐递减瞬时访问压力,减少最终对数据库的冲击,秒杀请求量较大,防止请求直接到达后端服务器,采用请求端限流,比如生成随机数、按钮变灰等手段,由于参与秒杀的商品为 1010 个,我们可以挡掉 90%请求,对用户来说无感

TPS 计算如下:500W * 0.1 = 50W/S

商品秒杀需要存储 1010 个商品订单数据,存储量较小,但是要求性能较高

3.2 存储方案

3.2.1 商品浏览

参与秒杀商品的品种只有 2 类,数据量非常小,可以用原先系统的数据库进行存储,但是对于 500W 用户浏览商品,需要提前将 2 类的商品信息进行缓存在 redis sentinel。


3.2.2 商品秒杀

由于参与商品的总共数量只有 1010 个,只会生成 1010 个订单数据、库存数据,采用 Mysql 主备进行存储。

四、计算架构设计

4.1 业务场景计算性能估算

已知上面计算出商品浏览和商品秒杀的性能

商品浏览 QPS:500W*5/60*0.1= 41000/S

商品秒杀 TPS:500W * 0.1 = 50W/S

4.2 高性能计算架构设计

4.2.1 商品浏览

4.2.1.1 业务特性分析

商品浏览是一个典型的读操作,请求量较大,负载均衡架构和缓存架构都需要。

4.2.1.2 架构分析

由于用户量过 500 万,采用多级负载均衡架构,覆盖 DNS->F5->Nginx->网关的多级负载均衡。

4.2.1.3 架构设计

负载均衡算法选择:所有用户都可以直接看评论,因此将请求发送给任意服务器都可以,这里选择“轮询”或者“随机”算法。

业务服务器数量估算:业务服务器数量估算假设 CDN 能够承载 90%的用户流量,那么剩下 10%的商品浏览请求进入系统,则请求 QPS 为 41K/s* 10%=4.1K/s,由于读取微博的处理逻辑比较简单,主要是读缓存系统,因此假设单台业务服务器处理能力是 1000/s,则机器数量为 40 台,按照 20%的预留量,最终机器数量为 50 台。

4.2.1.4 高可用计算架构设计

3.2.2 商品秒杀

3.2.2.1 业务特性分析

商品秒杀是一个典型的写操作,因此不能用缓存,可以用负载均衡。

3.2.2.2 架构分析

由于用户量百万,采用多级负载均衡架构,覆盖 DNS->F5->Nginx->网关的多级负载均衡。

3.2.2.3 架构设计

负载均衡算法选择:由于商品秒杀是依赖用户登录信息,所有商品秒杀的时候可以任意发给服务器处理,这里可采用“轮询”或者“随机”算法

业务服务器数量估算:商品秒杀的 TPS 为 50W/s,由于应用服务器采用微服务架构,目前基本都是基于 TomcatWeb 容器,Linux 的 Tomcat 允许每个进程可支持 1000 个线程数,要完成 50W/S 的 TPS,需要 500 台服务器,加上一定预留量,600 台服务器差不多。

3.2.2.4 高可用计算架构设计


五、其他架构设计

5.1 可扩展架构设计

电商秒杀业务场景是比较独立的业务,为不影响原系统功能,需单独拆封独立秒杀服务。

5.2 高可用架构设计

由于商品秒杀是特殊的独立业务,可以采用业务定制型异地多活,同城双中心即可。

用户头像

AHUI

关注

还未添加个人签名 2019.07.04 加入

还未添加个人简介

评论

发布
暂无评论
电商秒杀系统架构设计