[[415619]]

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

概述

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

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

高可用系列文章：

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

削峰和填谷

技術(shù)源于生活

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

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

簡(jiǎn)單概述一下，削峰 和 填谷

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

削峰

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

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

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

1、客戶端削峰

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

1.1、資源動(dòng)靜分離

這個(gè)方案比較簡(jiǎn)單，或者說(shuō)目前基本都采用的方式。通過(guò)將靜態(tài)資源與服務(wù)端隔離，在活動(dòng)開(kāi)始前，將資源預(yù)熱到CDN，減輕服務(wù)端的壓力?？蛻舳伺c服務(wù)端的交互，只有動(dòng)態(tài)數(shù)據(jù)的交互。

1.2、請(qǐng)求削峰

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

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

2)、公平性策略

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

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

2、服務(wù)端削峰

2.1、限流削峰

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

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

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

2.2、MQ削峰

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

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

假設(shè)秒殺系統(tǒng)的 流量是 ：10000 qps，訂單系統(tǒng)的消費(fèi)能力只有 100qps?；顒?dòng)時(shí)間如果持續(xù)比較長(zhǎng)，會(huì)產(chǎn)生消息堆積過(guò)多。一方面會(huì)對(duì)消息中間件造成壓力，另一方面，消息的有效性也沒(méi)辦法保障。

因此在這個(gè)鏈路圖中，實(shí)際場(chǎng)景會(huì)是這樣子：

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

填谷

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

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

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

如有其他場(chǎng)景，可以交流糾正

填谷補(bǔ)償

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

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

• 產(chǎn)生請(qǐng)求為：60 * 100 = 6000 個(gè)請(qǐng)求。
• 消費(fèi)時(shí)間為：6000 / 50 = 120 秒。

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

消息隊(duì)列的風(fēng)險(xiǎn)

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

每個(gè)方案都存在利弊，引入 MQ，能為我們解決 削峰，異步和解耦等問(wèn)題。但是，在引入MQ中間件的同時(shí)，也會(huì)為我們帶來(lái)以下的問(wèn)題：

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