【背景】

【业务背景】

负责设计 6.18 大促秒杀系统的设计，业务模式如下：

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

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

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

4. 老板要求万无一失。

【技术背景】

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

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

3. 目前只有单机房。

【性能评估】

【业务量】

• 秒杀用户数：日活 20%的用户参与秒杀 20w

• 秒杀时间到，20w 用户同时点击秒杀按钮

• 详情页-库存查询每秒一次

【秒杀页】

• 商品详情：QPS 约 3500（20w/(1min*60)）

• 库存信息：QPS 20w

• 秒杀：TPS 20w

【订单】

• 提交订单：TPS 1010

【支付】

• 支付：TPS 1010

【业务分析】

秒杀活动在较短时间内会比平时产生大数十倍、上百倍的页面访问流量和下单请求流量。

【秒杀活动】

秒杀活动可以分为 3 个阶段：

• 秒杀前：用户不断刷新商品详情页，页面请求达到瞬时峰值。

• 秒杀开始：用户点击秒杀按钮，下单请求达到瞬时峰值。

• 秒杀后：一部分成功下单的用户不断刷新订单或者产生退单操作，大部分用户继续刷新商品详情页等待退单机会。

【秒杀页面】

秒杀系统的流量虽然很高，但是实际有效流量是十分有限的。利用分层架构设计，在每个阶段提前校验，拦截无效流量，可以减少大量无效的流量涌入后端及数据库中。

• 利用 APP 缓存和 CDN 抗压静态页面流量

秒杀前，用户不断刷新商品详情页，造成大量的页面请求。所以，把秒杀商品详情页与普通的商品详情页分开。对于秒杀商品详情页做静态化处理，除了秒杀按钮需要服务端进行动态判断，其他的静态数据缓存在 APP 和 CDN 上。秒杀前刷新页面导致的流量进入服务端的流量只有很小的一部分。

• 利用读写分离 Redis 缓存拦截流量

CDN 是第一级流量拦截，第二级流量拦截使用支持读写分离的 Redis。在第二级主要读取数据，读写分离 Redis 能支持高达 60 万以上 qps，完全可以支持需求。

【秒杀实现】

首先通过运营平台，提前将秒杀商品缓存到读写分离 Redis，将每个秒杀商品在 Redis 中用一个 hash 结构表示，并设置秒杀开始标记。

秒杀开始前，从 Reidis 读取秒杀数据，检查秒杀是否开始

运营平台将秒杀标志打开，表示秒杀开始

当接受下单数超库存时，拦截所有请求，商品剩余数量为 0。

【架构设计】

【计算架构设计】

【缓存架构】

• APP 缓存：缓存详情页-静态数据，秒杀结果

• 分布式缓存：详情页（静态数据、动态数据）、剩余库存

【其他架构】

其他系统可以复用

【存储架构设计】

秒杀数据使用 Redis sentinel 集群

订单数据，复用平台的

【可扩展架构设计】

秒杀服务独立部署

使用独立域名

【高可用架构设计】

就一个机房，暂时先不做灾备处理

【总体架构】

【毕业总结】

通过几个月的学习，对架构已经从门外汉到达了解的程度；通过架构实战营的学习对架构有个全新的定义、整体的思维，更明白架构师是需要持续不断地进行学习、提升，同时也明白作为一个合格的架构师需要具备有深厚的理论基础、技术的深度/宽度/广度、洞悉业务的能力、系统的学习方法等。

学习时间虽短，但已经给自己打开一片全新的天地...