流量治理神器-Sentinel的限流模式，選單機還是集群？
點擊上方“服務端思維”，選擇“設為星標”
回復”669“獲取獨家整理的精選資料集
回復”加群“加入全國服務端高端社群「后端圈」
上篇文章給大家推薦了一些限流的框架，如果說硬要我推薦一款，我會推薦Sentinel，Sentinel的限流模式分為兩種，分別是單機模式和集群模式。今天我們就來學習下這兩種模式的區(qū)別和使用場景。
?
單機流控
單機流控就是流控的效果只針對服務的一個實例，比如你的服務部署了三個實例分別在三臺機器上。請求訪問到了A實例的時候，如果觸發(fā)了流控，那么只會限制A實例后面的請求，不會影響其他實例上的請求。
?
?
比如你單身的時候，每月的工資都花個精光。影響的只是你自己，跟別人沒關系，因為你本來就是一個人生活，單身跟單機就強行關聯(lián)在一起了。
?
單機流控相對來說比較簡單，不依賴中心化的存儲。每個服務內(nèi)部只需要記錄自身的一些訪問信息即可判斷出是否需要流控操作。
?
像Guava的RateLimiter就是典型的單機流控模式，將令牌數(shù)據(jù)全部存儲在本地內(nèi)存中，不需要有集中式的存儲，不需要跟其他服務交互，自身就能完成流控功能。
?
集群流控
集群流控
集群流控就是流控的效果針對整個集群，也就是服務的所有的實例，比如你的服務部署了三個實例分別在三臺機器上?？傮w限流QPS為100，請求訪問到了A實例的時候，如果觸發(fā)了流控，那么此時其他的請求到B實例的時候，也會觸發(fā)流控。
?
?
比如你結(jié)婚后，你和你老婆的工資是你們整個家庭的總收入。你每天出去玩，到處亂花錢，把錢花完了，你老婆想買衣服的時候，就被流控了，因為沒錢了，這就是集群流控的含義。
使用場景對比
?
單機流控更適合作為兜底保護的一種方式，比如我們單機限流總的請求量為2000，如果超過2000開始限流，這樣就能保證當前服務在可承受的范圍內(nèi)進行處理。
?
如果我們用的是集群限流，假設當前集群內(nèi)有10個節(jié)點，如果每個節(jié)點能承受2000的請求，那么加起來就是2萬的請求。也就是說只要不超過2萬個請求都不會觸發(fā)限流。如果我們的負載均衡策略是輪詢的話沒什么問題，請求分布到各個節(jié)點上都比較均勻。但是如果負載均衡策略不是輪詢，如果是隨機的話，那么請求很有可能在某個節(jié)點上超過2000，這個時候其實這個節(jié)點是處理不了那么多請求的，最終會被拖垮，造成連鎖反應。
?
比如我們的需求是限制總的請求次數(shù)為2000，如果是單機流控，那么也就是每個節(jié)點超過200就開始限流。還是前面的問題，如果請求分配不均勻的話，其實整體總量還沒達到2000，但是某一個節(jié)點超過了200，就開始限流了，對用戶體驗不是很好。
?
所以集群限流適合用在有整體總量限制的場景，比如開放平臺的API調(diào)用。
?
Sentinel集群流控
Sentinel里面集群限流有兩種身份：
?
Token Client：集群流控客戶端，會向 Token Server 請求 token。集群限流服務端會返回結(jié)果，告訴客戶端是否限流。
?
Token Server：集群流控服務端，處理來自 Token Client 的請求，根據(jù)配置的集群規(guī)則判斷是否應該允許通過。
?
在部署方面也分為兩種形式：
?
首先來看下獨立部署的架構(gòu)圖，此圖來自Sentinel文檔：
?
?
就是單獨部署一個Token Server，通過這個獨立的Token Server來存儲所有資源的訪問數(shù)據(jù)，然后再根據(jù)配置的規(guī)則決定某個資源能否放行，是否需要執(zhí)行限流操作。
?
因為集群流控必須要有一個中心去存儲數(shù)據(jù)，所以也必須單獨部署Token Server，單獨部署隔離性好，但是整體架構(gòu)的復雜度上去了。
?
另外還有一個必須要考慮的問題就是Token Server的高可用性。如果當前的Token Server掛掉了，需要有另一個節(jié)點立馬接替，其實就是需要實現(xiàn)一個選舉的功能。
?
如果Token Server部署多個節(jié)點，也給這些節(jié)點劃分主，從的區(qū)別，實現(xiàn)了故障選舉的邏輯。但還有另外一個問題需要考慮，就是節(jié)點之前的數(shù)據(jù)需要同步吧，不然故障切換后，新上任的節(jié)點沒有之前的數(shù)據(jù)，就只能從零開始了。
?
數(shù)據(jù)同步如果用AP的形式，那么可以參考Eureka的雙向同步機制。一但發(fā)生故障切換，還是會有極小的概念丟失數(shù)據(jù)，因為不是強一致性。
?
如果用CP的形式，那么可以參考Zookeeper里的數(shù)據(jù)一致性保證方式。
首先來看下嵌入式部署的架構(gòu)圖，此圖來自Sentinel文檔：
?
?
嵌入式部署跟獨立部署的區(qū)別在于可以不用單獨部署Token Server，而且將Token Server跟應用融合在一起，所以叫內(nèi)嵌式。
?
嵌入式部署如果是Token Server的那個應用實例掛了，我們可以通過API將另一個應用切換成Token Server，但是這個動作一定要做成自動的，手動的就比較LOW。
?
另外不足的就是隔離性不好，雖然架構(gòu)簡單。Token Server和應用耦合在一起，如果此時應用的QPS很高，則勢必會影響Token Server，反之也是一樣。
?
總結(jié)
最后，做個總結(jié)吧！集群流控能夠精確地控制整個集群的 QPS，結(jié)合單機限流兜底，可以更好地發(fā)揮流量控制的效果。
?
集群模式有一定的適用場景，同時采用集群模式對整個架構(gòu)的復雜度也會提高，所以如果沒有特別復雜的場景，建議大家直接用單機模式就行了，限流的閥值配置少一點，在壓測極限的70%即可。
— 本文結(jié)束 —
關注我，回復 「加群」 加入各種主題討論群。
對「服務端思維」有期待，請在文末點個在看
喜歡這篇文章，歡迎轉(zhuǎn)發(fā)、分享朋友圈
