写点什么

电商秒杀系统设计

作者:tom
  • 2022 年 5 月 15 日
  • 本文字数:1230 字

    阅读完需:约 4 分钟

1.业务背景

该系统的业务背景概括如下:

  • 日活 100 万

  • 20 个商品,10 个品类,共 200 个商品

  • 秒杀商品有限,1000 个充电宝,10 台 iphone 12

  • 团队以 java 为主,现有系统采用微服务架构

  • 只有 app 才能秒杀

  • 当前采用单机房设计

  • 只限于秒杀系统设计

2.基本场景

该系统的基本业务场景如下:

基本场景包括注册、登录、浏览商品、下单、支付场景。其中:

  • 注册 &登录场景

百万注册用户,每天活跃用户 40%,登录时读取用户信息是每天 40 万 QPS;

  • 浏览商品

共 20 个秒杀商品,商品数量忽略不计;

每月活跃用户约 40%。秒杀活动前会有推广活动,活跃用户会有提升,以 60%计算,约有 60 万用户同时在线浏览商品,tps 数为 600K;

  • 下单

订单数量,秒杀商品共 1010 个,那么订单总数也为 1010 个,要求在 1s 内完成处理,因此 tps 为 1010;

  • 支付

支付一般在 5 分钟内完成。tps 约为 1010/300=4tps,可忽略不计。

3.重点场景分析

3.1.浏览秒杀商品

  • 业务特征分析

典型读场景,由于订单下了后仅有少量修改,因此适合用缓存架构

  • 架构分析

1)用户量过百万,应用用多级负载均衡架构;

2)请求量 60 万,应该用多级缓存架构,考虑用三级缓存架构,app 缓存+web 容器缓存+分布式缓存,不用 CDN,因为业务量没那么大;分布式缓存用 redis,支持持久化,可以避免丢失订单。

  • 架构设计

登录状态保存在分布式缓存中,请求发送给任意服务器都可以,选择轮询或者随机算法

  • 业务服务器数量估算

由于浏览秒杀商品的处理逻辑比较简单,主要是读缓存系统,因此假设单台业务服务器处理能力是 1000/s,则机器数量为 60 台,按照 20%的预留量,最终机器数量为 75 台。

3.2.下单

  • 业务特征分析

典型写操作,不能用缓存,用负载均衡

  • 架构分析

用户量 60 万,选用多级负载均衡架构。选择 LVS,支持 60 万+性能

  • 架构设计

1)负载均衡算法选择

下单的时候依赖登录状态,登录状态一般都是保存在分布式缓存中,因此下单的时候,讲请求发送给任意服务器都可以,选择轮询或者随机算法

2)业务服务器数量估算

按照一个服务每秒处理 500 来估算,支持 1010 个订单处理,需要三台服务器。

4.存储架构设计


5.计算架构设计

5.1.负载均衡


5.2.多级缓存


6.高可用设计

  • 业务特征分析

1)下单

商品数量有限,下单会在 1s 内下单

2)浏览商品

商品数量有限,100w 用户同时浏览 2 个秒杀商品

  • 架构设计分析

1)下单

下单性能要求比较高,可以考虑对“非秒杀订单”限流,由于非秒杀订单也是收入来源,因此不能丢弃请求,采用漏桶算法。

2)浏览商品

存在缓存热点问题,使用“多缓存副本”。

7.可扩展设计

将商品服务和订单服务拆分出来,支持秒杀活动,其中商品服务支持商品、浏览记录查询,浏览等操作;订单服务支持下单,订单查询等服务。拆分后的微服务架构如下:

8.高可用架构设计

当前系统月活已经到达 100 万,还只是单机房设计,远远不能满足系统稳定运行要求;同时通过秒杀活动会拉新业务量会进一步增长。为保障业务未来一段时间平稳运行,需要将当单机房扩建为同城双中心,时间允许的情况下,跳过灾备方式,直接从单机房升级为双活架构,确保秒杀业务万无一失。



用户头像

tom

关注

还未添加个人签名 2019.02.13 加入

还未添加个人简介

评论

发布
暂无评论
电商秒杀系统设计_tom_InfoQ写作社区