流量削峰的由來(lái)

主要是還是來(lái)自于互聯(lián)網(wǎng)的業(yè)務(wù)場(chǎng)景，例如，馬上即將開(kāi)始的春節(jié)火車票搶購(gòu)，大量的用戶需要同一時(shí)間去搶購(gòu)；以及大家熟知的阿里雙11秒殺， 短時(shí)間上億的用戶涌入，瞬間流量巨大（高并發(fā)），比如：200萬(wàn)人準(zhǔn)備在凌晨12:00準(zhǔn)備搶購(gòu)一件商品，但是商品的數(shù)量缺是有限的100-500件左右。

這樣真實(shí)能購(gòu)買到該件商品的用戶也只有幾百人左右， 但是從業(yè)務(wù)上來(lái)說(shuō)，秒殺活動(dòng)是希望更多的人來(lái)參與，也就是搶購(gòu)之前希望有越來(lái)越多的人來(lái)看購(gòu)買商品。

但是，在搶購(gòu)時(shí)間達(dá)到后，用戶開(kāi)始真正下單時(shí)，秒殺的服務(wù)器后端缺不希望同時(shí)有幾百萬(wàn)人同時(shí)發(fā)起搶購(gòu)請(qǐng)求。

我們都知道服務(wù)器的處理資源是有限的，所以出現(xiàn)峰值的時(shí)候，很容易導(dǎo)致服務(wù)器宕機(jī)，用戶無(wú)法訪問(wèn)的情況出現(xiàn)。

這就好比出行的時(shí)候存在早高峰和晚高峰的問(wèn)題，為了解決這個(gè)問(wèn)題，出行就有了錯(cuò)峰限行的解決方案。

同理，在線上的秒殺等業(yè)務(wù)場(chǎng)景，也需要類似的解決方案，需要平安度過(guò)同時(shí)搶購(gòu)帶來(lái)的流量峰值的問(wèn)題，這就是流量削峰的由來(lái)。

怎樣來(lái)實(shí)現(xiàn)流量削峰方案

削峰從本質(zhì)上來(lái)說(shuō)就是更多地延緩用戶請(qǐng)求，以及層層過(guò)濾用戶的訪問(wèn)需求，遵從“最后落地到數(shù)據(jù)庫(kù)的請(qǐng)求數(shù)要盡量少”的原則。

1.消息隊(duì)列解決削峰

要對(duì)流量進(jìn)行削峰，最容易想到的解決方案就是用消息隊(duì)列來(lái)緩沖瞬時(shí)流量，把同步的直接調(diào)用轉(zhuǎn)換成異步的間接推送，中間通過(guò)一個(gè)隊(duì)列在一端承接瞬時(shí)的流量洪峰，在另一端平滑地將消息推送出去。

消息隊(duì)列中間件主要解決應(yīng)用耦合，異步消息， 流量削鋒等問(wèn)題。常用消息隊(duì)列系統(tǒng)：目前在生產(chǎn)環(huán)境，使用較多的消息隊(duì)列有 ActiveMQ、RabbitMQ、 ZeroMQ、Kafka、MetaMQ、RocketMQ 等。

在這里，消息隊(duì)列就像“水庫(kù)”一樣，攔蓄上游的洪水，削減進(jìn)入下游河道的洪峰流量，從而達(dá)到減免洪水災(zāi)害的目的。

具體的消息隊(duì)列MQ選型和應(yīng)用場(chǎng)景可以參考我的往期文章：《高并發(fā)架構(gòu)系列：詳解分布式之消息隊(duì)列的特點(diǎn)、選型、及應(yīng)用場(chǎng)景》

2.流量削峰漏斗：層層削峰

針對(duì)秒殺場(chǎng)景還有一種方法，就是對(duì)請(qǐng)求進(jìn)行分層過(guò)濾，從而過(guò)濾掉一些無(wú)效的請(qǐng)求。

分層過(guò)濾其實(shí)就是采用“漏斗”式設(shè)計(jì)來(lái)處理請(qǐng)求的，如下圖所示：

這樣就像漏斗一樣，盡量把數(shù)據(jù)量和請(qǐng)求量一層一層地過(guò)濾和減少了。

1）分層過(guò)濾的核心思想

通過(guò)在不同的層次盡可能地過(guò)濾掉無(wú)效請(qǐng)求。

通過(guò)CDN過(guò)濾掉大量的圖片，靜態(tài)資源的請(qǐng)求。

再通過(guò)類似Redis這樣的分布式緩存，過(guò)濾請(qǐng)求等就是典型的在上游攔截讀請(qǐng)求。

2）分層過(guò)濾的基本原則

對(duì)寫(xiě)數(shù)據(jù)進(jìn)行基于時(shí)間的合理分片，過(guò)濾掉過(guò)期的失效請(qǐng)求。

對(duì)寫(xiě)請(qǐng)求做限流保護(hù)，將超出系統(tǒng)承載能力的請(qǐng)求過(guò)濾掉。

涉及到的讀數(shù)據(jù)不做強(qiáng)一致性校驗(yàn)，減少因?yàn)橐恢滦孕ｒ?yàn)產(chǎn)生瓶頸的問(wèn)題。

對(duì)寫(xiě)數(shù)據(jù)進(jìn)行強(qiáng)一致性校驗(yàn)，只保留最后有效的數(shù)據(jù)。

最終，讓“漏斗”最末端(數(shù)據(jù)庫(kù))的才是有效請(qǐng)求。例如：當(dāng)用戶真實(shí)達(dá)到訂單和支付的流程，這個(gè)是需要數(shù)據(jù)強(qiáng)一致性的。

總結(jié)

1.對(duì)于秒殺這樣的高并發(fā)場(chǎng)景業(yè)務(wù)，最基本的原則就是將請(qǐng)求攔截在系統(tǒng)上游，降低下游壓力。如果不在前端攔截很可能造成數(shù)據(jù)庫(kù)(mysql、oracle等)讀寫(xiě)鎖沖突，甚至導(dǎo)致死鎖，最終還有可能出現(xiàn)雪崩等場(chǎng)景。

2.劃分好動(dòng)靜資源，靜態(tài)資源使用CDN進(jìn)行服務(wù)分發(fā)。

3.充分利用緩存(redis等)：增加QPS，從而加大整個(gè)集群的吞吐量。

4.高峰值流量是壓垮系統(tǒng)很重要的原因，所以需要Kafka等消息隊(duì)列在一端承接瞬時(shí)的流量洪峰，在另一端平滑地將消息推送出去。

以上是就是流量削峰的詳解。

覺(jué)得不錯(cuò)請(qǐng)點(diǎn)贊支持，歡迎留言或進(jìn)我的個(gè)人群179961551領(lǐng)取【架構(gòu)資料專題目合集90期】、【BATJTMD大廠JAVA面試真題1000+】，本群專用于學(xué)習(xí)交流技術(shù)、分享面試機(jī)會(huì)，拒絕廣告，我也會(huì)在群內(nèi)不定期答題、探討。