架构实战营 毕业设计项目

1. 业务背景

「业务背景」

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

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

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

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

4. 老板要求万无一失

「技术背景」

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

2. 主要渠道是自有的 App (Android & ios) 和微信小程序

3. 为了促进转化用户到 App，只有下载 App 才能参加秒杀活动。

4. 目前只有单机房

2.业务基本场景

1. 用户需要在 APP 登录/注册

2. 用户可以提前浏览秒杀商品

3. 秒杀开始，用户才能下单

4. 成功下单用户，可以支付或者取消订单

5. 秒杀商品售罄之前，所有用户都可以继续浏览和刷新秒杀商品页面

3.存储架构设计

1. 注册登录

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

1. 热销和秒杀商品库存

只有 200 条左右商品，但秒杀开始时，会有高并发库存查询，redis 单机 TPS 为 5~10 万，所以使用 redis cluster，在必要时可以拓展 redis 的读副本来降低压力。

1. 订单

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

4.计算架构设计

4.1 性能估算

1. 注册登录

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

1. 热销商品

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

1. 秒杀商品

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

1. 支付

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

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

4.2 负载均衡架构设计

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

4.3 缓存架构设计

1. 将商品信息、图片静态化級存至 CDN 之中。

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

3. 使用分布式缓存 Redis Cluster 进行：秒杀限流、热点数据缓存。

5.可扩展架构设计

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

6.高可用架构设计

由于现在只有一个机房，老板又要求万无一失，考虑到现在百万的日活，而且是初创公司，先上同城灾备，后面可以演进到双活