模块九（电商秒杀系统）

业务背景

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

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

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

• 老板要求万无一失

技术背景

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

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

• 目前只有单机房

性能分析

• 正常日活是100万，秒杀时假设人数是平时的2到3倍，那么架构设计需按百万级别来设计，预计参与的人用户数为300万

• 用户需要提前登录，假设全在秒杀前30分钟内登录，则QPS=300万/180=1666/s

• 秒杀开始，假设秒杀请求在30秒内完成，平均每个用户点击请求5下，则TPS=300万*5/30=50万/s

存储架构设计

数据分析：

• 库存数据，频繁读写，对应秒杀场景，单库无法支撑写请求时，可通过库存拆分的方式分担写压力

• 商品信息相对固定，读多写少，可以用读写分离，提升性能

• 订单及支付数据，因为秒杀的商品数较少，并不会增加订单数量，所以并不要特别考虑

• 商品信息、订单、支付账单，可先采用 MySQL 主从架构

• 商品详情页动静资源分离，静态资源通过引入 CDN 存储进行加速

• 用户信息、库存信息缓存到 Redis, redis 单机 TPS 为 5~10 万， 而在秒杀时有高并发的写，TPS为50万/s，采用多机的 Cluster 架构

计算架构设计

负载均衡设计

缓存设计

• 采用app缓存+web容器缓存+分布式缓存三级缓存

• APP 端缓存+web容器缓存，可缓存绝大部分静态资源，减少后端压力

• 分布式缓存，缓存库存，用户，商品信息

高可用设计

• APP接入端限流：通过答题器降低接入请求，防止用户高频请求

• 网关入口限流：业务规则过滤，检查库存

• 秒杀任务排队：采用漏桶限流，将最后的合法秒杀请求放到限流桶队列，队列满则丢弃

可扩展架构设计（微服务拆分）