电商秒杀系统架构设计

业务背景

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

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

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

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

技术背景

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

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

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

业务场景

场景分析

• 详情页

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

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

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

• 秒杀按钮

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

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

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

• 异步请求

PS：允许进入下单页的用户可以是比库存多一点

• 订单页

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

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

• 提交订单按钮：

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

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

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

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

• 支付页

• 支付成功，则下单成功

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

处理流程

点击秒杀处理流程

架构设计

性能评估

几点假设

• 用户数量：40w

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

• 下单限制：必须登录

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

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

详情页

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

• 库存信息：QPS 40w

• 秒杀：TPS 40w

订单页

• 地址信息：QPS 2000

• 商品缩略信息：QPS 2000

• 提交订单：TPS 2000，数据量影响可忽略不计

支付页

• 支付：TPS 1000，数据量影响可忽略不计

存储架构设计

• 数据持久化到 MySQL

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

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

• 缓存数据使用 Redis sentinel

• 消息队列 RocketMQ

计算架构设计

• 负载均衡

• 缓存架构

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

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

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

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

• 后台处理

功能

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

可扩展架构设计

秒杀服务独立部署即可

高可用架构设计

就一个机房，暂时先不做灾备处理

总体架构

参考文章

《秒杀架构设计_曹林华的技术博客_51CTO 博客》

https://blog.51cto.com/u_13527416/2085258

《该如何选择消息队列》

https://zhuanlan.zhihu.com/p/86812691

《RocketMQ 架构原理》

https://www.cnblogs.com/qdhxhz/p/11094624.html

《RocketMQ 介绍及集群部署》

https://www.jianshu.com/p/23e04d8178b8

《Redis Decr 命令_将 key 中储存的数字值减一。》

https://www.redis.net.cn/order/3561.html