写点什么

架构训练营毕业设计:电商秒杀系统

作者:AragornYang
  • 2022 年 5 月 15 日
  • 本文字数:1110 字

    阅读完需:约 4 分钟

架构训练营毕业设计:电商秒杀系统

秒杀基本场景


  • 注册、登录

  • 查看秒杀商品

  • 尚未开始

  • 可秒杀(库存数量)

  • 秒杀结束

  • 秒杀下单

  • 狼多肉少

  • 订单支付

  • 回退库存(支付失败时)

难点

  • 秒杀限流

  • 客户端限流

  • 服务端限流

  • ID 限流

  • IP 限流

  • 库存限制

  • 秒杀扣库存

  • 扣库存不能等到支付完成。

  • 下单时扣库存,线程内,先扣库存后下单。

  • 回退库存

  • 支付失败时回退库存

  • 支付超时

  • 取消支付

  • 秒杀微服务

  • 秒杀类商品详情的动态数据,从秒杀微服务获取

  • 秒杀类商品的下单,插入秒杀判定步骤,由 App 端和秒杀微服务负责

  • 秒杀判定通过,App 端走正常的订单下单流程

  • 支付失败时在秒杀微服务内回退库存

性能估算

日常

  • 日活 100 万用户

  • 200 个商品

商品动态数据请求

假设每日活用户每天浏览 10 件次商品

  • 每日总计商品浏览 100 万 * 10 件次 = 1000 万件次

  • 每秒平均商品浏览 1000 万件次 / 8.64 万秒 = 116 件次/秒

下单请求

  • 每日下单 10 万

  • 每秒平均下单 = 10 万 / 8.64 万秒 = 1.16


由于峰值往往是均值的几十倍,假设现有订单微服务能够承载 每秒峰值下单 100。

大促秒杀

假设浏览集中在秒杀开始前后各 5 分钟内。


秒杀商品动态数据请求

  • 100 万秒杀参与者,人均载入秒杀商品动态数据 10 次

  • 每秒 1000 万 / 60*10 秒 = 1.67 万次


秒杀请求

客户端百倍限流

  • 100 万秒杀参与者,限流掉 99%,只剩 1 万参与者向服务器发起秒杀请求


下单请求

秒杀微服务判定为秒杀成功的大约只有 1010 单,订单创建排队延后。

  • 已有订单微服务可以承载 每秒峰值下单 100

  • 大约 1010 / 100 = 10 秒内完成所有订单创建

架构设计

存储架构设计

存储性能估算

  • 存储 100 万秒杀参与者的 ID,IP

  • IP 4 字节

  • 用户 ID 8 字节

  • 100 万 * 12 字节 = 12 MB

  • 如果进行了客户端百倍限流,1 万 * 12 字节 = 0.12 MB


  • 存储 1010 个秒杀成功的用户 ID,订单 ID

  • 用户 ID 8 字节

  • 订单 ID 12 字节

  • 1010 * 20 字节 = 20 KB


如果不进行客户端百倍限流,虽然存储容量需求很小,但考虑到访问的短时密集性,秒杀系统需要使用独立的 Redis Cluster 对 Redis 访问进行分流。

计算架构设计

负载均衡

秒杀系统并不冲击现有的负载均衡,沿用现有设计即可。

但秒杀服务内,如果不进行客户端百倍限流,考虑到访问的短时密集性,秒杀系统需要使用对访问进行分流。

客户端百倍限流

客户端限流就是在客户端进行极端的负载均衡,根据特定算法,不向服务器发起请求就直接判定某些秒杀失败。如果本地阻截 99% 的秒杀请求,就实现了百倍限流。

缓存

原有的多级缓存

  • 本地缓存(App 内缓存)

  • CDN 缓存

  • 分布式缓存


秒杀的静态资源继续使用原有的多级缓存

  • 本地缓存(App 内缓存)

  • CDN 缓存


秒杀的库存数量

  • 应用内缓存


要提前进行缓存预热。


其它

可扩展方面无需额外改进,加入秒杀前已经使用了微服务。

高可用方面可以进行同城双中心的演化,但考虑到秒杀系统对整个系统的影响微乎其微,至少不会因为加入秒杀系统而进行同城双中心。


用户头像

AragornYang

关注

还未添加个人签名 2018.10.03 加入

还未添加个人简介

评论

发布
暂无评论
架构训练营毕业设计:电商秒杀系统_架构训练营_AragornYang_InfoQ写作社区