栏目分类:
子分类:
返回
名师互学网用户登录
快速导航关闭
当前搜索
当前分类
子分类
实用工具
热门搜索
名师互学网 > IT > 软件开发 > 后端开发 > Java

架构训练营-电商秒杀系统

Java 更新时间: 发布时间: IT归档 最新发布 模块sitemap 名妆网 法律咨询 聚返吧 英语巴士网 伯小乐 网商动力

架构训练营-电商秒杀系统

一、背景

1.1【业务背景】

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

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

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

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

  4. 老板要求万无一失。
    1.2【技术背景】

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

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

    目前只有单机房。

1.3【业务基本场景】

1.只有下载 App 才能参加秒杀活动。

2.秒杀页面对畅销和好评的商品进行推荐销售。

3.订单需 30 分钟内支付。

4.支付依赖第三方支付平台。

二、设计思路

2.1.独立部署

避免对其他业务产生影响,秒杀系统和 Redis 集群独立部署,使用独立的域名。

2.2.减少到后端服务器的请求数

系统做动静分离,静态资源上传到 CDN。

利用 APP 缓冲。

2.3.流量消峰

秒杀时通过答题,防止秒杀器和延长用户提交请求的时间。

2.4.限流

APP 端随机丢弃部分请求,只有 20%请求进入后端服务。

如用户秒杀成功,APP 端将不可再参与秒杀活动。

后端服务随机丢弃部分请求,只有 20%请求最后能访问 redis 集群中的库存数据进行秒杀,可在后端系统配置请求通过率并实时生效。

2.5.库存减扣

秒杀商品件数缓存到 redis 集群中,每一种商品都创建一个 list,该商品的秒杀件数有多少,list 中的元素就有多少个,每次下单就从 list 中弹出一个元素,防止超卖。

秒杀成功的用户放入 SET 中,防止多次抢购。

三、存储架构设计

3.1 存储性能估算

下载

iOS 安装包 50M,Android 安装包 60M,APP 安装包已上传 CDN。

注册

因为 6.18 大促的前期宣传,注册数每天增加 3 万,但数据量没有质的飞越,可以忽略不计。

登录

正常日活用户 100 万,6.18 大促登录数据是每天 200 万。

浏览商品

2 件秒杀商品,200 件推荐商品。静态资源需要提前推送 CDN,秒杀商品件数缓存到 redis 集群中。

秒杀

6.18 大促登录数据是每天 200 万,假设有 60%的用户参加秒杀,每个用户参加 2 次秒杀答题,题库数据量为:200 万 * 60% *2 = 240 万。需要题库数缓存到 CDN 中。

充电宝和 iPhone 12 合计 1010 台 ,1010 条下单记录。

支付

同下单,合计为 1010 条记录。
3.2 存储架构设计

支付和订单处理,数据量不大,沿用原有 Mysql 主备。

避免对其他业务产生影响,Redis 集群独立部署。

四、计算架构

4.1 计算性能估算

下载

6.18 大促登录数据是每天 200 万,假设有 60%的用户参加秒杀,同时其中 40%用户需要下载 APP,下载多发生在秒杀前 8 小时内。

下载量:200 万 * 60% *40% =48 万。

下载量 QPS:48 万 / (8 * 60 * 60) ≈ 16.8 次/秒

因下载是非核心业务,这里先假设原来的 CDN 可以满足需求。

注册

每日新注册用户不到 3 万,可以忽略。

登录

6.18 大促登录数据是每天 200 万,假设登录时间集中在早晚 4 小时,登录 TPS 均值:200 万 / 14400 = 140。

浏览商品

6.18 大促登录数据是每天 200 万,假设有 60%的用户参加秒杀,秒杀前 5 分钟开始进入商品浏览页面,查看秒杀商品和推荐商品,假设每人查看 10 个商品。

查询数量为:200 万 * 60% *10 = 1200 万查询。

查询 QPS 为: 1200 万 / (5 *60) = 4 万/秒

秒杀

6.18 大促登录数据是每天 200 万,假设有 60%的用户参加秒杀,20%请求进入后端服务,因为有答题,秒杀 2 秒完成,因此秒杀 QPS 均值:200 万 * 60% *20% / 2 = 12 万。

因为后端服务保留 20%的请求,因此访问 redis 集群中秒杀件数的 TPS 均值:12 万 *20% =2.4 万。

1010 条下单记录,2 秒内完成(假设秒杀持续了 2 秒),下单 TPS 均值:1010 /5 =505。

支付

支付预计在 1 分钟内完成,TPS 为:1010 /60 ≈ 16.9 ,可以忽略不计。
4.2 计算架构之负载均衡

4.3 计算架构之缓存架构

五、可扩展架构设计

5.1 微服务拆分

5.2 、内部服务间通过消息队列进行调用

为了避免下单、支付等服务产生数据库死锁,给每种商品建立一个消息队列,消峰、解耦的同时避免数据库资源的竞争。

转载请注明:文章转载自 www.mshxw.com
本文地址:https://www.mshxw.com/it/1002968.html
我们一直用心在做
关于我们 文章归档 网站地图 联系我们

版权所有 (c)2021-2022 MSHXW.COM

ICP备案号:晋ICP备2021003244-6号