削峰填谷,你只知道消息队列?

开发 前端
在后端的思维里面,削峰动作更多是服务端同学的工作和思考。但是在整体系统的设计中,客户端的削峰也是必不可少的。通过客户端的削峰,可以削减服务端的压力,从而保障系统的可用性。

[[415619]]

本文转载自微信公众号「Java补习课」,作者九灵。转载本文请联系Java补习课公众号。

概述

日常分享Java核心技术,分布式架构原理,中间件应用与原理等高质量原创文章。致力帮助更多小朋友加入大厂!

今天想和大家聊聊削峰填谷,最近 B 站发生的机房断电事件,和A站的服务雪崩,让我们对高可用关注了起来,之前梳理了高可用三剑客 限流,熔断和降级,今天想继续聊聊削峰填谷,也为后面的高性能篇 做一下铺垫, 想回顾一下之前相关内容的童鞋,可以查看一下,下面文章,欢迎点赞,收藏,关注三连,感谢!

高可用系列文章:

  • 《面试补习》- 你来说说什么是限流?
  • 限流神器Sentinel,不了解一下吗?
  • 阿里P7大佬带你解密Sentinel
  • 《面试补习》-熔断降级我学会了!

削峰和填谷

技术源于生活

  1. 削峰填谷(Peak cut)是调整用电负荷的一种措施。 
  2. 根据不同用户的用电规律,合理地、有计划地安排和组织各类用户的用电时间。 
  3. 以降低负荷高峰,填补负荷低谷。减小电网负荷峰谷差,使发电、用电趋于平衡。 

在我们理解的削峰填谷的流量趋势图,如下图所示,在流量高峰阶段削去高峰流量,在流量下降时,填补这部分流量,使流量趋向平衡。

简单概述一下,削峰 和 填谷

  • 削峰:为保证服务可用,剔除部分流量。 --业务有损
  • 填谷:在服务能力盈余的情况下,提供补偿操作。--业务补偿

削峰

通过削去流量尖刺,让请求流量趋向平稳,以保障服务的稳定性。

  • 客户端削峰
  • 服务端削峰

上面有提到,削峰是业务有损的行为,削掉的这部分流量,可能在电商系统中,致使我们丢失这个用户。

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补习课
相关推荐

2017-04-12 23:50:41

MQ流量缓冲

2017-08-16 16:30:01

CMQ消息实践

2022-02-07 12:10:01

消息

2022-03-07 08:13:06

MQ消息可靠性异步通讯

2024-02-20 08:16:10

阻塞队列源码

2021-05-07 15:28:03

Kafka客户端Sarama

2020-06-12 09:40:32

消息队列Java线程

2023-04-26 09:16:17

2020-07-30 09:00:00

华为

2024-03-22 12:10:39

Redis消息队列数据库

2020-03-12 09:34:05

Redis数据技术

2021-01-20 20:37:09

AI

2022-11-29 07:48:16

2022-08-09 08:31:29

RocketMQ消息中间件

2017-10-11 15:08:28

消息队列常见

2019-05-05 09:24:09

KafkaTopicPartition

2023-11-30 07:43:14

消息队列架构

2022-03-02 07:43:32

JWTJWEJWA

2022-03-15 09:58:12

单例模式系统

2019-09-23 10:47:52

Kafka架构微服务
点赞
收藏

51CTO技术栈公众号