电商平台常用的秒杀系统结构布局

一、背景

业务背景

公司决定进行 618 大促

1、大促的商品为各大电商平台上畅销和好评的商品

2、挑选的商品范围为 10 个品类,每个品类不超过 20 个商品

3、秒杀选择了 1000 个充电宝,10 台 iPhone 12 作为秒杀商品

4、日活大约 100w 用户

5、需要保证万无一失

6、秒杀活动为限价秒杀

技术背景

1、团队以 Java 为主

2、已经落地了微服务

3、主要渠道是自有 APP(安卓和 IOS)

4、只有下载 APP 才能参加秒杀

5、目前为单机房

目前现状

目前已经落地微服务的电商平台(类似模块 6)。目前拆分的微服务为:

  • 用户服务
  • 商品服务
  • 订单服务
  • 支付服务
  • 购物车服务
  • 物流服务
  • 结算服务
  • 统计服务

架构为:

设计电商秒杀系统

目前的选型如下:

服务接入层:

  • 使用 Spring Cloud Gateway 作为服务网关
  • 使用 Hystrix 实现服务容错,以及限流、熔断等

服务运行层:

  • 使用 Eureka 实现服务注册和服务发现
  • Feign 和 Ribbon 做远程服务调用和服务路由以及负载均衡

技术支撑层:

  • 容器使用 docker
  • 编排使用 k8s
  • 分布式事务使用 Seate
  • 监控工具使用 Promethus 等

基础设施层:

  • 日志使用 ELK
  • 分布式锁使用 redisson
  • 消息队列使用 kafka
  • 缓存服务使用 redis 集群
  • 搜索服务使用 ES
  • 监控使用 CAT

公有云服务:

  • 阿里云 OSS
  • 阿里云、网宿、帝联 CDN
  • 阿里云数据分析
  • 万网域名
  • DNSPOD DNS 和 HTTPDNS

约束条件

  • 秒杀系统需要在 5 月底前完成
  • 公司第一次大规模大促,秒杀系统不允许出现问题
  • 秒杀系统不能影响普通商品的交易
  • 秒杀系统人力为 10 人
  • 只有 APP 端用户参与秒杀活动

二、业务场景

商品抢购过程如下:

设计电商秒杀系统

商品详情数据:

1、商品名称

2、价格

3、图片信息

4、其他信息展示

结算页面数据:

1、商品名称

2、价格

3、抢购数量

4、地址

5、支付方式

6、其他信息

支付:

将生成的订单信息传给下游的订单接入接口

在秒杀的运营系统中设置好活动的开始和结束时间,以及投入的库存。在活动开始后,用户通过抢购入口,进入到活动的结算页,然后点击下单,完成商品的抢购操作。库存在抢购到的时候锁定,付款之后减去。操作过程如下:

设计电商秒杀系统

整个下单过程:

1、生成订单

2、预占库存

3、支付

场景特点如下:

1、秒杀时候有很大的瞬时流量

2、热点数据

3、业务流程短

4、库存少

5、可能会有刷流量的情况

三、估算

用户量预估

日活 100w,按照 30%参加活动,100w*30% 有 30w 用户参加秒杀活动

关键行为

  • 抢购:浏览商品详情页;点击抢购按钮
  • 下单:浏览下单页面;点击下单按钮
  • 付款:点击付款按钮

用户行为建模和行为估算

日活用户 100w,假设有 30%的用户会参与秒杀活动。充电宝 1000 个,Iphone12 10 台,一共的订单量为 1010 单。

性能估算

抢购:

抢购前用户可能会不断的刷新页面,抢购按钮变为可用后,会点击按钮,假如页面响应慢,则可能会反复点击。大部分操作集中于秒杀开始的时间点前后 10s 。

假设平均每个用户会在整个时间段内平均刷新页面 5 次,平均点击按钮 2 次。

QPS:30w*5 / 20 = 7.5w QPS

TPS: 30w*2 / 10 = 6w TPS

下单:

进入结算页面,假设秒杀的用户都提前填好地址等用户信息。只需要提交订单就可以。假设在 10s 内平均每个用户提交两次。

TPS:30w * 2 / 10 = 6w TPS

付款:

只有抢占库存才会进入到付款页面。假设 15 分钟内全部完成支付。商品一共 1010 单,这样 15 分钟内的 TPS 会比较小。

性能汇总:

QPS:13.5w QPS

TPS:6W TPS

存储估算

和之前电商系统一样静态文件使用 OSS 进行存储。因此只估算秒杀商品的存储情况。因为本次秒杀的商品信息只有两种,假定所有信息存储起来占用 10M。存储空间占用就是 10M *2 = 20M

四、总体设计

为了活动过程不影响普通商品的服务,对秒杀系统进行相应的隔离。分别从业务、系统和数据进行相应的隔离。业务上和普通商品走的流程是不一样的。针对秒杀系统涉及到的系统进行物理隔离。如下所示:

设计电商秒杀系统

流量进行分流,从入口域名开始使用单独的域名,同时系统从流量入口开始使用单独的系统,从应用服务层到微服务进行流量隔离。在整个基础上,数据层进行单独的部署。

隔离的流程大致是,系统对秒杀 sku 进行打标,从详情页开始识别出秒杀标,路由到秒杀的商品详情页域名,进入到单独的秒杀集群。

功能结构图

设计电商秒杀系统

系统架构图:

设计电商秒杀系统

五、存储架构设计

目前已经实现动静分离(根据是否包含访问者个性化数据来判断),对于图片、HTML、JS、CSS 等文件存储于统一的对象存储中,实际访问的时候通过 CDN 进行访问。秒杀商品的静态页面确定好,一般不会变动。在 CDN 侧可以进行提前预热。所以下面的存储设计主要是针对动态数据的存储。

秒杀动态数据存储分析如下:

设计电商秒杀系统

数据结构设计:

  • 存储类型:MySQL 集群
  • 相关数据表设计如下:
设计电商秒杀系统

六、计算架构设计

秒杀场景下的读操作比例一定远远大于写操作比例。

负载均衡

多级负载均衡架构如下:

设计电商秒杀系统

静态资源域名都准备两套,策略由 GSLB 进行设置,域名分别接入不同厂商的 CDN。App 在获取域名解析的时候,优先从 HTTPDNS 拿解析,如果拿不到解析或者异常由 DNS 进行保底。同一类资源客户端尝试不同的两个域名。客户端对域名采用预解析方式。

动态请求,经过 CDN 的动态加速进行。全局负载均衡策略和静态资源类似。

分布式缓存

秒杀系统系统多级缓存:

设计电商秒杀系统

商品的图片、视频等资源缓存在 CDN 中。其余的缓存为商品详情和商品库存。商品详情这些变化比较少的数据,在秒杀活动开始之前,全量推送到所有的 web 服务器上的本地缓存上,直到活动结束,针对这类数据设置较长的定时轮询时间。对于商品库存信息设置时间短的轮询时间,对于读场景,可以接受一定程度的出现数据脏读。可能会存在已经没有库存的少量下单请求误以为有库存,等到最终扣减库存的时候,提示用户商品售罄。

热点数据

因为秒杀的缓存数据为热点数据,所以采用副本方式,结构如下:

设计电商秒杀系统

所有副本的生成时间和实效时间添加一个随机值,避免同时生成,同时失效。

扣库存

因为减库存会产生比较大的并发更新请求直接在数据库中扣减同一秒杀商品的库存数据,这样会导致线程之间竞争 InnoDB 行锁。数据库中针对同一行数据的更改是串行执行的,如果某一个线程没有释放锁之前,其余的线程会阻塞,这样并发越高等待的线程就越多。这样的情况会影响数据库的 TPS。前面缓存了库存的数据,扣库存采用直接在库存中进行。扣减过程如下:

设计电商秒杀系统

接口高可用

限流

在接入端采用漏桶方式进行限流。

设计电商秒杀系统

排队

设计电商秒杀系统

答题

设计电商秒杀系统

七、微服务拆分

服务拆分

1、一共有 10 个后端,应用三个火枪手原则,可以同时开发 3 个微服务

2、由于是从 0 到 1 开始单独做秒杀系统,采用业务拆分方式进行

3、目前公司已经落地了电商微服务系统,有业务专家,拆分方式采用粗分然后演进的形式

最终拆分的微服务为:

  • 秒杀详情系统
  • 秒杀库存、商品系统
  • 秒杀交易系统

微服务框架选型

后端团队目前技术栈统一为 JAVA,前期规模不会特别大,框架选择使用嵌入 SDK 的方式。

设计电商秒杀系统

服务的选型和电商微服务的相同。架构类似。

八、异地多活

业务分级

秒杀按照重要性,业务分为抢购、下单、支付和页面服务

数据分类

抢购

  • 依赖商品服务
  • 库存数据全局唯一,需要保证数据强一致性
  • 商品信息一般不会更改

下单

  • 依赖订单服务
  • 数据全局唯一,需要保证强一致性

支付

  • 依赖支付服务
  • 数据全局唯一,需要保证强一致性

页面服务

  • 依赖
  • 页面信息活动开始后一般不会更改

数据同步

缓存数据不同步,开始活动前进行预热

抢购

  • 库存数据,数据库同步
  • 库存缓存数据,redis cluster 同步
  • 商品信息,redis cluster 同步

下单

  • 数据库同步

支付

  • 数据库同步

异常处理

抢购

  • CDN 直接返回 503 页面

下单

  • 挂公告;推迟秒杀或者给予补偿

支付

  • 挂公告;补库存或者给予优惠券

多活示意图:

设计电商秒杀系统

九、质量设计

可测试性

服用电商微服务平台的自动化测试平台

可维护性

复用电商微服务平台的基础设施

可观测性

复用电商微服务平台的监控

  • 项目添加基础监控
  • 每隔一段时间进行巡检
  • 每隔一段时间进行备份

十、演进规划

1、第一期先完成 618 功能需求

2、第二期完善秒杀系统,添加比如策略系统等,以支持更多类型的秒杀活动

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 1219982080@qq.com 举报,一经查实,本站将立刻删除。

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-04-27 16:46
下一篇 2022-04-27 16:49

相关推荐

  • 国付宝信息科技有限公司发生工商变更贝宝支付

    近日,PayPal收购的国付宝信息科技有限公司(以下简称“国付宝”)发生一系列工商变更,其中包括更名,由国付宝更名为贝宝支付(北京)有限公司(以下简称“贝宝支付”),自此国付宝一名成为中国支付行业的过去式,而迎来贝宝支付的新时代。结束了长达10年的支付牌照漫长申请过程。 对于更名缘由,Paypal则表示”作为Paypal在中国的全资子公司,将致力为中国用户带…

    2022-05-24
    00
  • 个人做电商,必备的几大技术

    现在社会,电商成为了现在必不可少的工具之一,因为大家都习惯了网上购物,选货。 所以很多网友都想自己开店做电商,但是大家都别忘了,要自己做电商,并非一个简单的事,因为做电商,并非是简简单单拍照,然后上传图片,就能够卖出商品的,要做网店,得需要好多东西,才能够让你的店铺有生意,甚至能做赚钱。 首先,大家在决定做电商的时候,就给考虑好,你自己的产品是否真的适合上电…

    2022-04-27
    00
  • 淘宝优惠券营销层出不穷,技术手段推荐最优的优惠券组合

    导语:之前花了大量的篇幅介绍优惠券的作用、怎么建券、怎么使用、怎么核销等的文章,对此感兴趣的同学,可以先看看下方的文章,希望能对大家有一些帮助。本篇文章主要介绍当用户在订单结算过程中,通过技术手段替用户推荐最优的优惠券组合,达到帮用户省更多钱目的。 现在的电商,针对优惠券营销真的是层出不穷,有单品券、品类券、品牌券、无门槛券、满减券、打折券、免邮券等等。优惠…

    2022-04-16
    00
  • 电商快排创业项目诚邀加盟商,共同瓜分百亿市场

    电商快排创业项目诚邀加盟商,共同瓜分百亿市场!  该项目主要服务的群体为广大电商创业者,支持的平台有淘宝、京东、拼多多、抖音、快手、小红书六大板块,无论是是电商系单品的人气提升,稀释转化率,还是热门短视频打造,直播间互动,平台都有比较完善的任务板块可供选择,自有机房,分站源码部署,安全稳定,全系任务给到代理商最低接口价。  目前版本支持的任务分为:电商系和短…

    2022-05-24
    00
  • 全新电子电气架构出现,让全车OTA不再是电车专利

    出生即拥有互联网的Z世代,被认为是能真正改变世界的一代人。 几年前起,从游戏、社交到教育,都在寻找满足Z世代人群需求的方式。只有能吸引更多年轻人的产品,才受到更多追捧。以颇受关注的视频平台赛道来看,MAU不到爱奇艺一半的BiliBili,市值在相当长的时间内是前者的3倍。 在将虚拟世界推向了视频、圈层与社交化后,来自新一代的需求也开始改变现实世界。一个被普遍…

    2022-06-06
    00

发表回复

您的电子邮箱地址不会被公开。

联系我们

13515318674

在线咨询: QQ交谈

邮件:1219982080@qq.com