【业务背景】

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

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

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

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

老板要求万无一失。

【技术背景】

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

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

目前只有单机房。

一、复杂度分析

a) 业务复杂度:秒杀系统自身的业务复杂度并不高

b)性能复杂度：假设全部的日活用户都来参与秒杀活动，并且访问集中在秒杀前后 1 分钟内，每人刷新了 5 次页面，商品的查询 QPS=1000000*5/60=8 万；秒杀操作假设集中在活动开始后的 10S 内， TPS 可以认为是 1000000/10 = 10 万。

二、存储架构设计

考虑之前分析的复杂度，tps 在 10 万左右。

缓存集群 redis 做为商品信息、用户信息缓存，以及商品库存的记录。

MySQL 采用主备架构

三、计算架构设计

3.1、负载均衡设计

LVS 可以抗住几十 w 的并发，通过前端验证（比如验证码，防机器人），到达 LVS 可以抗住全部合法流量。

3.2、缓存设计

秒杀系统对商品访问的 QPS 较高，可以建立 4 级缓存，去优化商品详情的访问性能

四、高可用设计

为了保证接口的高可用，大致思路分：1、限流 2、熔断与降级

4.1、限流设计

用户请求的各个环节都可以限流：

• 1、请求端的限流：发起请求的时候限流，被限流的请求实际上没有到后端服务器,避免重复提交

• 2、网关层的限流：接到业务请求的时候进行限流，避免过大流量冲垮业务服务器

• 3、单个服务自我保护，比如秒杀库存服务，是一个热点，可以重点限流。

4.2、熔断与降级设计

对于出现抖动不稳定的上游服务可以使用 sentinel 进行自动降级熔断，防止上游的抖动波及到下游的秒杀服务。另外，不是强依赖的服务，都可以加降级开关，必要时进行降级处理。