架构实战营 毕业设计
【毕设背景和要求】
【业务背景】
你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：
1. 你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类；
2. 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone 12 作为秒杀商品；
3. 正常的日活大约 100 万用户；
4. 老板要求万无一失。
【技术背景】
技术团队以 Java 为主，已经落地了微服务架构；
主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；
目前只有单机房。
【毕设要求】
设计完整的架构，例如存储、负载均衡、缓存、高可用、可扩展等；
大约 10 页以内的 PPT，每页 PPT 说明一项设计，包括架构设计和设计理由，无需详细解释备选方案。
毕业设计：设计电商秒杀系统
一、分析
秒杀活动的瞬间流量很高，需要用缓存和消息队列，降低后端压力。
日活用户 100 万，在秒杀活动期间，至少会有 3~5 倍的用户参与，架构设计至少参照百万级别架构设计。
老板要求万无一失，要考虑高可用，目前只有一个机房，所以需要申请云资源。
团队已经落地微服务，而秒杀活动的流量很高，所以在原有的 spring Cloud 基础上，单独开一些服务，专门做秒杀。
创业型公司，技术人员不会太多，作为业务重点的秒杀活动，可用根据需求找 12 个人做后端，andorid3 个，ios3 个。
二、业务流图
用户的主要业务流程包括，下载 APP，然后注册/登录；打开首页，查看推荐商品和秒杀商品；抢购商品，抢购时支付前先查询库存，支付后库存自动减 1；最后系统记录用户的购物信息。
三、计算架构设计
注册登录
TPS: 日活用户 100 万人，假定活动当天新增 10 倍用户，一共 1000 万用户，80%登录注册发生在 5 小时内，则 TPS=1000 万*0.8/5/3600=450
热销商品
QPS:10 大类，每类 20 个商品，一共 200 个商品。当天一共 5 倍的人查看，每人查看 3 次，每次查看 5 个商品，且 80%的请求发生在 5 小时内，则 QPS=500 万*3*5*0.8/5/3600=340
秒杀商品
QPS：1000 个充电宝，10 个 iphone，假定当天 5 倍人参与，共 500 万，每个商品每人点击请求 3 次，秒杀请求发生在 1 分钟内。则 TPS=500 万*2*3/60=50 万
支付
TPS 热销商品：点击抢购后，进入支付界面，支付前查询商品剩余数量是否大于 1，支付后商品数量减 1，TPS 为 340。
TPS 秒杀商品：和上面逻辑一致，TPS 为 50 万。
四、存储架构设计
注册登录
假定有 5 倍的用户进行登录注册，存储的用户注册和登录信息 500 万
热销和秒杀商品库存
只有 200 条左右商品，但秒杀开始时，会有高并发库存查询，redis 单机 TPS 为 5~10 万，所以使用 redis cluster。
订单
预计登录用户有 50%的购买转化率，每人平均购买 2 件商品。则订单存储量为 500 万*0.5*2=500 万
五、负载均衡设计
初创公司，F5 价格过高，为满足峰值数百万的请求，使用多个 LVS 作为一级负载均衡。
六、缓存设计
App 缓存+web 容器缓存+分布式缓存
使用 APP 缓存和 WEB 缓存将大量静态页面保存起来，秒杀时静态页面从 APP 或 Web 获取，减轻后端压力。
秒杀开始后，为支持大量库存查询请求，使用 redis 保存库存，分布式缓存使用 redis，为应对大流量，redis 采用 redis cluster 方式部署。
七、高可用设计
为确保在秒杀开启后，大流量冲击下万无一失，确保高可用，除了自建机房，需要购买一定的异地云服务，将数据同步到云中，发生本地宕机情况下，自动切换到云端。同时将请求放入消息队列，以应对高频请求，降低服务端压力。
八、可扩展设计
百万级别的业务，公司可以抽出 20 个左右开展这次秒杀业务，后端 12 个人，根据三个火枪手原则，开 4 个微服务，以后有新的业务可用直接水平扩展。
九、小结
秒杀业务因为高流量高并发，对架构设计要求较高，本文采用了缓存和消息队列来应对。初创公司为降低开发成本，同时不影响原来的业务，在原来微服务架构基础上，直接开 4 个新的服务，完成秒杀业务。本文采用多级负载均衡架构应对高峰值场景，采用云端备份服务方式保证高可用。最后感谢华仔和极客时间组织的这个训练营，预祝越来越好！！
还未添加个人签名 2020.08.13 加入
还未添加个人简介
评论