一、背景

技术

• 技术团队 Java 技术为主

• 已落地微服务

• 目前单机房

• 有 APP 跟微信小程序，要求仅 APP 用户才能参与秒杀

业务

• 在销售商品 <=10 个品类 *20 个商品

• 本次秒杀 2 个商品（1000 个充电宝、10 台 iphone12）

• 正常日活大约 100w 用户

• 目前只有单机房

• 老板需要万无一失

二、业务分析

本次秒杀 2 个商品（1000 个充电宝、10 台 iphone12）, 产生的秒杀订单 1000+10 = 1010 个。

日活百万，估计参与秒杀可能是平时流量的 1.5~2 倍。

老板需要万无一失，需要做好核心流程的梳理，保证核心流程的可用性。

三、设计的思路

• 做好隔离：包括秒杀服务的隔离、中间件的隔离。单独部署服务集群，防止拖垮其他服务。

• 多层限流：保证到达 DB 层能在可控的流量。

• 尽量缓存：把商品提前预热到缓存，包括库存的数据。

• 高可用设计：包括限流、排队、降级、熔断。

存储架构设计

数据量不大，因为才秒杀 2 个商品（1000 个充电宝、10 台 iphone12），产生的秒杀数据才一千多条。

Mysql 做个主备即可。

Redis 主要做缓存，查询秒杀的商品信息

六、计算架构设计

6.1、负载均衡设计

因为系统日活有 100w，秒杀时候假设是平时的 1.5 倍~2 倍。LVS 可以抗住几十 w 的并发，通过前端加合法性验证（比如验证码，防机器人），到达 LVS 可以抵挡全部合法流量。

6.2、缓存设计

七、高可用设计

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

7.1、限流设计

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

• 1、请求端的限流：发起请求的时候限流，被限流的请求实际上没有到后端服务器

• 2、接入端的限流：接到业务请求的时候进行限流，避免请求进到实际的业务处理流程

• 3、单个服务自我保护，如果请求太多，可以舍弃新的请求

7.2、排队设计

各个角色说明：

• 1、排队模块。使用 Kafka 消息队列，将请求以先进先出的方式保存下来，队列大小可以比秒杀商品多一些。

• 2、调度模块。根据秒杀服务处理能力检测，有能力处理，将队列的消息下方到秒杀服务中去。

• 3、其他服务。真正的业务处理模块，如下单、完成交易。

7.3、降级设计

降级服务主要为了优先保证核心业务正常，比如这边保证秒杀的下单交易服务正常。其他服务视情况降级。

7.4、熔断设计

为了防止故障链式西效应，起到服务的自我保护