流量削峰的由來
主要是還是來自于互聯(lián)網(wǎng)的業(yè)務(wù)場景辱匿，例如，馬上即將開始的春節(jié)火車票搶購炫彩，大量的用戶需要同一時間去搶購匾七；以及大家熟知的阿里雙11秒殺， 短時間上億的用戶涌入江兢，瞬間流量巨大（高并發(fā)）昨忆，比如：200萬人準備在凌晨12:00準備搶購一件商品，但是商品的數(shù)量缺是有限的100-500件左右杉允。
這樣真實能購買到該件商品的用戶也只有幾百人左右邑贴， 但是從業(yè)務(wù)上來說席里，秒殺活動是希望更多的人來參與，也就是搶購之前希望有越來越多的人來看購買商品拢驾。
但是奖磁，在搶購時間達到后，用戶開始真正下單時繁疤，秒殺的服務(wù)器后端缺不希望同時有幾百萬人同時發(fā)起搶購請求署穗。
我們都知道服務(wù)器的處理資源是有限的，所以出現(xiàn)峰值的時候嵌洼，很容易導(dǎo)致服務(wù)器宕機案疲，用戶無法訪問的情況出現(xiàn)。
這就好比出行的時候存在早高峰和晚高峰的問題麻养，為了解決這個問題褐啡，出行就有了錯峰限行的解決方案。
同理鳖昌，在線上的秒殺等業(yè)務(wù)場景备畦，也需要類似的解決方案，需要平安度過同時搶購帶來的流量峰值的問題许昨，這就是流量削峰的由來懂盐。
怎樣來實現(xiàn)流量削峰方案
削峰從本質(zhì)上來說就是更多地延緩用戶請求，以及層層過濾用戶的訪問需求糕档，遵從“最后落地到數(shù)據(jù)庫的請求數(shù)要盡量少”的原則莉恼。
1.消息隊列解決削峰
要對流量進行削峰，最容易想到的解決方案就是用消息隊列來緩沖瞬時流量速那，把同步的直接調(diào)用轉(zhuǎn)換成異步的間接推送俐银，中間通過一個隊列在一端承接瞬時的流量洪峰，在另一端平滑地將消息推送出去端仰。
消息隊列中間件主要解決應(yīng)用耦合捶惜，異步消息， 流量削鋒等問題荔烧。常用消息隊列系統(tǒng)：目前在生產(chǎn)環(huán)境吱七，使用較多的消息隊列有 ActiveMQ、RabbitMQ鹤竭、 ZeroMQ踊餐、Kafka、MetaMQ诺擅、RocketMQ 等市袖。
在這里，消息隊列就像“水庫”一樣，攔蓄上游的洪水苍碟，削減進入下游河道的洪峰流量酒觅，從而達到減免洪水災(zāi)害的目的。
具體的消息隊列MQ選型和應(yīng)用場景可以參考我的往期文章：《高并發(fā)架構(gòu)系列：詳解分布式之消息隊列的特點微峰、選型舷丹、及應(yīng)用場景》
2.流量削峰漏斗：層層削峰
針對秒殺場景還有一種方法，就是對請求進行分層過濾蜓肆，從而過濾掉一些無效的請求颜凯。
分層過濾其實就是采用“漏斗”式設(shè)計來處理請求的，如下圖所示：
這樣就像漏斗一樣仗扬，盡量把數(shù)據(jù)量和請求量一層一層地過濾和減少了症概。
1）分層過濾的核心思想
通過在不同的層次盡可能地過濾掉無效請求。
通過CDN過濾掉大量的圖片早芭，靜態(tài)資源的請求彼城。
再通過類似Redis這樣的分布式緩存，過濾請求等就是典型的在上游攔截讀請求退个。
2）分層過濾的基本原則
對寫數(shù)據(jù)進行基于時間的合理分片募壕，過濾掉過期的失效請求。
對寫請求做限流保護语盈，將超出系統(tǒng)承載能力的請求過濾掉舱馅。
涉及到的讀數(shù)據(jù)不做強一致性校驗，減少因為一致性校驗產(chǎn)生瓶頸的問題刀荒。
對寫數(shù)據(jù)進行強一致性校驗代嗤，只保留最后有效的數(shù)據(jù)。
最終照棋，讓“漏斗”最末端(數(shù)據(jù)庫)的才是有效請求资溃。例如：當用戶真實達到訂單和支付的流程武翎，這個是需要數(shù)據(jù)強一致性的烈炭。
總結(jié)
1.對于秒殺這樣的高并發(fā)場景業(yè)務(wù)，最基本的原則就是將請求攔截在系統(tǒng)上游宝恶，降低下游壓力符隙。如果不在前端攔截很可能造成數(shù)據(jù)庫(mysql、oracle等)讀寫鎖沖突垫毙，甚至導(dǎo)致死鎖霹疫，最終還有可能出現(xiàn)雪崩等場景。
2.劃分好動靜資源综芥，靜態(tài)資源使用CDN進行服務(wù)分發(fā)丽蝎。
3.充分利用緩存(redis等)：增加QPS，從而加大整個集群的吞吐量。
4.高峰值流量是壓垮系統(tǒng)很重要的原因屠阻，所以需要Kafka等消息隊列在一端承接瞬時的流量洪峰红省，在另一端平滑地將消息推送出去。
以上是就是流量削峰的詳解国觉。
覺得不錯請點贊支持吧恃，歡迎留言或進我的個人群179961551領(lǐng)取【架構(gòu)資料專題目合集90期】、【BATJTMD大廠JAVA面試真題1000+】麻诀，本群專用于學習交流技術(shù)痕寓、分享面試機會，拒絕廣告蝇闭，我也會在群內(nèi)不定期答題呻率、探討。
