流量治理神器-Sentinel的限流模式，選單機(jī)還是集群？
點(diǎn)擊上方藍(lán)字“設(shè)為星標(biāo)”
大家好，架構(gòu)擺渡人。這是我的第5篇原創(chuàng)文章，還請(qǐng)多多支持。
?
上篇文章給大家推薦了一些限流的框架，如果說硬要我推薦一款，我會(huì)推薦Sentinel，Sentinel的限流模式分為兩種，分別是單機(jī)模式和集群模式。今天我們就來學(xué)習(xí)下這兩種模式的區(qū)別和使用場(chǎng)景。
?
單機(jī)流控
單機(jī)流控就是流控的效果只針對(duì)服務(wù)的一個(gè)實(shí)例，比如你的服務(wù)部署了三個(gè)實(shí)例分別在三臺(tái)機(jī)器上。請(qǐng)求訪問到了A實(shí)例的時(shí)候，如果觸發(fā)了流控，那么只會(huì)限制A實(shí)例后面的請(qǐng)求，不會(huì)影響其他實(shí)例上的請(qǐng)求。
?
?
比如你單身的時(shí)候，每月的工資都花個(gè)精光。影響的只是你自己，跟別人沒關(guān)系，因?yàn)槟惚緛砭褪且粋€(gè)人生活，單身跟單機(jī)就強(qiáng)行關(guān)聯(lián)在一起了。
?
單機(jī)流控相對(duì)來說比較簡單，不依賴中心化的存儲(chǔ)。每個(gè)服務(wù)內(nèi)部只需要記錄自身的一些訪問信息即可判斷出是否需要流控操作。
?
像Guava的RateLimiter就是典型的單機(jī)流控模式，將令牌數(shù)據(jù)全部存儲(chǔ)在本地內(nèi)存中，不需要有集中式的存儲(chǔ)，不需要跟其他服務(wù)交互，自身就能完成流控功能。
?
集群流控
集群流控
集群流控就是流控的效果針對(duì)整個(gè)集群，也就是服務(wù)的所有的實(shí)例，比如你的服務(wù)部署了三個(gè)實(shí)例分別在三臺(tái)機(jī)器上?？傮w限流QPS為100，請(qǐng)求訪問到了A實(shí)例的時(shí)候，如果觸發(fā)了流控，那么此時(shí)其他的請(qǐng)求到B實(shí)例的時(shí)候，也會(huì)觸發(fā)流控。
?
?
比如你結(jié)婚后，你和你老婆的工資是你們整個(gè)家庭的總收入。你每天出去玩，到處亂花錢，把錢花完了，你老婆想買衣服的時(shí)候，就被流控了，因?yàn)闆]錢了，這就是集群流控的含義。
使用場(chǎng)景對(duì)比
?
單機(jī)流控更適合作為兜底保護(hù)的一種方式，比如我們單機(jī)限流總的請(qǐng)求量為2000，如果超過2000開始限流，這樣就能保證當(dāng)前服務(wù)在可承受的范圍內(nèi)進(jìn)行處理。
?
如果我們用的是集群限流，假設(shè)當(dāng)前集群內(nèi)有10個(gè)節(jié)點(diǎn)，如果每個(gè)節(jié)點(diǎn)能承受2000的請(qǐng)求，那么加起來就是2萬的請(qǐng)求。也就是說只要不超過2萬個(gè)請(qǐng)求都不會(huì)觸發(fā)限流。如果我們的負(fù)載均衡策略是輪詢的話沒什么問題，請(qǐng)求分布到各個(gè)節(jié)點(diǎn)上都比較均勻。但是如果負(fù)載均衡策略不是輪詢，如果是隨機(jī)的話，那么請(qǐng)求很有可能在某個(gè)節(jié)點(diǎn)上超過2000，這個(gè)時(shí)候其實(shí)這個(gè)節(jié)點(diǎn)是處理不了那么多請(qǐng)求的，最終會(huì)被拖垮，造成連鎖反應(yīng)。
?
比如我們的需求是限制總的請(qǐng)求次數(shù)為2000，如果是單機(jī)流控，那么也就是每個(gè)節(jié)點(diǎn)超過200就開始限流。還是前面的問題，如果請(qǐng)求分配不均勻的話，其實(shí)整體總量還沒達(dá)到2000，但是某一個(gè)節(jié)點(diǎn)超過了200，就開始限流了，對(duì)用戶體驗(yàn)不是很好。
?
所以集群限流適合用在有整體總量限制的場(chǎng)景，比如開放平臺(tái)的API調(diào)用。
?
Sentinel集群流控
Sentinel里面集群限流有兩種身份：
?
Token Client：集群流控客戶端，會(huì)向 Token Server 請(qǐng)求 token。集群限流服務(wù)端會(huì)返回結(jié)果，告訴客戶端是否限流。
?
Token Server：集群流控服務(wù)端，處理來自 Token Client 的請(qǐng)求，根據(jù)配置的集群規(guī)則判斷是否應(yīng)該允許通過。
?
在部署方面也分為兩種形式：
?
首先來看下獨(dú)立部署的架構(gòu)圖，此圖來自Sentinel文檔：
?
?
就是單獨(dú)部署一個(gè)Token Server，通過這個(gè)獨(dú)立的Token Server來存儲(chǔ)所有資源的訪問數(shù)據(jù)，然后再根據(jù)配置的規(guī)則決定某個(gè)資源能否放行，是否需要執(zhí)行限流操作。
?
因?yàn)榧毫骺乇仨氁幸粋€(gè)中心去存儲(chǔ)數(shù)據(jù)，所以也必須單獨(dú)部署Token Server，單獨(dú)部署隔離性好，但是整體架構(gòu)的復(fù)雜度上去了。
?
另外還有一個(gè)必須要考慮的問題就是Token Server的高可用性。如果當(dāng)前的Token Server掛掉了，需要有另一個(gè)節(jié)點(diǎn)立馬接替，其實(shí)就是需要實(shí)現(xiàn)一個(gè)選舉的功能。
?
如果Token Server部署多個(gè)節(jié)點(diǎn)，也給這些節(jié)點(diǎn)劃分主，從的區(qū)別，實(shí)現(xiàn)了故障選舉的邏輯。但還有另外一個(gè)問題需要考慮，就是節(jié)點(diǎn)之前的數(shù)據(jù)需要同步吧，不然故障切換后，新上任的節(jié)點(diǎn)沒有之前的數(shù)據(jù)，就只能從零開始了。
?
數(shù)據(jù)同步如果用AP的形式，那么可以參考Eureka的雙向同步機(jī)制。一但發(fā)生故障切換，還是會(huì)有極小的概念丟失數(shù)據(jù)，因?yàn)椴皇菑?qiáng)一致性。
?
如果用CP的形式，那么可以參考Zookeeper里的數(shù)據(jù)一致性保證方式。
首先來看下嵌入式部署的架構(gòu)圖，此圖來自Sentinel文檔：
?
?
嵌入式部署跟獨(dú)立部署的區(qū)別在于可以不用單獨(dú)部署Token Server，而且將Token Server跟應(yīng)用融合在一起，所以叫內(nèi)嵌式。
?
嵌入式部署如果是Token Server的那個(gè)應(yīng)用實(shí)例掛了，我們可以通過API將另一個(gè)應(yīng)用切換成Token Server，但是這個(gè)動(dòng)作一定要做成自動(dòng)的，手動(dòng)的就比較LOW。
?
另外不足的就是隔離性不好，雖然架構(gòu)簡單。Token Server和應(yīng)用耦合在一起，如果此時(shí)應(yīng)用的QPS很高，則勢(shì)必會(huì)影響Token Server，反之也是一樣。
?
總結(jié)
最后，做個(gè)總結(jié)吧！集群流控能夠精確地控制整個(gè)集群的 QPS，結(jié)合單機(jī)限流兜底，可以更好地發(fā)揮流量控制的效果。
?
集群模式有一定的適用場(chǎng)景，同時(shí)采用集群模式對(duì)整個(gè)架構(gòu)的復(fù)雜度也會(huì)提高，所以如果沒有特別復(fù)雜的場(chǎng)景，建議大家直接用單機(jī)模式就行了，限流的閥值配置少一點(diǎn)，在壓測(cè)極限的70%即可。
?
大家好，我是從古代穿越過來的美男子：架構(gòu)擺渡人。我將把我的武功秘籍全部傳授與你們，覺得有用請(qǐng)分享給身邊的朋友。來個(gè)三連吧，感謝各位！另外我還在B站錄制了《真實(shí)訂單業(yè)務(wù)，億級(jí)數(shù)據(jù)帶你實(shí)戰(zhàn)分庫分表》的實(shí)戰(zhàn)課程，記得去學(xué)習(xí)哦！
點(diǎn)擊閱讀原文直達(dá)主頁