写点什么

模块九 电商秒杀系统设计

用户头像
小牧ah
关注
发布于: 刚刚

【业务背景】

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

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

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

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

4. 老板要求万无一失。

【技术背景】

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

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

3. 目前只有单机房。


业务基本场景

对前面的业务背景描述,进行核心业务场景假设,秒杀系统核心系统包括:

  1. 秒杀商品详情系统,

  2. 秒杀交易系统

  3. 商品库存系统

  4. 支付系统


存储架构设计


存储性能估算


  1. 用户信息

日活 100W 的系统,假设日活用户占 10%,注册用户有 100/10% = 1000W

  1. 商品信息

正常售卖商品数:10 个品类,每个品类不超过 20 个商品,总商品数目为:10*20=200 个商品,假设定期会对这些热销和好评的商品进行更新,更新评率为每周更新所有 200 个商品,为满足未来 2 年的增长,200*52*2=20000+商品

由于秒杀系统仅 618 使用,因此无需隔离热点商品信息,如后续需要演进为每日秒杀的系统,则可以做单独的热点商品存储和正常商品隔离

  1. 库存信息

假设每个上架的商品都是有库存的,库存记录数大致 20000+

秒杀库存,是否需要设计隔离的热点商品库存也看是否会演进每日秒杀的系统

  1. 订单信息

假设该电商系统 100W 日活用户,实际每日下单的用户占 50%,每日产生 50W 订单,满足未来 2 年增长 365*2*50=3.65 亿订单数据

  1. 支付信息

假设下单的用户都进行了支付,少量因为订单因为各种填写错误等原因未支付的订单,因此支付账单约 3.65 亿


存储架构设计


数据特点分析:

  1. 商品信息相对固定,包含商品介绍,图片等静态资源信息,读多写少,适合通过读写分离的方式,提高读性能的支撑,

  2. 库存数据,频繁读写,对应秒杀场景,单库无法支撑写请求时,可通过库存拆分的方式分担写压力

  3. 订单数据,支付数据未来可能持续增长,且数据量较大(上亿记录),存在明显的冷热特性,因此考虑对数据进行分片,按月拆分, 先做水平分表,后续再考虑分库


根据上面的分析,存储架构设计包括

  1. 分为商品、库存数据库、订单库、支付账单库,可先采用 MySQL 主从架构

  2. 商品详情页动静资源分离,静态资源通过引入 CDN 存储进行加速

  3. 用户信息、一些动态缓存的内容,以及秒杀过程中排队,可以考虑引入 Redis, 采用多机的 Cluster 架构

计算架构设计


计算性能估算

  1. 查看商品详情:假设 100W 用户全部参与秒杀,查看商品的 QPS 为 100W

  2. 下单秒杀:比如增加答题等设计拦截下单请求,下单过程分散到 1~3 秒,下单 TPS 大致到 30W

  3. 支付:支付过程由于一般较长,假设一般要 10 秒完成,支付 TPS 为 10W

计算架构-负载均衡设计

采用多级负载均衡架构

  1. 第一级 DNS 采用专门的秒杀域名,和主站分离

  2. 第二级采用 LVS 集群,第三级采用 nginx 集群

计算架构-缓存设计

采用多级缓存架构设计

1.CDN 缓存静态商品信息,拦截大部分商品 QPS

2.APP 端缓存,秒杀预告预先放出了商品信息,可缓存部分资源到 APP 内部缓存

3.应用程序本地缓存,可存商品信息等

4.分布式缓存 RedisCluster 集群,存储用户信息,商品信息,秒杀限流任务队列


用户头像

小牧ah

关注

还未添加个人签名 2018.02.24 加入

还未添加个人简介

评论

发布
暂无评论
模块九 电商秒杀系统设计