业务场景

一、秒杀业务

1、每个用户需先登录

2、用户导航到秒杀商品页面

3、秒杀时间到进行抢购

4、抢购成功进行支付

二、正常业务

1、由于6.18秒杀活动，正常业务流量会增加，热门商品和其他商品会随之增加购买流量，按平时的5倍进行系统评估和扩容机制来支撑，假设正常业务足以支撑5倍流量。 —— 不做分析

用户量估算

业务背景日活100万

1、登录：秒杀活动开始前，用户已经提前登录——不考虑

2、秒杀商品页：用户一般都会频繁刷新页面，等待秒杀时间到——CDN/Nginx 缓存商品静态页面

3、抢购：用户一般会在抢购失败后，继续点击抢购——前端限制请求

4、支付：由于秒杀商品数量1000个充电宝 + 10个IPhone，支付请求量低——不考虑

5、发货：秒杀业务由于商品增加少，不影响发货——不考虑

存储性能估算

抢购记录存储：假设没条记录64字节，则需要 640M（1千万 * 64 / 1000 / 1000）

计算性能估算

TPS：由于秒杀基本就集中在前1秒时间内，假设10%的人参与抢购， 所以TPS = 10万

QPS：10万

指标汇总

高性能——需要，TPS 10万，QPS 10万

高可用——需要，秒杀期间系统不能出问题，保证商品不超卖，不少卖

扩展性——不需要，秒杀系统业务单一，使用后就短时内不会再用

安全 ——需要，防止褥羊毛

成本 ——不考虑，满足指标前提下以节约成本为目标。

存储容量——不考虑，容量规划 1G 就够了

存储写性能——需要，TPS 10万

存储读性能——需要，TPS 10万

设计关键点

1、前端限制抢购只能一次请求，请求接入层限流

2、秒杀商品页静态资源缓存

3、多级负载均衡，要支持10万请求

4、异步支付

5、数据强一致性

存储架构设计

说明：秒杀系统存储容量小，一台Mysql可以支撑，秒杀抢购记录写入TPS 10万，可通过异步后台慢慢写入；Redis存储秒杀商品数量，开启每次请求都刷盘机制，保证数量正确性；秒杀结果后把Redis的商品数量同步与Mysql；

缓存架构设计

说明：Web容器选择Nginx，可缓存商品页静态资源；另APP终端可缓存静态资源；分布式缓存选择Redis，可缓存秒杀商品梳理。

负载均衡架构设计

高可用存储架构设计

秒杀总体架构

说明：

1、秒杀单独独立成微服务

2、Redis提前预缓存秒杀商品数量

3、商品页静态资源提前组装缓存至Nginx

4、前端现在抢购按钮在30秒内只能点击一次

5、Nginx抢购流量随机负载排队服务

6、排队服务接收请求后发送MQ消息，发送消息后直接返回，提示客户端等待几秒后查询结果

7、业务服务消费MQ消息进行处理，检查Redis集群一中商品数量判断是否抢购成功

8、业务服务将抢购记录保存至Redis集群二中

8、客户端查询抢购查询结果，成功则跳转支付页面，开启支付流程

9、秒杀结束后将Redis集群的数据同步至Mysql 数据库