业务背景

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

背景分析

• 创业公司：成本敏感
  

• 目前商场的商品小于 200 个

• 日活 1000 万：注册用户约 1 千万

• 万无一失：每个组件做到高可用部署（成本敏感，目前只有单机房），不做机房多活

• 团队以 Java 为主：继续使用现有 Java 架构

• 已经落地微服务：继续使用微服务基础设施，本次秒杀活动，可单独作为一个微服务

• 促进 App 转化：假设新用户增长了 50%，于是用户总规模达到了 1500 万

• 预估峰值 TPS：假设 1500 万中，有 1 千万在 1 分钟内秒杀，于是秒杀的 TPS 为 1000 万/60 秒=17 万/s
  

关键设计

• 由于秒杀瞬时访问量巨大，需要分层做好泄洪工作

• 由于买单远远大于秒杀货品数量，没有必要也无法做到严格意义上的“先来后到”，可以将秒杀商品进行分片，以达到分散并发压力的效果

• 通过多级缓存实现并发分流的作用，但考虑到控制成本，不引入 CDN

• 由于只有在 APP 才能秒杀，故可以使用 HTTP-DNS 技术

• 采用负载均衡架构
  

存储架构设计

• 关系型数据还是遵照已有架构设计，使用 MySQL

• 使用的主备模式

• 由于没有达到 2000 万级，所以不考虑 MySQL 分库分表

计算架构设计

• 秒杀的后端服务单独作为一个微服务实现

• 一台后端服务承担 1 千 TPS，考虑到 17 万 TPS，需要 170 台服务器--过多

• 在 App 端进行限流，只放 10%的流量到后端

• 部署 20 台后端服务

缓存架构设计

• 采用多级缓存

• APP 要缓存秒杀页面

• Nginx 要缓存页面静态资源

• 后端全局缓存使用现有的 Redis

• Redis 使用 Cluster

• 将 1000 个充电宝和 10 台 Iphone12 分成 5 份，存在 Redis 分片中

负载均衡架构设计

• 使用 HTTP-DNS

• HTTP-DNS 按轮询算法将流量分给后端的 2 台 Nginx

• 不使用 LVS 的原因是，现有架构已经使用了 Nginx

• 2 台 Nginx 能够应付这个量级

可扩展设计

• 计算节点无状态可水平扩展

• 秒杀业务为独立的微服务，可扩展

高可用设计

• Nginx 采用虚拟 IP 和 keep-alived 实现高可用

• 计算节点有 20 个，无状态，支持高可用

• Redis Cluster 支持高可用

• MySQL 主备