写点什么

架构实战营 毕业设计

用户头像
Dylan
关注
发布于: 2 小时前

【业务背景】

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

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

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

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

4.老板要求万无一失。

【技术背景】

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

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

3.目前只有单机房。

【毕设要求】

1.设计完整的架构,例如存储、负载均衡、缓存、高可用、可扩展等;

2.大约 10 页以内的 PPT,每页 PPT 说明一项设计,包括架构设计和设计理由,无需详细解释备选方案。

【提示】

1.分析考虑要全面,但并不意味着架构设计要面面俱到,如果分析后认为某些设计点可以不做,就在作业最后统一说明原因即可;

2.如果没有思路,请对照模块 9 的 IM 案例;

3.如果有的信息觉得不够全或者不够细,可以做出一定的假设,但不能天马行空,需要对照已有的业务背景和技术背景进行合理推断。


设计电商秒杀系统

一、 分析

1.     核心业务场景:下载 APP;注册登录;秒杀;支付。

2.     秒杀商品数量不多,秒杀活动的瞬间流量很高,需要用缓存和消息队列,降低后端压力。

3.     日活用户 100 万,在秒杀活动期间,至少会有 3~5 倍的用户参与,架构设计至少参照百万级别架构设计。

4.     老板要求万无一失,要考虑高可用,目前只有一个机房,所以需要申请云资源。

5.     团队已经落地微服务,而秒杀活动的流量很高,所以在原有的 spring Cloud 基础上,单独开一些服务,专门做秒杀。

6.     创业型公司,技术人员不会太多,作为业务重点的秒杀活动,可用根据需求找 12 个人做后端,android 3 人,ios 3 人,微信小程序 3 人。


二、 业务流图

用户的主要业务流程包括,下载 APP,然后注册/登录;打开首页,查看推荐商品和秒杀商品;抢购商品,抢购时支付前先查询库存,支付后库存自动减 1;最后系统记录用户的购物信息。



三、 计算架构设计

1.   注册登录

TPS: 日活用户 100 万人,假定活动当天新增 10 倍用户,一共 1000 万用户,80%登录注册发生在 5 小时内,则 TPS=1000 万*0.8/5/3600=450

2.   热销商品

QPS: 10 大类,每类 20 个商品,一共 200 个商品。当天一共 5 倍的人查看,每人查看 3 次,每次查看 5 个商品,且 80%的请求发生在 5 小时内,则 QPS=500 万*3*5*0.8/5/3600=340

3.   秒杀商品

QPS:1000 个充电宝,10 个 iphone,假定当天 5 倍人参与,共 500 万,每个商品每人点击请求 3 次,秒杀请求发生在 1 分钟内。则 TPS=500 万*2*3/60=50 万

4.   支付

TPS: 热销商品:点击抢购后,进入支付界面,支付前查询商品剩余数量是否大于 1,支付后商品数量减 1,TPS 为 340。

TPS: 秒杀商品:和上面逻辑一致,TPS 为 50 万。

 

四、 存储架构设计

1.     注册登录

假定有 5 倍的用户进行登录注册,存储的用户注册和登录信息 500 万

2.     热销和秒杀商品库存

只有 200 条左右商品,但秒杀开始时,会有高并发库存查询,redis 单机 TPS 为 5~10 万,所以使用 redis cluster。

3.     订单

预计登录用户有 50%的购买转化率,每人平均购买 2 件商品。则订单存储量为 500 万*0.5*2=500 万



五、负载均衡设计

采用多级负载均衡,作为初创公司,F5 价格过高,为满足峰值数百万的请求,LVS 已足够满足需求,使用多个 LVS 作为一级负载均衡。


六、缓存设计

1. App 缓存+web 容器缓存+分布式缓存

2. 使用 APP 缓存和 WEB 缓存将大量静态页面保存起来,秒杀时静态页面从 APP 或 Web 获取,减轻后端压力。

3. 秒杀开始后,为支持大量库存查询请求,使用 redis 保存库存,分布式缓存使用 redis,为应对大流量,redis 采用 redis cluster 方式部署。



七、高可用设计

为确保在秒杀开启后,大流量冲击下万无一失,确保高可用,自建同城双中心成本比较高,异地多活更不能考虑了,对创业公司来说金钱成本和时间成本都比较高,最好购买一定的异地云服务,将数据同步到云中,发生本地宕机情况下,自动切换到云端。同时将请求放入消息队列,以应对高频请求,降低服务端压力。



八、可扩展设计

百万级别的业务,公司可以抽出 20 个左右开展这次秒杀业务,后端 12 个人,根据三个火枪手原则,开 4 个微服务,以后有新的业务可用直接水平扩展。

 


九、总结

秒杀业务因为高流量高并发,对架构设计要求较高,本文采用了缓存和消息队列来应对。初创公司为降低开发成本,同时不影响原来的业务,在原来微服务架构基础上,直接开 4 个新的服务,完成秒杀业务。本文采用多级负载均衡架构应对高峰值场景,采用云端备份服务方式保证高可用。

 

发布于: 2 小时前阅读数: 3
用户头像

Dylan

关注

还未添加个人签名 2018.11.22 加入

还未添加个人简介

评论

发布
暂无评论
架构实战营 毕业设计