什麼是服務限流

讓我們先看一看系統架構設計中，為什麼要做“限流”。

旅遊景點通常都會有最大的接待量，不可能無限制的放遊客進入，比如故宮每天只賣八萬張票，超過八萬的遊客，無法買票進入，因為如果超過八萬人，景點的工作人員可能就忙不過來，過於擁擠的景點也會影響遊客的體驗和心情，並且還會有安全隱患；只賣N張票，這就是一種限流的手段。

軟體架構中的服務限流也是類似，也是當系統資源不夠的時候，已經不足以應對大量的請求，為了保證服務還能夠正常執行，那麼按照規則，系統會把多餘的請求直接拒絕掉，以達到限流的效果；

不知道大家注意過沒有，比如雙11，剛過12點有些顧客的網頁或APP會顯示下單失敗的提示，有些就是被限流調了。

計數器法：原理就是限制每秒處理請求數不超過閾值。比如一個介面一分鐘可以處理1000次請求，那麼可以設定一個計數器，當有一次請求過來，計數器就加1，如果一分鐘以內計數器超過了1000，那麼後面再過來的請求就不再處理；但是這個方法的缺點也很明顯，因為請求的訪問不一定是很平穩的，如果0:59過來了1000個請求，1:01已經是下一個視窗，又過來了1000個請求，但實際上三秒內來了2000個請求，已經超過我們的限流上限了；

滑動視窗：還拿上面的例子，一分鐘分6份，每份10秒；每過10秒鐘，我們的時間視窗就會往右滑動一格，每個格子都有獨立的計數器，我們每次都計算時間視窗內的數量，可以解決計數器法中的問題，而且當滑動視窗的格子越多，那麼限流的統計就會越精確。具體可以參考下圖，看圖比較清晰：

漏桶演算法：這個演算法也很簡單，就是我們有一個固定容量的桶，有水流進來，也有水流出去，我們不需要控制流進來的速度，只需要控制流出去的速度，如果水流進來的太快，桶滿了，多餘的水會溢位區，並不會影響水流出去的速度。

令牌桶演算法：還是有一個桶，桶裡面有N個令牌，所有的請求在處理之前都需要拿到一個可用的令牌才會被處理，如果桶裡面沒有令牌的話，則拒絕服務；令牌桶演算法的原理是系統會以一個恆定的速度往桶裡放入令牌。