一、业务背景

你作为一个电商创业公司的架构师，负责设计 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、热点数据问题

大家抢购的都是同一个商品，所以这个商品直接就被推到了热点的位置，不管你是用的数据库，还是分布式缓存，都无法支持几十万、上百万对同一个 key 的读写，以 Redis 的写为例，最高仅可支持几万的 TPS。

3、刷子流量

高频次的请求，会挤占正常用户的抢购通道，同时，刷子也获得了更高的秒杀成功率。这不仅破坏了公平的抢购环境，也给系统服务带来了巨大的额外负担。

五、存储架构设计

秒杀系统只需要存储参加秒杀的商品数据、订单数据等信息，数据量较小，因此使用 Mysql 存储即可，为了保证存储可靠性，使用主从同步的方式进行存储。

六、负载均衡设计

使用 DNS 做域名解析，使用 F5/LVS 做整个机房内所有业务的负载均衡，同时搭建秒杀系统的 Nginx 集群、网关和秒杀服务。

七、缓存设计

由于瞬时高并发和热点数据的存在，因此将缓存分散，同时由于大量数据访问导致网络带宽不足的情况，需要将缓存放的离用户越近越好，因此就需要五级缓存，每一级都尽量将用户的请求拦截。

由于秒杀商品是确定的，因此可以增加活动报备及审批系统，审批后，提前预热缓存。

对于分布式缓存，由于存在热点数据，因此需要主从集群，同时为了保证高可用，则可以选择 Sentinel 集群部署即可

八、可扩展

将秒杀系统单独拆分出来即可，由于秒杀系统整体逻辑比较简单，因此拆出来后不需要再对服务进行拆分。

九、高可用

由于只存在一个机房，因此无法做机房级别的高可用。

在同一个机房内，使用 keepalived 保证 F5/LVS 的高可用和 Nginx 的高可用，同时对于网关和秒杀服务做集群化部署，通过注册中心做服务注册与发现，同时注册中心也使用集群部署保证高可用。