概述
今天想和大家聊聊削峰填谷，最近 B 站發生的機房斷電事件，和A站的服務雪崩，讓我們對高可用關注了起來，之前梳理了高可用三劍客 限流，熔斷和降級，今天想繼續聊聊削峰填谷,也為後面的高效能篇 做一下鋪墊， 想回顧一下之前相關內容的童鞋,可以檢視一下，下面文章，歡迎點贊，收藏，關注三連，感謝！
高可用系列文章：
削峰和填谷
技術源於生活
削峰填谷（Peak cut）是調整用電負荷的一種措施。
根據不同使用者的用電規律，合理地、有計劃地安排和組織各類使用者的用電時間。
以降低負荷高峰，填補負荷低谷。減小電網負荷峰谷差，使發電、用電趨於平衡。
在我們理解的削峰填谷的流量趨勢圖，如下圖所示，在流量高峰階段削去高峰流量，在流量下降時，填補這部分流量,使流量趨向平衡。
簡單概述一下，削峰 和 填谷
- 削峰： 為保證服務可用，剔除部分流量。 --業務有損
- 填谷： 在服務能力盈餘的情況下，提供補償操作。 --業務補償
削峰
通過削去流量尖刺，讓請求流量趨向平穩，以保障服務的穩定性。
- 客戶端削峰
- 服務端削峰
上面有提到，削峰是業務有損的行為，削掉的這部分流量，可能在電商系統中，致使我們丟失這個使用者。
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 補習課，掌握第一手資料！ 如果本篇部落格有任何錯誤，請批評指教，不勝感激 ！