设计电商秒杀系统

1、背景

技术

1.技术团队以 Java 为主

2.已经落地了微服务架构；

3.主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序

4.只有下载 App 才能参加秒杀活动；

5.目前只有单机房。

业务

1.在售商品数量 <= 10 个品类 * 20 个商品

2.秒杀 2 个商品，数量 = 1000 个充电宝 + 10 台 iPhone12

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

4.老板要求万无一失

2、业务分析

1.秒杀 2 个商品，数量 = 1000 个充电宝 + 10 台 iPhone12：产生订单数：1010 个

2.日活用户 100 万：秒杀流量为正常流量的 1.5-2 倍

3.老板要求万无一失：需要做好核心流程的梳理，确保核心流程的可用性

3、设计思路

1.做好隔离：包括秒杀服务的隔离、中间件的隔离。单独部署服务集群，防止某一服务宕机时拖垮其他服务。

2.多层限流：保证到达 DB 层的是可控的流量。

3.尽量使用缓存：商品提前预热到缓存中，包括库存的数据。

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

4、存储架构设计

秒杀商品数量 1010 个，数量不大，数据库和 Redis 缓存使用主备复制即可

5、计算架构设计

5.1  负载均衡设计

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

5.2  缓存设计

6、高可用架构设计

6.1  限流设计

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

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

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

4.  单个服务自我保护，如果请求太多，可以舍弃新的请求。

6.2  排队设计

各个角色说明：

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

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

3.   业务服务。处理模块，如下单、完成交易。

6.3  降级设计

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

6.4  熔断设计

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