业务背景

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

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

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

• 要求：老板要求万无一失。

技术背景

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

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

• 机房：目前只有单机房。

业务场景

场景分析

1. 详情页

静态数据、动态数据分离，静态数据需放入客户端缓存

• 商品详情：静态数据，需要缓存

• 秒杀数据：库存，秒杀时间

• 秒杀按钮

• 点击该按钮，请求排队进入订单页

• 获取成功则进入下单页，否则秒杀失败

• 未开始秒杀、秒杀失败、库存为 0 都应不允许再点击

2. 订单页

• 地址信息：展示默认地址

• 活动信息：商品缩略图、商品标题、秒杀数量、秒杀金额等信息

• 提交订单按钮：

• 点击该按钮，先扣减 redis 库存，是否为负

• 提交订单成功，会扣减真实库存

• 提交订单失败，库存为 0 或小于 0

• 异步请求，每秒轮询，是否可以支付

3. 支付页

• 支付成功，则下单成功

• 超时未支付，自动归还库存

架构设计

性能评估

• 用户数量：50w

• 查看详情页：秒杀前 5 分钟

• 下单限制：必须登录

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

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

详情页

• 商品详情：QPS 2500（50w/(5min*60)）

• 库存信息：QPS 50w

订单页

• 地址信息：QPS 2500

• 提交订单：TPS 2000

支付页

• 支付：TPS 1000

存储架构设计

• 数据持久化到 MySQL

• 存储秒杀订单、秒杀活动

• 其他数据可访问其他服务接口即可

• 缓存数据使用 Redis sentinel

• 消息队列 RocketMQ

计算架构设计

• 负载均衡

• 缓存架构

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

• WEB 容器缓存：缓存详情页-静态数据

• 应用缓存：缓存秒杀活动信息（总库存数量、剩余库存是否为 0）、请求计数器

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

• 后台处理

功能

• 消费堆积在秒杀请求队列中的请求

可扩展架构设计

秒杀服务独立部署即可

高可用架构设计

一主多从架构

总体架构