什麼是限流？
限流可以認為服務降級的一種，限流就是限制系統的輸入和輸出流量已達到保護系統的目的。一般來說系統的吞吐量是可以被測算的，為了保證系統的穩定運行，一旦達到的需要限制的閾值，就需要限制流量並採取一些措施以完成限制流量的目的。比如：延遲處理，拒絕處理，或者部分拒絕處理等等。
坐地鐵上班的同學對於這張圖片是不是都不會陌生。
基本上在上下班的早晚高峰我們就會發現進站的閘機會有一部分是關閉的。為什麼地鐵站會關閉一部分閘機呢？這就是為了限流。畢竟地鐵站就那麼大，可容納的人數也就那麼多。如果大家一股腦全部擠進地鐵站是不是又會發生踩踏事件什麼的。這是生活中的限流。還有我們去景區玩，景區的門票是不是也是固定的，每天就賣那麼多張，賣完即止。限流是不是和我們的生活也息息相關。
為什麼要限流？
開篇也有說到限流是為了保證系統的穩定運行。假設我們一個系統一小時之最多隻能處理10000個請求，但是一小時流量突增10倍，這突增的流量我們如果不進行限制的話，任由它直接進入系統的話，是不是直接會把我們的系統弄癱瘓，就無法對外提供服務了。本人就曾經被這個所坑過，有一次把爬蟲開關攔截的開關給關掉了，突然有一大波的爬蟲流量進入系統中，我們也沒有把這些爬蟲請求進行攔截，然後一股腦的全部給轉發到下游系統裡面去了。下游系統直接就找上門來了，造成他們的服務發生大量的超時。比如地鐵早高峰的時候我們如果不對地鐵站進行限流的話，大家是不是都會往地鐵站擠，然後再往地鐵裡面擠，擠不上都還要擠。會導致地鐵門都關不上，然後地鐵就開不走，會導致越來越多的人堵在地鐵站。然後最後就會導致整條地鐵線都阻塞了。上班就妥妥的遲到了（對於程序員說大多數應該是彈性制的所以也不存在遲到這一說法）。
限流操作有哪些？
拒絕服務
這個是最最簡單粗暴的做法了，直接把請求直接拒絕掉。
比如早高峰坐地鐵的時候，直接讓進入1000個人，剩下多出來的人不讓坐地鐵了。直接把入站口給關閉了。
服務降級
將系統的所有功能服務進行一個分級，當系統出現問題，需要緊急限流時，可將不是那麼重要的功能進行降級處理，停止服務，這樣可以釋放出更多的資源供給核心功能的去用。
假設有一個功能新用戶註冊完，要給用戶發送多少優惠券。這時候服務降級的話就可以直接把送券服務關掉，讓服務快速響應，提高系統處理能力。
應用到早高峰坐地鐵的時候比如在人民廣場這個大站點，處理不過來了那麼多人換乘，我們是不是可以直接地鐵一號線在人民廣場不停，直接到下一站在停，這時候經過人民廣場換乘的人就少了。
延遲處理
把請求全部放入到隊列中，真正處理的話，就從隊列裡面依次去取，這樣的話流量比較大的情況可能會導致處理不及時，會有一定的延時。雙十一零點我們付款的時候，去查詢訂單的狀態是不是也會有一定的延時，不像在平時付完款訂單狀態就變成了付款狀態。
特權處理
這個模式需要將用戶進行分類，通過預設的分類，讓系統優先處理需要高保障的用戶群體，其它用戶群的請求就會延遲處理或者直接不處理。我們去銀行辦理業務的時候是不是也會經常需要排隊，但是是不是經常會VIP用戶、什麼白金卡用戶，直接不需要排隊，直接一上來就可以辦理業務，還優先處理這些人的業務。是不是特羨慕這些人,哎 羨慕也沒辦法誰叫人家有錢咧。
限流的實現方式？
計數器方法
這是最簡單的限流算法了，系統裡面維護一個計數器，來一個請求就加1，請求處理完成就減1，當計數器大於指定的閾值，就拒絕新的請求。是通過全局的總求數於設置的閾值來達到限流的目的。通常應用在池化技術上面比如：數據庫連接池、線程池等中應用。這種方式的話限流不是平均速率的。扛不住突增的流量。
漏桶算法
我們可以看到水是可以持續流入漏桶裡面的，底部也是勻速的流出，如果流入的速率大於底部流出的速率，以及漏桶的水超過桶的大小就會發生益出。請求一經過漏桶的過濾，不管你請求有多少，速率有多快，我反正就這麼個速度處理。我們平時坐地鐵的時候是不是也是這樣，不管你乘客有多少，反正就是隔5min發一趟車。那早高峰的時候你5min鍾一趟車根本就不夠用啊，上班的人太多啊，你需要加快速度處理啊，所以可能早高峰改為3min一趟，動態調整速率。
令牌桶
看圖的話是不是令牌桶和漏桶都差不多，只不過令牌桶新增了一個勻速生產令牌的中間人以恆定的速度往桶裡面放令牌，如果令牌的數量超過裡桶的限制的話，令牌就會溢出，這時候就直接捨棄多餘的令牌。每個請求過來必須拿到桶裡面拿到了令牌才允許請求（拿令牌的速度是不限制的，這就意味著如果瞬間有大量的流量請求進來，可以短時間內拿到大量的令牌），拿不到令牌的話直接拒絕。這個令牌桶的思想是不是跟我們java裡面的Semaphore 有點類似。Semaphore 是拿信號量，用完了就還回去。但是令牌桶的話，不需要還回去，因為令牌會定時的補充。令牌桶算法我們可以通過Google開源的guava包創建一個令牌桶算法的限流器。
總結
- 以上粗略的介紹了幾種單機的限流思想，大家可以根據這個思想然後去實現各種各樣的限流組件。
- 我們的限流算法每個裡面是不是都一個閾值，這個閾值設置為多少是不是比較難。
閾值設置過大的話，服務可能扛不住，閾值設置小了會把用戶請求給誤殺，資源沒有得到最大的一個利用。
- 分佈式限流的話，以後有機會再講。
結束
- 由於自己才疏學淺，難免會有紕漏，假如你發現了錯誤的地方，還望留言給我指出來,我會對其加以修正。
- 如果你覺得文章還不錯，你的轉發、分享、讚賞、點贊、留言就是對我最大的鼓勵。
- 感謝您的閱讀,十分歡迎並感謝您的關注。
