如何设计一个秒杀系统
15
15
1.0x
00:00/00:00
登录|注册

04 | 流量削峰这事应该怎么做?

分层校验的基本原则
漏斗式设计
秒杀答题的设计思路
延缓请求
防止秒杀器作弊
增加购买复杂度
其他排队方式
消息队列缓冲瞬时流量
总结一下
分层过滤
答题
排队
为什么要削峰
高并发系统中的“流量削峰”应该怎么做?

该思维导图由 AI 生成,仅供参考

如果你看过秒杀系统的流量监控图的话,你会发现它是一条直线,就在秒杀开始那一秒是一条很直很直的线,这是因为秒杀请求在时间上高度集中于某一特定的时间点。这样一来,就会导致一个特别高的流量峰值,它对资源的消耗是瞬时的。
但是对秒杀这个场景来说,最终能够抢到商品的人数是固定的,也就是说 100 人和 10000 人发起请求的结果都是一样的,并发度越高,无效请求也越多。
但是从业务上来说,秒杀活动是希望更多的人来参与的,也就是开始之前希望有更多的人来刷页面,但是真正开始下单时,秒杀请求并不是越多越好。因此我们可以设计一些规则,让并发的请求更多地延缓,而且我们甚至可以过滤掉一些无效请求。

为什么要削峰

为什么要削峰呢?或者说峰值会带来哪些坏处?
我们知道服务器的处理资源是恒定的,你用或者不用它的处理能力都是一样的,所以出现峰值的话,很容易导致忙到处理不过来,闲的时候却又没有什么要处理。但是由于要保证服务质量,我们的很多处理资源只能按照忙的时候来预估,而这会导致资源的一个浪费。
这就好比因为存在早高峰和晚高峰的问题,所以有了错峰限行的解决方案。削峰的存在,一是可以让服务端处理变得更加平稳,二是可以节省服务器的资源成本。针对秒杀这一场景,削峰从本质上来说就是更多地延缓用户请求的发出,以便减少和过滤掉一些无效请求,它遵从“请求数要尽量少”的原则。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

文章介绍了在高并发系统中处理请求的“流量削峰”技术,以减轻系统压力和提高服务质量。主要包括排队、答题和分层过滤三种处理方式。排队通过消息队列缓冲瞬时流量,答题增加请求复杂度延缓请求发出,分层过滤则在不同层次过滤无效请求,减少系统压力。分层过滤的核心思想是在不同层次尽可能过滤无效请求,让有效请求通过。此外,文章还提到了分层校验的基本原则和目的,以及在处理流量削峰时可以采用业务手段的方式。总体而言,文章深入浅出地介绍了这些技术手段的设计思路和实现方式,对于处理高并发请求的系统开发人员具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《如何设计一个秒杀系统》
立即购买
登录 后留言

全部留言(53)

  • 最新
  • 精选
  • 胡镇华
    用消息队列实现的话,处理结果无法立即知晓,用户体验不真实,有没有更实时的方案?

    作者回复: 就是实时处理,每个请求过来实时处理,先过来先处理

    2018-10-04
    10
    39
  • 看不到de颜色
    看完本篇文章,有几点疑问还想请老师解答一下。 1.使用消息队列削峰的话,可以知道消息是否被消费,但是是否真的秒杀成功该如何向用户返回。 2.看到老师提到削峰的方式,之前有看过到诸如令牌桶,漏桶之类的算法。是否也可以在此引入呢? 3.如果并发请求过大的话是否可以在每个服务上加入信号量来控制,数量为库存大小。每当处理一个请求就减一下,归零不再向下处理呢。

    作者回复: 大家对请求队列这块问的比较多,疑问也多,后面相关的问题我找个时间统一回答一下吧。

    2018-10-15
    10
  • Ballontt
    可不可以前端直接按照1%的概率去请求后台接口。请数量一下就下降了100倍

    作者回复: 光从减少请求的角度可以,但是体验会很差😃

    2018-10-04
    2
    10
  • Lost In The Echo。
    请求入队列后怎么给用户“交代”?

    作者回复: 参考一下nero的回答哈

    2018-10-04
    10
  • 皇甫
    请问徐老师,当请求被丢进消息队列以后,是就直接返回给用户吗? 那用户怎么知道请求是否成功了呢?

    作者回复: 如果是同步的就要等待消息被正确投递后才返回结果,但大部分就是异步的,寄发送后即返回,然后由消息队列保证最后最终被投递,这个要由消息队列自己来承诺sla

    2018-10-08
    9
  • Geek_c991e0
    大神问下,如果秒杀库存总数是10,那削峰队列大小就是10吗,如果有后面不买了,但是已经入了队列了,怎么办。还是说队列放所有请求,这样的话是不是浪费啊

    作者回复: 入了队列不处理就超时了,队列的大小不应该和秒杀商品数关联

    2018-11-05
    5
  • GrubbyLu
    徐老师看了其他同学的留言以及您的回复之后,还是有一点不能理解。就是用消息队列进行解耦之后,如何把消息队列处理秒杀请求的结果反馈给用户,有什么好的通知方式嘛?(看到有一个同学留言说用长链接异步推送结果,您说用户体验偏差,麻烦能介绍一些好的方式嘛)

    作者回复: 大家对请求队列这块问的比较多,后面相关的问题我找个时间统一、详细回答一下吧

    2018-10-14
    4
  • 潘政宇
    队列被打满了,直接丢包吗?

    作者回复: 有多种处理方式,一种是丢弃 还有可以把队列序列化到文件,然后再慢慢消化

    2018-10-04
    4
  • 大老杨
    这种答题的是不是对于秒杀场景用户体验不是很好

    作者回复: 答题是有两种效果 一是可以防止一些秒杀器 二是可以延长一部分答题时间 是不是影响体验,我觉得体验和上面两条相比应该要做些妥协

    2018-10-04
    2
    4
  • LionHeart
    有个奇怪的想法,比如10万个人12:00秒杀10个商品,系统在12:00前在10万个人中挑选10个用户id放缓存,真正秒杀时直接判断用户id在不在缓存中,在缓存就进入后面的逻辑,最差的情况就是缓存中的10个用户最终没有来秒杀,那再走正常的秒杀逻辑

    作者回复: 😂

    2019-05-17
    8
    3
收起评论
显示
设置
留言
53
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部