大家好，架構擺渡人。這是我的第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%即可。
大家好，我是從古代穿越過來的美男子：架構擺渡人。我將把我的武功秘籍全部傳授與你們，覺得有用請分享給身邊的朋友。來個三連吧，感謝各位！