《面试补习》-- 来聊聊削峰填谷!
概述
今天想和大家聊聊削峰填谷
,最近 B 站
发生的机房断电
事件,和A站
的服务雪崩,让我们对高可用关注了起来,之前梳理了高可用三剑客 限流
,熔断
和降级
,今天想继续聊聊削峰填谷
,也为后面的高性能篇
做一下铺垫, 想回顾一下之前相关内容的童鞋,可以查看一下,下面文章,欢迎点赞
,收藏
,关注
三连,感谢!
高可用系列文章:
削峰和填谷
技术源于生活
在我们理解的削峰填谷
的流量趋势图
,如下图所示,在流量高峰阶段削去
高峰流量,在流量下降时,填补
这部分流量,使流量趋向平衡。
简单概述一下,削峰
和 填谷
削峰: 为保证服务可用,剔除部分流量。 --业务有损
填谷: 在服务能力盈余的情况下,提供补偿操作。 --业务补偿
削峰
通过削去流量尖刺,让请求流量趋向平稳,以保障服务的稳定性。
客户端削峰
服务端削峰
上面有提到,削峰是业务有损的行为,削掉的这部分流量,可能在电商系统中,致使我们丢失这个用户。
1、客户端削峰
在后端的思维里面,削峰动作更多是服务端同学
的工作和思考。但是在整体系统的设计中,客户端的削峰也是必不可少的。通过客户端的削峰,可以削减服务端的压力,从而保障系统的可用性
。
1.1、资源动静分离
这个方案比较简单,或者说目前基本都采用的方式。通过将静态资源
与服务端隔离
,在活动开始前,将资源预热到 CDN,减轻服务端的压力。客户端与服务端的交互,只有动态数据的交互。
1.2、请求削峰
1、设置两次请求最小有效时间间隔
设置两次请求之间的时间间隔为 t, 在每次请求间隔内的请求,都会被忽略掉,不向服务的发起请求,假设 t 秒内,每个用户只会触发一次有效请求,对应的 qps 为 1/t
,如果用户量为 Q, 那么最大的 qps 为 Q / t
。
2、公平性策略
每个用户一次活动周期内有效请求概率是 P,比如概率 0.2,也就是 5 次中 1 次请求机会,或者 10 次中 2 次请求机会。根据随机算法+插值算法生成请求序列:
根据上述方式就可以得到公平性策略,粒度可以自由把控
2、服务端削峰
2.1、限流削峰
在之前的限流相关文章中有介绍到,服务端限流主要有
网关限流
容器限流
服务器限流
在服务器限流中, 主要介绍了,使用Sentinel
来做流量控制,通过下面的流量图可以看到,流量控制在了 2 qps
,峰值流量通过快速失败
的方式返回。 那么,对于这部分被拒绝的流量,我们从业务角度来看的话,是有损的。
2.2、MQ 削峰
在消息队列
的架构中,有 pull
和 push
两种消息同步的方式,我们可以通过下游系统 订单系统
主动拉取pull
的方式,来保障下游服务的流量稳定。
那么,我们是否可以脱了了限流
,只通过 MQ
的方式,来达到削峰
呢? 答案是: 不能!
假设秒杀系统的 流量是 : 10000 qps
,订单系统的消费能力只有 100qps
。活动时间如果持续比较长,会产生消息堆积过多。 一方面会对消息中间件
造成压力,另一方面,消息的有效性
也没办法保障。
因此在这个链路图中,实际场景会是这样子:
流量先经过 Sentinel
等限流中间件的调平后,由秒杀系统提交 MQ 任务
。
填谷
从上面的削峰策略
可以看到,大部分的削峰
都是业务有损的,从客户端发起请求限流
,到服务端的中间件限流
。对于这部分的请求,都是直接丢弃的。而在 MQ削峰
的场景下,我们可以通过将请求缓存
的方式,减缓流量压力,有下游服务来控制请求压力,从而达到削峰
的效果。
脱离了削峰,就不存在填谷了
在 MQ削峰
的场景中,我们主要保障的是 订单系统
的流量稳定性, 如果 秒杀系统的消息流量为 100tps
,订单系统的处理能力为 200tps
,那么,对于下游系统来说,就不存在峰值流量了!
如有其他场景,可以交流纠正
填谷补偿
在峰值
流量阶段,出现部分流量无法得到马上的处理,通过峰值流量过去后,在消费能力盈余
的情况下,对之前的请求做补偿操作,使整体流量趋向于平稳。
比如在上述链路图中,秒杀活动持续了 1 分钟,
产生请求为:
60 * 100 = 6000
个请求。消费时间为:
6000 / 50 = 120
秒。
在用户可接受的范围内(1分钟的等待
),获取自己的秒杀下单结果
。同时对订单系统的负载做好保护
。
消息队列的风险
相对于其他的削峰方案,看起来MQ削峰
方案是最优的,那为什么我们在 流控方案上,还是更加注重限流
方案上。而不是统一使用 MQ削峰
呢?
每个方案都存在利弊,引入 MQ
,能为我们解决 削峰
,异步
和解耦
等问题。但是,在引入 MQ 中间件的同时,也会为我们带来以下的问题:
中间件可用性
:MQ 队列不可用,会导致整个链路不可用,严重会造成雪崩消息可靠性
:消息发送,消费需要得到保障消息堆积
:消息生产过快,导致 MQ 中间件压力过大消息重复
:消费幂等能力支撑消息顺序
:部分场景要求消费按照顺序执行
点关注,不迷路
在架构设计中,很重要的一点,每个方案都是有利有弊
,而我们在进行架构设计时,需要考虑引入一个解决方案时,权衡这个方案的利弊
,最终落地。
好了各位,以上就是这篇文章的全部内容了,下一篇文章会梳理高可用秒杀系统的架构设计
欢迎大家关注。感谢大伙能看到这里,如果这个文章写得还不错, 求三连!!! 创作不易,感谢各位的支持和认可,我们下篇文章见!
我是 九灵
,有需要交流的童鞋可以关注公众号:Java 补习课
,掌握第一手资料! 如果本篇博客有任何错误,请批评指教,不胜感激 !
版权声明: 本文为 InfoQ 作者【九灵】的原创文章。
原文链接:【http://xie.infoq.cn/article/31c814915d1ba33eaf9327bd0】。文章转载请联系作者。
评论