目錄
一 什麼是限流
二 為什麼需要限流
三 那些場景需要用到限流
3.1 對外服務
3.2 對內服務
四 限流演算法
4.1 計數器演算法
4.2 漏桶演算法
4.3 令牌桶演算法
限流其實是指當系統資源不夠，不足以應對大量請求，即系統資源與訪問量出現矛盾的時候，我們為了保證有限的資源能夠正常服務，因此對系統按照預設的規則進行流量限制或功能限制的一種方法。
一旦流量過大，為了保證服務可用，所以需要限流。
這些情況都是無法預知的，不知道什麼時候會有10倍甚至20倍的流量打進來，如果真碰上這種情況，擴容是根本來不及的。所以需要限流。
對內的中颱服務 z 被各種服務 g、h、p、b 共同呼叫，一旦 g 出現流量陡增的情況，很容易將中颱服務 z 打掛。所以中臺服務 z 需要對呼叫方進行限流。
採用計數器實現限流有點簡單粗暴，一般我們會限制一秒鐘的能夠通過的請求數，比如限流 qps 為100，演算法的實現思路就是從第乙個請求進來開始計時，在接下去的1s內，每來乙個請求，就把計數加1，如果累加的數字達到了100，那麼後續的請求就會被全部拒絕。等到1s結束後，把計數恢復成0，重新開始計數。
具體的實現可以是這樣的：對於每次服務呼叫，可以通過atomiclong#incrementandget()方法來給計數器加1並返回最新值，通過這個最新值和閾值進行比較。
漏桶演算法的原理比較簡單，水（請求）先進入到漏桶裡，人為設定乙個最大出水速率，漏桶以<=最大出水速率的速度出水，當水流入速度過大會直接溢位（拒絕服務）：
因此，這個演算法的核心為：
因此這是一種強行限制請求速率的方式，但是缺點非常明顯，主要有兩點：
所以，通常來說利用漏桶演算法來限流，實際場景下用得不多。
令牌桶演算法是網路流量整形（traffic shaping）和限流（rate limiting）中最常使用的一種演算法，它可用於控制傳送到網路上資料的數量並允許突發資料的傳送。
從某種意義上來說，令牌桶演算法是對漏桶演算法的一種改進，主要在於令牌桶演算法能夠在限制呼叫的平均速率的同時還允許一定程度的突發呼叫，來看下令牌桶演算法的實現原理：
整個的過程是這樣的：
那麼，我們再看一下，為什麼令牌桶演算法可以防止一定程度的突發流量呢？可以這麼理解，假設我們想要的速率是1000qps，那麼往桶中放令牌的速度就是1000個/s，假設第1秒只有800個請求，那意味著第2秒可以容許1200個請求，這就是一定程度突發流量的意思，反之我們看漏桶演算法，第一秒只有800個請求，那麼全部放過，第二秒這1200個請求將會被打回200個。
注意上面多次提到一定程度這四個字，這也是我認為令牌桶演算法最需要注意的乙個點。假設還是1000qps的速率，那麼5秒鐘放1000個令牌，第1秒鐘800個請求過來，第2~4秒沒有請求，那麼按照令牌桶演算法，第5秒鐘可以接受4200個請求，但是實際上這已經遠遠超出了系統的承載能力，因此使用令牌桶演算法特別注意設定桶中令牌的上限即可。
總而言之，作為對漏桶演算法的改進，令牌桶演算法在限流場景下被使用更加廣泛。
服務限流演算法
業務 中的邏輯限流 按照服務的呼叫方，可以分為以下幾種型別服務 1 與使用者打交道的服務 比如web服務 對外api，這種型別的服務有以下幾種可能導致機器被拖垮 2 對內的rpc服務 乙個服務a的介面可能被bcde多個服務進行呼叫，在b服務發生突發流量時，直接把a服務給呼叫掛了，導致a服務對cde也...
Redis 限流演算法
判斷有限時間內的數量是否超過限制上線 date default timezone set prc class limitelse elseelse else 有問題，併發上來，一直就允許5個，但是利用 pipeline 保證了各個client之間的原子性 function isactionallow...
幾種限流演算法
思路很簡單，請求先進入到漏桶裡，漏桶以固定的速度出水，也就是處理請求，當水加的過快，則會直接溢位，也就是拒絕請求，可以看出漏桶演算法能強行限制資料的傳輸速率。但是對於很多場景來說，除了要求能夠限制資料的平均傳輸速率外，還要求允許某種程度的突發傳輸。這時候漏桶演算法可能就不合適了，令牌桶演算法更為適合...