您的位置:首页 >网友投稿 >

搭建一个秒杀系统 需要经历这些步骤吗「秒杀系统」

发布时间:2024-02-24 08:36:42 来源:搜狐

秒杀是电商平台的常见配置,用户看到的呈现效果都需要后端的支持,那么,秒杀的后端系统如何根据前端业务需求做调整?笔者针对这个问题,进行了具体的阐述。

秒杀是电商平台最常用的促销活动,例如京东淘宝等主流电商平台把秒杀、抢购作为一个功能入口存在,定期秒杀。

其产品定位在于通过低价促销吸引对价格敏感的用户,起到引流促活,且带动销售。

下图是京东、淘宝的秒杀页面。

那么一个秒杀系统如何搭建?前后端功能如何配合?

都说“前端一小步,后端一大步”,对于C端来说,价格、商品吸引人,我能到特定时间去抢购、付款就可以了。

那么,后端如何做相应的功能支撑呢?

下面我具体阐述一下。

一、秒杀架构

秒杀架构

从此架构看出,一个秒杀完整的系统搭建,后端需要有商家报名参与入口、秒杀活动的设置、后台秒杀活动、订单管理等功能。

二、 商家报名流程

平台可以给商家提供这样的功能入口,一旦商家有意愿做秒杀活动,可以发起由平台审核,审核通过即可上架。

商家是否满足要求:是否对参与商家设置门槛,比如经营较好,店铺综合评分较高的店铺方可参与;提报商品是否满足:比如此商品设置价格合理,是否是违规商品等。

这里我只简单论述,具体需根据每个企业业务性质进行考量。

三、秒杀活动设置活动信息:包括秒杀时间、渠道、秒杀模板(不会做图的商家可提供模板套用);活动限制条件:每个用户的限制购买次数、购买数量等;活动商品:设置活动商品价格、库存、时间段等。四、秒杀抢购

对于C端用户是否有意愿参与秒杀、是否有心仪的商品、抢购流程是否顺畅等需求点进行考虑。

是否有意愿参与秒杀:首先前端交互效果一定要引人入胜;是否有心仪商品:价格、商品是否吸引用户;抢购是否顺畅:活动预热是否充分,可设置提醒/活动开始时候库存是否充足,是否超过限购数量,售完是否可以原价购买等;

下面是我自己整理的秒杀流程图,仅供借鉴。

五、技术层面实现

这部分也是参考一些大神的博客得出的一些技术层面的心得,可能不是很恰当,希望大家指正。

1. 前端高并发

前端常用的方法是扩容、静态化、限流。

扩容:

加机器,这是最简单的方法,通过增加前端池的整体承载量来抗峰值。

举个通俗的例子:

比如我想运送100棵树木,我准备两辆卡车,一辆运50,计算公式就是2辆X50棵/辆X1小时=100棵/小时。

那如果我需要搬运更多的树木,我可以通过增加车辆、也可以增加每辆车的运输量、或者缩短运输时间。

这就是扩容的概念。

静态化:

将活动页面上的所有可以静态的元素全部静态化,并尽量减少动态元素,通过CDN来抗峰值。

限流:

一般都会采用IP级别的限流,即针对某一个IP,限制单位时间内发起请求数量;或者在活动入口,增加游戏或者问题环节进行消峰操作。

有损服务:

最后一招,在接近前端池承载能力的水位上限的时候,随机拒绝部分请求来保护活动整体的可用性。

2. 后端如何解决

方案:本地标记 Redis预处理 RabbitMQ异步下单 客户端轮询。

实现:

在秒杀阶段使用本地标记对用户秒杀过的商品做标记,若被标记过直接返回重复秒杀,未被标记才查询redis,通过本地标记来减少对redis的访问。抢购开始前,将商品和库存数据同步到redis中,所有的抢购操作都在redis中进行处理,通过Redis预减少库存减少数据库访问。为了保护系统不受高流量的冲击而导致系统崩溃的问题,使用RabbitMQ用异步队列处理下单,实际做了一层缓冲保护,做了一个窗口模型,窗口模型会实时的刷新用户秒杀的状态。client端用js轮询一个接口,用来获取处理状态。六、总结

以上是自己对于设计秒杀系统的思路,不喜勿喷。

如果大家有更多的思路希望和我多多交流,不断补充。

本文由 @琛琛 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

热门排行

经典笑话

编辑推荐