秒杀系统

用户头像
俊俊哥
关注
发布于: 2020 年 07 月 31 日
秒杀系统

场景

秒杀,是互联网中比较常见的一种高并发场景,大体可以分为:限时抢购限量抢购

分析



上图是一个最简单的请求模型。

假如PM提出一次秒杀活动,有N件商品,在10分钟之内限量销售,每天X场抢购活动,每场持续Y小时。

  1. 安全性,确定请求的是合法用户。

  2. 库存每次售卖都要减库存。

  3. 最小库存数不能为负数。

  4. 一件商品不能卖2次。



设计

  • 对于请求商品页面,提前静态化。

提前生成静态页面,放入CDN等静态资源服务器



  • 提前准备好扩容资源。

现在基本都是基于云的部署,但是像618、双11、跨年,记得提前预备好资源(其他公司也要搞活动,资源很抢手的)。



  • 前端做好时钟控制按钮是否有效。

攻防对战的最初级交锋,就是使用前端按钮置灰能力。这能过滤掉大部分无效请求哦。



  • 能在越前面快速返回越好

活动未开始,业务层针对活动状态标识,做好快速返回(有些人会直接模拟请求,绕过前端置灰能力)。

活动结束后,快速返回。

在能做过滤的最前的位置,做好黑名单。



  • 资源尽量隔离,有Plat B。

做好资源的限流、降级、失败方案。

隔离好正常业务与秒杀业务之间的服务,秒杀挂了不能影响线上其他服务。



  • 业务层与数据层解耦

解耦才能通过中间缓存提速啦。



安全性

单用户控制时间窗口内的访问频率

  1. 验证码

  2. IP限制

  3. 隐藏入口

羊毛党、脚本党

  1. 转入黑洞服务

  2. IP限制

  3. 验证码

高性能

不止秒杀系统,其实是有的系统架构设计都需要考虑「分解压力」,在互联网项目中,大流量峰值不少见,这些流量理论上来说最终都会落到一个地方,并且最终会有一个有状态的最终节点,往往是性能瓶颈。



所以很多高性能系统,考验的就是如何分解压力避免请求层层传递或者怎么进行纵向、横向扩展。

使用Redis缓存进行库存增减

基于Redis做库存增减,使用任务对DB->Redis的更新。

Redis分布式锁的实现(这里是个大话题...)

维护秒杀结束标识

所有秒杀相关接口,都加上秒杀活动是否结束标识判断,如果结束直接返回,包括轮询拉取的接口。

控制请求队列长度

也算是对系统的一种限流保护策略,是从请求堆积量来衡量。

特殊方案(产品协调)

  1. 如果产品可以的话,使用消息队列异步下单,削峰填谷。

  2. lua + nginx 或 lua + redis 进行流量过滤。

兜底方案

降级

当系统的容量达到一定程度时,限制或者关闭系统的某些非核心功能,从而把有限的资源保留给更核心的业务。

限流

当系统容量达到瓶颈时,我们需要通过限制一部分流量来保护系统,并做到既可以人工执行开关,也支持自动化保护的措施。

拒绝服务

服务负载达到极限时,进行拒绝服务操作,保护服务正常恢复。

发布于: 2020 年 07 月 31 日 阅读数: 35
用户头像

俊俊哥

关注

架构是平衡的艺术 2013.06.01 加入

还未添加个人简介

评论

发布
暂无评论
秒杀系统