架构实战营 模块九 (毕业设计) 作业

毕业设计：设计电商秒杀系统

1. 业务背景

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

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

4. 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone12 作为秒杀商品；

5. 正常的日活大约 100 万用户；

6. 老板要求万无一失。

7. 技术背景

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

9. 主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；

10. 目前只有单机房。

11. 业务基本场景

12. 登陆

13. 浏览秒杀商品

14. 下单

15. 总体架构思路

16. 正常日活用户 100 万用户，大概有 60%~120%的用户会参与秒杀活动，所以架构按照百万用户级别参与秒杀设计，适应最大业务需求。

17. 客户端只有下载 App 才能参加秒杀活动，所以架构设计只考虑 App 的情况。

18. 秒杀活动不经常有，保持单机房不变。

19. 存储架构

20. 估算

21. 登录正常日活用户 100 万，登录数据是每天 100 万

22. 浏览秒杀商品 100 万用户同时浏览两种商品，1000 个充电宝和 10 台 iPhone12。

23. 下单 1000 个充电宝和 10 台 iPhone12，订单数量 1

24. 设计

25. MySQL，采用主备模式，数据复制。因为需要存储的信息，只有 100w 用户数据，100w 登录信息，1010 条订单数据（1000 个充电宝和 10 台 iphone12）。

26. Redis，采用 Cluster 模式，4 个切片组(主备模式，每个切片分 1/4 的商品，包含 250 个充电宝，和 2-3 台 iphone)。用户根据时间随机分配到不同分片。因为有 100w 并发秒杀读请求。

27. 计算架构

28. 估算

29. 登录估计有 60~120 万用户登录，考虑到 50%用户可能会集中在秒杀时间前 1 个小时登录，登录的 TPS 值：50 万/3600 ≈ 140 

30. 秒杀估计有 60~120 万用户会在前 2 秒内参与秒杀，绝大部分是读请求。秒杀的 QPS 值：30 万~60 万

31. 负载均衡设计

32. App->IDC(LVS 集群+业务服务器集群)

33. 考虑到 QPS 在 30 万~60 万，采用 LVS 作负载均衡设计

34. 缓存架构设计

35. 尽量把商品详情页的页面元素静态化，然后使用 CDN 或 App 把这些静态化的元素缓存起来。秒杀前大量请求可以直接由 CDN 或 App 缓存服务，不会到达服务器端，减轻服务器端压力。

36. 秒杀活动开始，为了支撑大量高并发的库存查验请求，由 Redis 保存库存，扣减库存。因此，分布式缓存也选用 Redis。

37. 高可用架构设计

38. 秒杀系统在大流量的冲击下，容易出现意外情况，为了保证系统的高可用，要有相应的保护措施。

39. 高可用-排队收到秒杀请求后并不是立即处理，而是放到消息队列，系统根据能力进行异步处理。队列的大小根据秒杀商品数量或多一些定义。相比较限流来说，排队的客户端体验要更好一些。

上图为缓存架构设计图。