架构实战营模块九作业
题目
设计电商秒杀系统
【业务背景】
你作为一个电商创业公司的架构师,负责设计 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. 大约 10 页以内的 PPT,每页 PPT 说明一项设计,包括架构设计和设计理由,无需详细解释备选方案。
【提示】
1. 分析考虑要全面,但并不意味着架构设计要面面俱到,如果分析后认为某些设计点可以不做,就在作业最后统一说明原因即可;
2. 如果没有思路,请对照模块 9 的 IM 案例;
3. 如果有的信息觉得不够全或者不够细,可以做出一定的假设,但不能天马行空,需要对照已有的业务背景和技术背景进行合理推断
非功能需求分析
假设用户使用 APP 的高峰时间段为 6:00-8:30、12:00-13:30、18:00-24:00,共 10 个小时。由于日活 100 万用户,那么:
(1)登录:100 万次/天,TPS=100 万/(10*3600)=27;
登录业务与秒杀无关,是原有业务系统的基本功能,本次不做设计;
(2)注册:量很小;
注册业务与秒杀无关,是原有业务系统的基本功能,本次不做设计;
(3)浏览商品:假设平均每个活跃用户关注 2 类商品,并详细浏览排序前 10 的商品信息,那么 QPS=100 万*10/(10*3600)=277;
浏览商品业务与秒杀无关,是原有业务系统的基本功能,本次不做设计;
(4)下单:假设每个活跃用户平均每天购买 2 件商品,TPS=100 万*2/(10*3600)=55;
下单业务与秒杀无关,是原有业务系统的基本功能,本次不做设计;
(5)秒杀:假设所有活跃用户都参加秒杀活动,TPS=100 万;用户在秒杀前 10 分钟浏览秒杀商品信息页面,则 QPS=10 万;用户请求服务器时间 QPS=100 万。
秒杀排队设计
秒杀商品数据有限,先到先得,但 WEB 服务较多,请求需要进行排队,因此引入消息队列组件,充电宝和 iphone 秒杀请求分别使用各自的 topic 发到消息队列进行排队,所有秒杀服务作为消费者组订阅排队结果,如果订阅的请求数量超过商品的库存,则不再订阅,再有请求进来,直接返回已结束。
![](https://static001.geekbang.org/infoq/be/be8cfecfddc08686ec9643e845744ce8.png)
服务器时间同步设计
秒杀系统短时间 QPS 较大,请求时间 QPS=100 万(非功能需求页),为防止不同服务器时间不同步,可让 WEB 服务器定时每秒向服务器时间服务同步时钟。
![](https://static001.geekbang.org/infoq/a1/a1d66f8407e5f16d3947e285c853553c.png)
限流设计
秒杀系统的特点是商品数量很少,并发请求量非常高,可将绝大多数请求挡在网关,由于业务上秒杀商品只有充电宝 1000 个和 iphone 10 台,那么,每个网关只允许报入 1000 个充电宝秒杀请求和 10 个 iphone 秒杀请求,之后的请求都直接返回秒杀活动已结束。已报入的秒杀请求按 topic 进行排队(秒杀排队页),取最终的前 1000 个秒杀充电宝的用户和前 10 个秒杀 iphone 的用户,这些用户秒杀成功,返回成功页面,其他请求秒杀失败,返回秒杀活动结束页面。
![](https://static001.geekbang.org/infoq/07/07b7c1186ae62c2a634d362354266edd.png)
计算架构之负载均衡设计
由于秒杀的瞬间有 100 万的 TPS,使用 LVS 做第一级负载均衡,LVS 做第二级负载均衡,服务网关以随机或轮询的方式做第三级负载均衡。
理由:LVS 可处理 100 万左右的量;但不能可丁可卯,再考虑到成本,选择 LVS 做负载均衡。
![](https://static001.geekbang.org/infoq/22/22091c9f1be936858b27ecf081d24648.png)
计算架构之缓存架构设计
多级缓存架构,秒杀活动会高频次浏览秒杀页面,由于页面是固定的静态的,且页面较大(包括 html 页面、图片等资源),使用 APP 缓存+CDN 缓存+WEB 容器缓存。
理由:(1)资源为静态,静态资源较大,页面的并发量很高 QPS=10 万(非功能需求页),单机房的带宽可能不够,需要 APP 缓存+CDN 缓存+WEB 容器缓存将大部分查询请求拦在系统外部;(2)由于浏览商品 QPS=277(非功能需求页)很小,数据库压力不大,考虑成本,不用分布式缓存
![](https://static001.geekbang.org/infoq/3d/3ddc09e54d76fd7ade6b0b1573d3f888.png)
可扩展架构设计
由于已经落地了微服务,选择微服务架构,可通过增加服务器来提升并发处理能力。
![](https://static001.geekbang.org/infoq/ca/cac6c196f24b981104a6d5435e1baf13.png)
存储架构设计
秒杀系统的商品数据、用户数据、订单数据都可以用原业务系统的数据库。
由于秒杀系统的商品只有 2 种,且最多只有 1000 个,所以秒杀系统特有的数据非常少,可直接用原业务系统数据库。
原业务系统用户量 100 万,商品不超过 200 个,所以总体的量都很小,使用 mysql 主备数据库即可。
![](https://static001.geekbang.org/infoq/22/22b7b7782dd2e347aa494af4169deb5c.png)
高可用架构设计
所有模块都是多点部署,节点个数需要根据实测性能估算,负载均衡,数据库使用主备模式,主同步给备,消息队列使用两个结点两个副本。
当前只有单机房,由于要求万无一失,为提升可用性,有条件的话,可以在同城其他机房租机器部署灾备数据库,可作为后续架构演进方案,目前无需部署。
![](https://static001.geekbang.org/infoq/c3/c3125416919b54680f475cd8b8ef4d31.png)
评论