背景和要求

【业务背景】

你作为一个电商创业公司的架构师，负责设计 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 说明一项设计，包括架构设计和设计理由，无需详细解释备选方案。

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

一、总体业务架构分析

1.     因为目前公司商城的日活是 100 万，假设每日有约 50%的用户会浏览商城，则商城的总注册用户可能达到了 200 万的规模。考虑到秒杀活动的市场推广活动，秒杀活动期间短期内可能还会增加数十万(估算一周的 618 大促活动期间会新增 30-60 万)的新用户。总用户规模是两三百万级别，需要考虑百万级别的架构设计。

2.     秒杀活动的瞬间流量很高，假设前 10 秒内有 50%用户参与秒杀活动；TPS 大概是 300 万*50%/10=15 万/s,需要充分利用多级缓存和 Redis 集群，将大部分的秒杀并发请求拦截在 App 端和小程序以及分布式缓存，降低对后端数据库服务器的压力。

3.     老板要求万无一失，要考虑高可用，所以需要单独部署秒杀业务。又考虑作为创业公司，只有一个机房，不可能建设一个新机房。所以考虑在机房内单独部署秒杀业务，同时通过购买短期的云服务来做多活。

4.  团队已经落地微服务，可以在原有的 Spring Cloud 基础上，共用注册，登录和认证等服务；

5.     创业型公司技术人员不会太多，作为业务重点的秒杀活动，可安排 9-12 个人做后端；Andorid 2-3 个人，IOS 2-3 个人，测试 3 人，运维两人；

二、存储架构设计

存储性能估算

1.下载 APP

由于 App 有几百万的下载量，且下载用户分散在全国各地。

2.注册

 要保存 200 万用户注册信息；

3.登录

百万日活用户，每天登录数据是每天 100 万条；618 期间可能是每天 200 万条；

4.秒杀

秒杀商品只有 1010 个，数量很少。但秒杀对库存访问的并发量很大，假设前 10 秒内有 50%用户参与秒杀活动；查询库存的 TPS 大概是 300 万*50%/10=15 万/s。秒杀订单数是 1010 个。

5.订单

预计登录用户有 50%的参与秒杀，秒杀订单数 1010；

预计登录用户有 10%会购买商品，每人平均购买 2 件商品。则订单存储量

为 300 万*0.1*2=60 万;

存储架构设计：

1.下载 App

a.App 在各大应用市场上架，包括苹果 store 和安卓应用商店；

b.通过自有渠道平台下载（如官网、H5 等），可以在阿里云 OSS 存储安装包，通过 CDN 技术来支持。

2.用户注册和登录，秒杀商品和库存

MySQL 一主一备，同步用户数据+秒杀结果

（300 万注册信息，每日 150 万登录信息，1010 个秒杀订单，60 万商品订单）

Redis Cluster，存储秒杀商品的库存；

三、计算架构设计

计算性能估算

1.下载 APP  

因为主要通过应用市场或 CDN 支持，不涉及性能估算；

2.注册

假设每日新增用户 30 万人，假设是 6 小时内注册的，QPS=300000/6/3600 = 13/s ,可忽略

3.登录

在秒杀开始前 1 个小时内，用户可能会大量登录，按日活用户 2 倍估算，登录的 TPS 均值为：200 万/3600=550

3.     普通商品浏览

假设 10%的用户，每人浏览 10 个页面，每个页面 5 个接口请求；

QPS=300 万*0.1*10*5/4/3600=1040

4.秒杀

秒杀时，在开始的 10 秒内，50%用户参与秒杀活动；

TPS 大概是 300 万*50%/10=15 万/s

计算架构设计

1. App 下载通过应用市场和通过 CDN 技术来支持；

2.由于注册、登录、TPS 比较低，可复用之前商城的注册和登录服务，不再设计。

3.普通商品浏览 QPS=1040,采用 4-5 台业务服务器可以支持；

4.秒杀

由于秒杀的 TPS 已达到 15 万，设计如下方案

客户端削峰 - 请求秒杀时，App 在用户点击秒杀后，秒杀页的按钮暂时变灰，显示排队等待中请稍后；多余的重复的秒杀请求不会发送到服务端，预计削减 90%的请求量；

WEB 缓存削峰 - 应用内使用 Spring Cloud 组件的限流算法，削减请求，整个秒杀业务，每秒放行 500 个请求，多余的请求返回秒杀商品已售罄。

削减后的 TPS 已在可承受范围内；

四、计算架构之负载均衡设计

一级：通过 DNS 做自建机房和阿里云秒杀服务之间的一级负载均衡；确保秒杀服务被分配到两个服务集群进行处理；当秒杀活动中某个集群故障时，能通过配置，将流量导入另一个集群，并通过对服务配置限流的措施，提供降级的服务；

二级：因为是初创公司，从经济角度不适合使用 F5 做负载均衡，为满足秒杀业务峰值十万到几十万的并发请求，使用两个 LVS 作为二级负载均衡。

三级：后续通过 4 台 Nginx 做三级负载均衡，基本保证每台 Nginx 秒杀活动时的最高负载在 3 万/s-5 万/s 左右；

四级：每个 Nginx 下面对接多个网关微服务，作为四级负载均衡；

六、计算架构之缓存设计

1.  App/小程序缓存+DNS+Web 容器缓存+分布式缓存

2.  使用 APP/小程序缓存和 DNS 将秒杀活动的静态页面保存起来，秒杀时静态页面从 APP/小程序或 DNS 获取，减轻后端 Web 服务器的压力。

3.  秒杀开始后，为支持大量库存查询请求，使用 redis 保存库存，分布式缓存使用 redis，为应对高并发，Redis 采用 redis cluster 方式部署。  当然，还可以通过使用服务限流或消息队列的方式，每秒只放行 500 个请求或读取 500 个消息，对它们处理查库存和下单；然后再取下一批 500 个请求处理，直到库存为 0；这样对 Redis 访问的压力会大大降低，采用 Redis Sentinel 模式基本就可以了。

七、高可用设计

  为确保在秒杀开启后，大流量冲击下万无一失，确保高可用，除了自建机房，需要购买一定的异地云服务。在发生本地机房秒杀业务服务器出现宕机情况下，自动切换到云服务，并通过限流实现降级的服务。此外，还可以考虑将秒杀请求先放入消息队列，以应对高并发请求，降低服务端压力。

八、可扩展设计

  百万级别用户的秒杀业务，公司可以抽出 20 个左右的同学来支撑这次秒杀业务。大概是后端开发 12 个人，根据三个火枪手原则，拆分 4-5 个微服务，以后有新的业务可用直接水平扩展。微服务可扩展架构设计如下：

九、小结

秒杀业务因为高流量高并发，对架构设计要求较高，本方案采用了多级缓存和限流的机制来应对。初创公司为降低开发成本，同时不影响原来的业务，在原来微服务架构基础上，新增独立部署的秒杀服务。此外，还设计了独立部署在阿里云的云服务，通过异地多活设计，确保秒杀业务满足万无一失的要求。

谢谢！