写点什么

架构实战营模块九作业

作者:zhongwy
  • 2022 年 3 月 10 日
  • 本文字数:1402 字

    阅读完需:约 5 分钟

设计电商秒杀系统

基本业务场景


设计思路

机房部署

  • 秒杀系统实为当前电商系统的一个子系统;

  • 为避免秒杀流量对当前电商系统产生不利影响,隔离原则,结合电商系统现状,只有单机房,准备把秒杀系统部署在同城的另一个机房;

  • 秒杀系统中创建单独的数据库,主要包括活动商品表、活动库存表、活动订单表。

削峰限流

  • 秒杀阶段的短时间流量会是平时正常流量的几十上百倍,甚至更多,不太可能也没有必要准备几十上百倍的设备及带宽,流量集中在秒杀商品页,及秒杀请求,可以用 CDN 来扛;

  • 秒杀商品页为静态页提前把资源推送到 CDN;

  • 假设一共 100 个 CDN 节点,每个 CDN 节点平均取前 1000 个请求,计 10 万个推给秒杀系统;

  • 秒杀前 2 秒生成秒杀请求 URL,而且 URL 要经过加盐处理,防刷和作弊;

  • 秒杀开始前,秒杀按钮不可用,提交秒杀请求后 5 秒内不能再次提交;

  • 经过 CDN 限流,到秒杀系统后通过防刷、分层校验、限流削峰、限购、层层过滤,再经过库存查验扣减成功后的 1012 个流量进入到订单和支付流程。

库存查验 &扣减

  • 采用 Redis Cluster 保存活动商品库存,两个商品库存分布在不同的切片上,提前预热,无过期时间;

  • 考虑到原子性,使用 lua 脚本做库存查验+扣减处理;

  • 库存扣减成功,即认为秒杀成功。

下单 &支付

  • 下单失败,需要重试机制;

  • 下单未支付超过一定时间,比如 5 分钟未付款,则订单取消,返回活动商品库存。


存储架构设计

用户量 & 关键行为

【用户量】

1.  正常日活 100 万,618 大促当日日活 300 万用户(参考其它电商平台 2021 年数据,大部分为正常日活的一点几到二倍之间)。

  1. 假设 10% 的用户参与秒杀,即 30 万用户。也可以在 CDN 做边缘计算得出实际数量。

【关键行为】

1. 登录/注册;

2. 进入秒杀商品页;

3. 秒杀;

4. 付款。

用户行为建模和性能估算

【注册】

用户注册信息存在于当前电商系统。

【登录】

618 大促日活 300 万,即当天读取用户信息为 300 万 QPS,当前电商系统提供支撑。

【进入秒杀商品页】

进入秒杀页面,假设参与秒杀的用户提前 5 分钟开始陆续进入秒杀页面,则页面请求为 1000QPS。提前生成静态页面,并推送到 CDN,由 CDN 提供支撑。

校对时间,进入页面后,需要每秒向服务器校时,则最高请求为 30 万 QPS。由 CDN 提供支撑。

【秒杀】

秒杀请求,30 万用户参加秒杀,30 万 TPS。

下单,一共 1012 个用户可以成功秒杀到商品,1012 条订单数据,这个量级可以忽略不计。

活动库存,两个商品,一共两条记录,忽略不计。

【付款】

一共 1012 个用户可以成功秒杀到商品,假设用户在 10 秒内完成付款,即 101TPS。

1012 条交易数据,这个量级可以忽略不计。


存储架构

数据量很少,主备数据库架构即可满足要求。

实际上没有必要再另外部署数据库,直接使用当前电商系统的数据库构架即可。


计算架构设计

计算性能估算

【注册】

当前电商系统提供支撑。


【登录】

618 大促日活 300 万,即当天读取用户信息为 300 万 QPS,当前电商系统提供支撑。


【进入秒杀商品页】

进入秒杀页面,假设参与秒杀的用户提前 5 分钟开始陆续进入秒杀页面,则页面请求为 1000QPS。提前生成静态页面,并推送到 CDN,由 CDN 提供支撑。

校对时间,进入页面后,需要每秒向服务器校时,则最高请求为 30 万 QPS。由 CDN 提供支撑。


【秒杀】

秒杀请求,30 万用户参加秒杀,30 万 TPS。

下单,一共 1012 个用户可以成功秒杀到商品,如果 1 秒完成,则 1012TPS,可以忽略不计。


【付款】

一共 1012 个用户可以成功秒杀到商品,假设用户在 10 秒内完成付款,即 101TPS。

发布于: 刚刚阅读数: 2
用户头像

zhongwy

关注

还未添加个人签名 2020.02.28 加入

还未添加个人简介

评论

发布
暂无评论
架构实战营模块九作业_zhongwy_InfoQ写作平台