大家好，架構擺渡人。這是我的第5篇原創文章，還請多多支援。
上篇文章給大家推薦了一些限流的框架，如果說硬要我推薦一款，我會推薦Sentinel，Sentinel的限流模式分為兩種，分別是單機模式和叢集模式。今天我們就來學習下這兩種模式的區別和使用場景。
單機流控
單機流控就是流控的效果只針對服務的一個例項，比如你的服務部署了三個例項分別在三臺機器上。請求訪問到了A例項的時候，如果觸發了流控，那麼只會限制A例項後面的請求，不會影響其他例項上的請求。
比如你單身的時候，每月的工資都花個精光。影響的只是你自己，跟別人沒關係，因為你本來就是一個人生活，單身跟單機就強行關聯在一起了。
單機流控相對來說比較簡單，不依賴中心化的儲存。每個服務內部只需要記錄自身的一些訪問資訊即可判斷出是否需要流控操作。
像Guava的RateLimiter就是典型的單機流控模式，將令牌資料全部儲存在本地記憶體中，不需要有集中式的儲存，不需要跟其他服務互動，自身就能完成流控功能。
叢集流控
叢集流控就是流控的效果針對整個叢集，也就是服務的所有的例項，比如你的服務部署了三個例項分別在三臺機器上。總體限流QPS為100，請求訪問到了A例項的時候，如果觸發了流控，那麼此時其他的請求到B例項的時候，也會觸發流控。
比如你結婚後，你和你老婆的工資是你們整個家庭的總收入。你每天出去玩，到處亂花錢，把錢花完了，你老婆想買衣服的時候，就被流控了，因為沒錢了，這就是叢集流控的含義。
使用場景對比
保護層面對比
單機流控更適合作為兜底保護的一種方式，比如我們單機限流總的請求量為2000，如果超過2000開始限流，這樣就能保證當前服務在可承受的範圍內進行處理。
如果我們用的是叢集限流，假設當前叢集內有10個節點，如果每個節點能承受2000的請求，那麼加起來就是2萬的請求。也就是說只要不超過2萬個請求都不會觸發限流。如果我們的負載均衡策略是輪詢的話沒什麼問題，請求分佈到各個節點上都比較均勻。但是如果負載均衡策略不是輪詢，如果是隨機的話，那麼請求很有可能在某個節點上超過2000，這個時候其實這個節點是處理不了那麼多請求的，最終會被拖垮，造成連鎖反應。
準確度對比
比如我們的需求是限制總的請求次數為2000，如果是單機流控，那麼也就是每個節點超過200就開始限流。還是前面的問題，如果請求分配不均勻的話，其實整體總量還沒達到2000，但是某一個節點超過了200，就開始限流了，對使用者體驗不是很好。
所以叢集限流適合用在有整體總量限制的場景，比如開放平臺的API呼叫。
Sentinel叢集流控
Sentinel裡面叢集限流有兩種身份：
Token Client：叢集流控客戶端，會向 Token Server 請求 token。叢集限流服務端會返回結果，告訴客戶端是否限流。
Token Server：叢集流控服務端，處理來自 Token Client 的請求，根據配置的叢集規則判斷是否應該允許通過。
在部署方面也分為兩種形式：
獨立部署
首先來看下獨立部署的架構圖，此圖來自Sentinel文件：
就是單獨部署一個Token Server，通過這個獨立的Token Server來儲存所有資源的訪問資料，然後再根據配置的規則決定某個資源能否放行，是否需要執行限流操作。
因為叢集流控必須要有一箇中心去儲存資料，所以也必須單獨部署Token Server，單獨部署隔離性好，但是整體架構的複雜度上去了。
另外還有一個必須要考慮的問題就是Token Server的高可用性。如果當前的Token Server掛掉了，需要有另一個節點立馬接替，其實就是需要實現一個選舉的功能。
如果Token Server部署多個節點，也給這些節點劃分主，從的區別，實現了故障選舉的邏輯。但還有另外一個問題需要考慮，就是節點之前的資料需要同步吧，不然故障切換後，新上任的節點沒有之前的資料，就只能從零開始了。
資料同步如果用AP的形式，那麼可以參考Eureka的雙向同步機制。一但發生故障切換，還是會有極小的概念丟失資料，因為不是強一致性。
如果用CP的形式，那麼可以參考Zookeeper裡的資料一致性保證方式。
嵌入式部署
首先來看下嵌入式部署的架構圖，此圖來自Sentinel文件：
嵌入式部署跟獨立部署的區別在於可以不用單獨部署Token Server，而且將Token Server跟應用融合在一起，所以叫內嵌式。
嵌入式部署如果是Token Server的那個應用例項掛了，我們可以通過API將另一個應用切換成Token Server，但是這個動作一定要做成自動的，手動的就比較LOW。
另外不足的就是隔離性不好，雖然架構簡單。Token Server和應用耦合在一起，如果此時應用的QPS很高，則勢必會影響Token Server，反之也是一樣。
總結
最後，做個總結吧！叢集流控能夠精確地控制整個叢集的 QPS，結合單機限流兜底，可以更好地發揮流量控制的效果。
叢集模式有一定的適用場景，同時採用叢集模式對整個架構的複雜度也會提高，所以如果沒有特別複雜的場景，建議大家直接用單機模式就行了，限流的閥值配置少一點，在壓測極限的70%即可。
大家好，我是從古代穿越過來的美男子：架構擺渡人。我將把我的武功祕籍全部傳授與你們，覺得有用請分享給身邊的朋友。來個三連吧，感謝各位！