偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

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

開發(fā) 前端
在后端的思維里面,削峰動作更多是服務(wù)端同學(xué)的工作和思考。但是在整體系統(tǒng)的設(shè)計中,客戶端的削峰也是必不可少的。通過客戶端的削峰,可以削減服務(wù)端的壓力,從而保障系統(tǒng)的可用性。

[[415619]]

本文轉(zhuǎn)載自微信公眾號「Java補(bǔ)習(xí)課」,作者九靈。轉(zhuǎn)載本文請聯(lián)系Java補(bǔ)習(xí)課公眾號。

概述

日常分享Java核心技術(shù),分布式架構(gòu)原理,中間件應(yīng)用與原理等高質(zhì)量原創(chuàng)文章。致力幫助更多小朋友加入大廠!

今天想和大家聊聊削峰填谷,最近 B 站發(fā)生的機(jī)房斷電事件,和A站的服務(wù)雪崩,讓我們對高可用關(guān)注了起來,之前梳理了高可用三劍客 限流,熔斷和降級,今天想繼續(xù)聊聊削峰填谷,也為后面的高性能篇 做一下鋪墊, 想回顧一下之前相關(guān)內(nèi)容的童鞋,可以查看一下,下面文章,歡迎點贊,收藏,關(guān)注三連,感謝!

高可用系列文章:

  • 《面試補(bǔ)習(xí)》- 你來說說什么是限流?
  • 限流神器Sentinel,不了解一下嗎?
  • 阿里P7大佬帶你解密Sentinel
  • 《面試補(bǔ)習(xí)》-熔斷降級我學(xué)會了!

削峰和填谷

技術(shù)源于生活

  1. 削峰填谷(Peak cut)是調(diào)整用電負(fù)荷的一種措施。 
  2. 根據(jù)不同用戶的用電規(guī)律,合理地、有計劃地安排和組織各類用戶的用電時間。 
  3. 以降低負(fù)荷高峰,填補(bǔ)負(fù)荷低谷。減小電網(wǎng)負(fù)荷峰谷差,使發(fā)電、用電趨于平衡。 

在我們理解的削峰填谷的流量趨勢圖,如下圖所示,在流量高峰階段削去高峰流量,在流量下降時,填補(bǔ)這部分流量,使流量趨向平衡。

簡單概述一下,削峰 和 填谷

  • 削峰:為保證服務(wù)可用,剔除部分流量。 --業(yè)務(wù)有損
  • 填谷:在服務(wù)能力盈余的情況下,提供補(bǔ)償操作。--業(yè)務(wù)補(bǔ)償

削峰

通過削去流量尖刺,讓請求流量趨向平穩(wěn),以保障服務(wù)的穩(wěn)定性。

  • 客戶端削峰
  • 服務(wù)端削峰

上面有提到,削峰是業(yè)務(wù)有損的行為,削掉的這部分流量,可能在電商系統(tǒng)中,致使我們丟失這個用戶。

1、客戶端削峰

在后端的思維里面,削峰動作更多是服務(wù)端同學(xué)的工作和思考。但是在整體系統(tǒng)的設(shè)計中,客戶端的削峰也是必不可少的。通過客戶端的削峰,可以削減服務(wù)端的壓力,從而保障系統(tǒng)的可用性。

1.1、資源動靜分離

這個方案比較簡單,或者說目前基本都采用的方式。通過將靜態(tài)資源與服務(wù)端隔離,在活動開始前,將資源預(yù)熱到CDN,減輕服務(wù)端的壓力。客戶端與服務(wù)端的交互,只有動態(tài)數(shù)據(jù)的交互。

1.2、請求削峰

1)、設(shè)置兩次請求最小有效時間間隔

設(shè)置兩次請求之間的時間間隔為 t, 在每次請求間隔內(nèi)的請求,都會被忽略掉,不向服務(wù)的發(fā)起請求,假設(shè) t 秒內(nèi),每個用戶只會觸發(fā)一次有效請求,對應(yīng)的 qps 為 1/t,如果用戶量為 Q, 那么最大的 qps 為 Q / t。

2)、公平性策略

每個用戶一次活動周期內(nèi)有效請求概率是P,比如概率0.2,也就是5次中1次請求機(jī)會,或者10次中2次請求機(jī)會。根據(jù)隨機(jī)算法+插值算法生成請求序列:

根據(jù)上述方式就可以得到公平性策略,粒度可以自由把控

2、服務(wù)端削峰

2.1、限流削峰

在之前的限流相關(guān)文章中有介紹到,服務(wù)端限流主要有

  • 網(wǎng)關(guān)限流
  • 容器限流
  • 服務(wù)器限流

在服務(wù)器限流中, 主要介紹了,使用Sentinel 來做流量控制,通過下面的流量圖可以看到,流量控制在了 2 qps ,峰值流量通過快速失敗的方式返回。那么,對于這部分被拒絕的流量,我們從業(yè)務(wù)角度來看的話,是有損的。

2.2、MQ削峰

在消息隊列的架構(gòu)中,有 pull 和 push 兩種消息同步的方式,我們可以通過下游系統(tǒng) 訂單系統(tǒng) 主動拉取pull 的方式,來保障下游服務(wù)的流量穩(wěn)定。

那么,我們是否可以脫了了限流,只通過 MQ 的方式,來達(dá)到削峰呢?答案是:不能!

假設(shè)秒殺系統(tǒng)的 流量是 :10000 qps,訂單系統(tǒng)的消費能力只有 100qps?;顒訒r間如果持續(xù)比較長,會產(chǎn)生消息堆積過多。一方面會對消息中間件造成壓力,另一方面,消息的有效性也沒辦法保障。

因此在這個鏈路圖中,實際場景會是這樣子:

流量先經(jīng)過 Sentinel等限流中間件的調(diào)平后,由秒殺系統(tǒng)提交 MQ 任務(wù)。

填谷

從上面的削峰策略可以看到,大部分的削峰 都是業(yè)務(wù)有損的,從客戶端發(fā)起請求限流 ,到服務(wù)端的中間件限流。對于這部分的請求,都是直接丟棄的。而在 MQ削峰 的場景下,我們可以通過將請求緩存 的方式,減緩流量壓力,有下游服務(wù)來控制請求壓力,從而達(dá)到削峰的效果。

脫離了削峰,就不存在填谷了

在 MQ削峰 的場景中,我們主要保障的是 訂單系統(tǒng) 的流量穩(wěn)定性, 如果 秒殺系統(tǒng)的消息流量為 100tps,訂單系統(tǒng)的處理能力為 200tps,那么,對于下游系統(tǒng)來說,就不存在峰值流量了!

如有其他場景,可以交流糾正

填谷補(bǔ)償

在峰值流量階段,出現(xiàn)部分流量無法得到馬上的處理,通過峰值流量過去后,在消費能力盈余的情況下,對之前的請求做補(bǔ)償操作,使整體流量趨向于平穩(wěn)。

比如在上述鏈路圖中,秒殺活動持續(xù)了 1分鐘,

  • 產(chǎn)生請求為:60 * 100 = 6000 個請求。
  • 消費時間為:6000 / 50 = 120 秒。

在用戶可接受的范圍內(nèi)(1分鐘的等待),獲取自己的秒殺下單結(jié)果。同時對訂單系統(tǒng)的負(fù)載做好保護(hù)。

消息隊列的風(fēng)險

相對于其他的削峰方案,看起來MQ削峰方案是最優(yōu)的,那為什么我們在 流控方案上,還是更加注重限流方案上。而不是統(tǒng)一使用 MQ削峰呢?

每個方案都存在利弊,引入 MQ,能為我們解決 削峰,異步和解耦等問題。但是,在引入MQ中間件的同時,也會為我們帶來以下的問題:

  • 中間件可用性:MQ隊列不可用,會導(dǎo)致整個鏈路不可用,嚴(yán)重會造成雪崩
  • 消息可靠性:消息發(fā)送,消費需要得到保障
  • 消息堆積:消息生產(chǎn)過快,導(dǎo)致MQ中間件壓力過大
  • 消息重復(fù):消費冪等能力支撐
  • 消息順序:部分場景要求消費按照順序執(zhí)行

 

 

責(zé)任編輯:武曉燕 來源: Java補(bǔ)習(xí)課
相關(guān)推薦

2017-04-12 23:50:41

MQ流量緩沖

2017-08-16 16:30:01

CMQ消息實踐

2025-01-20 07:00:00

2025-03-27 03:40:00

分布式系統(tǒng)Kafka

2022-02-07 12:10:01

消息

2024-06-14 15:46:46

2024-09-18 07:00:00

消息隊列中間件消息隊列

2022-03-07 08:13:06

MQ消息可靠性異步通訊

2021-05-07 15:28:03

Kafka客戶端Sarama

2023-04-26 09:16:17

2024-02-20 08:16:10

阻塞隊列源碼

2020-06-12 09:40:32

消息隊列Java線程

2020-07-30 09:00:00

華為

2021-01-20 20:37:09

AI

2024-03-22 12:10:39

Redis消息隊列數(shù)據(jù)庫

2020-03-12 09:34:05

Redis數(shù)據(jù)技術(shù)

2022-03-15 09:58:12

單例模式系統(tǒng)

2022-08-09 08:31:29

RocketMQ消息中間件

2022-11-29 07:48:16

2019-05-05 09:24:09

KafkaTopicPartition
點贊
收藏

51CTO技術(shù)棧公眾號