架构实战营 - 模块 9- 作业

设计电商秒杀系统

【业务背景】

你作为一个电商创业公司的架构师，负责设计 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. 如果有的信息觉得不够全或者不够细，可以做出一定的假设，但不能天马行空，需要对照已有的业务背景和技术背景进行合理推断

分析：

1，日活用户大约 100W，可以推断用户量为千万级别。

2，老板要求万无一失，代表系统需要高可用。

3，秒杀系统可以使用 redis+lua 作为存储用来扣减库存。

4，存储方面采用 mysql，缓存采用 redis。

5，10 个品类不超过 20 个商品，也就是 200 个商品。

业务分析：

1，秒杀商品只有 1000 个充电宝，10 台 iPhone 12

秒杀方案说明：

1，活动当天，把需要秒杀的商品库存数量从 mysql 同步到指定的 redis。

2，使用 redis 作为存储，进行秒杀系统的存储设计。

3，redis 库存全部扣减完成，代表秒杀商品全部售罄，秒杀活动结束；如果 redis 库存没有全部扣减完成，还有剩余，等待秒杀活动结束以后，盘点库存的时候，再由 redis 同步回 mysql。

4，秒杀系统需要做到限流，比如由 APP 过来的流量，进入 F5，nginx，应用的时候，层层限流，最后再使用 redis 进行库存扣减。

618 活动方案说明：

1，按照正常的电商系统设计，无特殊方案，仅保证系统可高用。

总结：电商系统+秒杀方案

存储架构分析：

1，日活用户 100W，假设每个用户每天晚上 8 点-12 点之间下单一次，那么每天就有 100W 数据，从数据量上来看，存储需要分库分表，读写分离。

TPS:100W/4/3600=69.4。

2，活动当天，推断用户数量增加，那么假设为平日的 3 倍，那么就有 300W 用户参与当天的 618 活动。

TPS:100W/4/3600*3=208.33。

3，秒杀商品只有 1000 个充电宝，10 台 iPhone 12，由于只有 APP 用户才能参与秒杀，所以并不是人人都会参与秒杀，故假定参与秒杀的人数为 1/3，那么就有 100W 人参与秒杀。

4，另外由于是电商系统，有许多的商品图片等，可以采用图片服务器来单独存放商品图片。

5，秒杀系统部分使用 redis+lua 作为库存部分。

计算架构分析：

1，日活用户 100W，活动当天，推断用户数量增加，那么假设为平日的 3 倍，那么就有 300W 用户参与当天的 618 活动。

2，单机房，那么使用 F5+nginx。

3，做到万无一失，那么做负载均衡与高可用设计

单机房负载均衡架构：

说明：

1，单机房负载均衡。

2，因为 100W 日活，活动当天假定 300W 日活，那么上 F5，高可用，那么 2 台。

3，因为做了微服务落地，那么每个业务域都可以使用 nginx 网关集群进行路由。

缓存架构：

说明：

1，电商系统，会有很多商品的图片等，需要使用单独的服务器进行缓存。

2，用户量太大，需要进行多级缓存。

存储架构：

说明：

1，日活用户大约 100W，可以推断用户量为千万级别。

2，日活 100W，可知每日数据为 100W，需要做分库分表，读写分离。

3，秒杀系统的部分，可以按照前面业务分析部分，单独使用某一台 redis 进行存储，redis 使用 sentinel 做到高可用。

4，秒杀部分需要做到限流。比如由 APP 过来的流量，进入 F5，nginx，应用的时候，层层限流，最后再使用 redis 进行库存扣减。

整体架构：