關于兩種限流模式

流量預警和限流方案中，比較常用的有兩種。第一種滑窗模式，通過統計多個單元時間的訪問次數來進行控制，當單位時間的訪問次數達到的某個峰值時進行限流。第二種為響應模式，通過控制當前活躍請求數，來進行流量控制。下面來簡單分析下兩種的優缺點。

1、滑窗模式

模式分析:

在每次有訪問進來時，我們判斷前N個單位時間里總訪問量是否超過了設置的閾值，若超過則不允許執行。

這種模式的實現的方式更加契合流控的本質意義。理解較為簡單。但由于訪問量的預先不可預見性，會發生單位時間的前半段有大量的請求涌入，而后半段則拒絕所有請求的情況發生。（一般，需要會將單位時間切的足夠的細來解決這個問題）其次，我們很難確定這個閾值設置在多少比較合適，只能通過經驗或者模擬（如壓測）來進行估計，不過即使是壓測也很難估計的準確，線上每臺機器的硬件參數的不同，或者同一臺機子在不同的時間點其可以接受的閾值也不盡相同（系統中），每個時間點導致能夠承受的最大閾值也不盡相同，我們無法考慮的周全。

所以滑窗模式往往用來對某一資源的保護上（或者說是承諾比較合適：我對某一接口的提供者承諾過，最高調用量不超過XX），如對db的保護，對某一服務的調用的控制上。因為對于我們應用來說，db或某一接口就是一共單一的整體。

代碼實現思路：

每一個窗（單位時間）就是一個獨立的計數器（原子計數器），用以數組保存。將當前時間以某種方式（比如取模）映射到數組的一項中。每次訪問先對當前窗內計數器+1，再計算前N個單元格的訪問量綜合，超過閾值則限流。

這里有個問題，時間永遠是遞增的，單純的取模，會導致數組過長，使用內存過多，我們可以用環形隊列來解決這個問題。

2、響應模式

模式分析：

每次操作執行時，我們通過判斷當前正在執行的訪問數是否超過某個閾值在決定是否限流。

該模式看著思路比較的另類，但卻有其獨到之處。實際上我們限流的根本是為了保護資源，防止系統接受的請求過多，應接不暇，拖慢系統中其他接口的服務，造成雪崩。也就是說我們真正需要關心的是那些運行中的請求，而那些已經完成的請求已是過去時，不再是需要關心的了。

我們來看看其閾值的計算方式，對于一個請求來說，響應時間rt/qps是一個比較容易獲取的參數，那么我們這樣計算：qps/1000*rt。

此外，一個應用往往是個復雜的系統，提供的服務或者暴露的請求、資源不止一個。內部GC、定時任務的執行、其他服務訪問的驟增，外部依賴方、db的抖動，抑或是代碼中不經意間的一個bug。都可能導致相應時間的變化，導致系統同時可以執行請求的變化。而這種模式，則能恰如其分的自動做出調整，當系統不適時，rt增加時，會自動的對qps做出適應。

代碼實現思路:

當訪問開始時，我們對當前計數器（原子計數器）+1，當完成時，-1。該計數器即為當前正在執行的請求數。只需判斷這個計數器是否超過閾值即可。