前面學習過的熔斷和降級都是通過暫時關閉某些非核心服務或者元件來保護核心系統的可用性。但是並不是所有的場景下都可以使用熔斷降級的策略，例如當核心服務產生比較大的影響時，總不能把核心服務進行熔斷與降級，些時一般採用限流方案來進行保護。
限流指的是通過限制到達系統的併發請求數量，保證系統能夠正常響應部分使用者請求，而對於超過限制的流量，則只能通過拒絕服務的方式保證整體系統的可用性。限流策略一般部署在服務的入口層，比如 api 閘道器中。
現實中可以在多個維度上對到達系統的流量做控制，例如：
你可以對系統每分鐘處理多少請求做出限制；
可以針對單個介面設定每分鐘請求流量的限制；
可以限制單個 ip、使用者 id 或者裝置 id在一段時間內傳送請求的數量；
限制速率的方式是基於一些限流演算法的，那麼常見的限流的演算法有以下幾種：
漏桶演算法：在流量產生端和接收端之間增加乙個漏桶，流量會進入和暫存到漏桶裡面，而漏桶的出口處會按照乙個固定的速率將流量漏出到接收端。經過了漏桶演算法之後，隨機產生的流量就會成為比較平滑的流量到達服務端，從而避免了突發的大流量對於服務介面的影響。
令牌桶演算法：如果我們需要在一秒內限制訪問次數為 n 次，那麼就每隔 1/n 的時間，往桶內放入乙個令牌；在處理請求之前先要從桶中獲得乙個令牌，如果桶中已經沒有了令牌，那麼就需要等待新的令牌或者直接拒絕服務；桶中的令牌總數也要有乙個限制，如果超過了限制就不能向桶中再增加新的令牌了。這樣可以限制令牌的總數，一定程度上可以避免瞬時流量高峰的問題。
漏桶演算法在面對突發流量的時候，採用的解決方式是快取在漏桶中，會增長響應時間，這與網際網路業務低延遲的要求不符；而令牌桶演算法可以在令牌中暫存一定量的令牌，能夠應對一定的突發流量，一般我會使用令牌桶演算法來實現限流方案。
限流策略是微服務治理中的標配策略，只是你很難在實際中確認限流的閾值是多少，設定的小了容易誤傷正常的請求，設定的大了則達不到限流的目的。一般通過定期的壓力測試得到整體系統以及每個微服務的實際承載能力，然後再依據這個壓測出來的值設定合適的閾值。並結合配置中心中來實現動態調整。
高併發限流演算法
目錄開篇 限流演算法 1.漏桶 leaky bucket 2.令牌桶 token bucket 資料流漏桶演算法和令牌桶演算法的比較 參考資料 在高併發系統中，有很多手段來保護系統，如快取 降級和限流等。快取 讓資料盡早進入快取，離程式近一點，不要大量頻繁的訪問db，可提供系統訪問速度和增大系統處理...
Java高併發系統的限流策略
在大資料量高併發訪問時，經常會出現服務或介面面對暴漲的請求而不可用的情況，甚至引發連鎖反映導致整個系統崩潰。此時你需要使用的技術手段之一就是限流，當請求達到一定的併發數或速率，就進行等待 排隊 降級 拒絕服務等。在開發高併發系統時有三把利器用來保護系統 快取 降級和限流。快取比較好理解，在大型高併發...
高併發系統設計
高併發系統主要是為了解決在有限的資源下解決最核心的問題，並發現以後可能會出現的問題。高併發原則一般遵守如下幾個設計原則 1.無狀態 指的是應用在處理業務邏輯期間盡量減少鎖的使用 降低網路通訊延遲 無資料持久化操作等，以此來增加應用系統的效能。2.拆分 大而全的系統，可根據實際的訪問量來拆分系統，來實...