為什麼要限流
日常生活中,有哪些需要限流的地方?
像我旁邊有一個國家AAAA景區,平時可能根本沒什麼人前往,但是一到五一或者春節就人滿為患,這時候景區管理人員就會實行一系列的政策來限制進入人流量,
為什麼要限流呢?假如景區能容納一萬人,現在進去了三萬人,勢必摩肩接踵,整不好還會有事故發生,這樣的結果就是所有人的體驗都不好,如果發生了事故景區可能還要關閉,導致對外不可用,這樣的後果就是所有人都覺得體驗糟糕透了。
限流的思想就是,在保證可用的情況下儘可能多增加進入的人數,其餘的人在外面排隊等待,保證裡面的一萬人可以正常遊玩。
回到網路上,同樣也是這個道理,例如某某明星公佈了戀情,訪問從平時的50萬增加到了500萬,系統最多可以支撐200萬訪問,那麼就要執行限流規則,保證是一個可用的狀態,不至於伺服器崩潰導致所有請求不可用。
限流思路
對系統服務進行限流，一般有如下幾個模式：
熔斷
系統在設計之初就把熔斷措施考慮進去。當系統出現問題時，如果短時間內無法修復，系統要自動做出判斷，開啟熔斷開關，拒絕流量訪問，避免大流量對後端的過載請求。
系統也應該能夠動態監測後端程式的修復情況，當程式已恢復穩定時，可以關閉熔斷開關，恢復正常服務。常見的熔斷元件有Hystrix以及阿里的Sentinel，兩種互有優缺點，可以根據業務的實際情況進行選擇。
服務降級
將系統的所有功能服務進行一個分級，當系統出現問題需要緊急限流時，可將不是那麼重要的功能進行降級處理，停止服務，這樣可以釋放出更多的資源供給核心功能的去用。
例如在電商平臺中，如果突發流量激增，可臨時將商品評論、積分等非核心功能進行降級，停止這些服務，釋放出機器和CPU等資源來保障使用者正常下單，而這些降級的功能服務可以等整個系統恢復正常後，再來啟動，進行補單/補償處理。除了功能降級以外，還可以採用不直接運算元據庫，而全部讀快取、寫快取的方式作為臨時降級方案。
延遲處理
這個模式需要在系統的前端設定一個流量緩衝池，將所有的請求全部緩衝進這個池子，不立即處理。然後後端真正的業務處理程式從這個池子中取出請求依次處理，常見的可以用佇列模式來實現。這就相當於用非同步的方式去減少了後端的處理壓力，但是當流量較大時，後端的處理能力有限，緩衝池裡的請求可能處理不及時，會有一定程度延遲。後面具體的漏桶演算法以及令牌桶演算法就是這個思路。
特權處理
這個模式需要將使用者進行分類，通過預設的分類，讓系統優先處理需要高保障的使用者群體，其它使用者群的請求就會延遲處理或者直接不處理。
快取、降級、限流區別
快取，是用來增加系統吞吐量，提升訪問速度提供高併發。
降級，是在系統某些服務元件不可用的時候、流量暴增、資源耗盡等情況下，暫時遮蔽掉出問題的服務，繼續提供降級服務，給使用者儘可能的友好提示，返回兜底資料，不會影響整體業務流程，待問題解決再重新上線服務
限流，是指在使用快取和降級無效的場景。比如當達到閾值後限制介面呼叫頻率，訪問次數，庫存個數等，在出現服務不可用之前，提前把服務降級。只服務好一部分使用者。
限流的演算法
限流演算法很多,常見的有三類,分別是計數器演算法、漏桶演算法、令牌桶演算法,下面逐一講解。
計數器演算法
簡單粗暴,比如指定執行緒池大小，指定資料庫連線池大小、nginx連線數等,這都屬於計數器演算法。
計數器演算法是限流演算法裡最簡單也是最容易實現的一種演算法。舉個例子,比如我們規定對於A介面，我們1分鐘的訪問次數不能超過100個。那麼我們可以這麼做：在一開 始的時候，我們可以設定一個計數器counter，每當一個請求過來的時候，counter就加1，如果counter的值大於100並且該請求與第一個請求的間隔時間還在1分鐘之內，那麼說明請求數過多,拒絕訪問；如果該請求與第一個請求的間隔時間大於1分鐘，且counter的值還在限流範圍內，那麼就重置 counter,就是這麼簡單粗暴。
漏桶演算法
漏桶演算法思路很簡單，水（請求）先進入到漏桶裡，漏桶以一定的速度出水，當水流入速度過大會超過桶可接納的容量時直接溢位，可以看出漏桶演算法能強行限制資料的傳輸速率。
這樣做的好處是:
削峰:有大量流量進入時,會發生溢位,從而限流保護服務可用
緩衝:不至於直接請求到伺服器,緩衝壓力
消費速度固定 因為計算效能固定
令牌桶演算法
令牌桶與漏桶相似,不同的是令牌桶桶中放了一些令牌,服務請求到達後,要獲取令牌之後才會得到服務,舉個例子,我們平時去食堂吃飯,都是在食堂內視窗前排隊的,這就好比是漏桶演算法,大量的人員聚集在食堂內視窗外,以一定的速度享受服務,如果湧進來的人太多,食堂裝不下了,可能就有一部分人站到食堂外了,這就沒有享受到食堂的服務,稱之為溢位,溢位可以繼續請求,也就是繼續排隊,那麼這樣有什麼問題呢?
如果這時候有特殊情況,比如有些趕時間的志願者啦、或者高三要高考啦,這種情況就是突發情況,如果也用漏桶演算法那也得慢慢排隊,這也就沒有解決我們的需求,對於很多應用場景來說，除了要求能夠限制資料的平均傳輸速率外，還要求允許某種程度的突發傳輸。這時候漏桶演算法可能就不合適了，令牌桶演算法更為適合。如圖所示，令牌桶演算法的原理是系統會以一個恆定的速度往桶裡放入令牌，而如果請求需要被處理，則需要先從桶裡獲取一個令牌，當桶裡沒有令牌可取時，則拒絕服務。
令牌桶好處就是,如果某一瞬間訪問量劇增或者有突發情況,可以通過改變桶中令牌數量來改變連線數,就好比那個食堂排隊吃飯的問題,如果現在不是直接去視窗排隊,而是先來樓外拿飯票然後再去排隊,那麼有高三的學生時可以將增加飯票數量或者優先將令牌給高三的學生,這樣比漏桶演算法更加靈活。
併發限流
簡單來說就是設定系統閾值總的QPS個數,這些也挺常見的,就拿Tomcat來說,很多引數就是出於這個考慮,例如
配置的acceptCount 設定響應連線數, maxConnections設定瞬時最大連線數, maxThreads 設定最大執行緒數,在各個框架或者元件中,併發限流體現在下面幾個方面:
- 限制總併發數（如資料庫連線池、執行緒池）
- 限制瞬時併發數（nginx的limit_conn模組，用來限制瞬時併發連線數）
- 限制時間視窗內的平均速率（如Guava的RateLimiter、nginx的limit_req模組，限制每秒的平均速率）
- 其他的還有限制遠端介面呼叫速率、限制MQ的消費速率。
- 另外還可以根據網路連線數、網路流量、CPU或記憶體負載等來限流。
有了併發限流，就意味著在處理高併發的時候多了一種保護機制，不用擔心瞬間流量導致系統掛掉或雪崩，最終做到有損服務而不是不服務；但是限流需要評估好，不能亂用，否則一些正常流量出現一些奇怪的問題而導致使用者體驗很差造成使用者流失。
介面限流
介面限流分為兩個部分,一是限制一段時間內介面呼叫次數,參照前面限流演算法的計數器演算法, 二是設定滑動時間視窗演算法。
介面總數
控制一段時間內介面被呼叫的總數量,可以參考前面的計數器演算法,不再贅述。
介面時間視窗
固定時間視窗演算法(也就是前面提到的計數器演算法)的問題是統計區間太大，限流不夠精確，而且在第二個統計區間 時沒有考慮與前一個統計區間的關係與影響（第一個區間後半段 + 第二個區間前半段也是一分鐘）。為了解決上面我們提到的臨界問題，我們試圖把每個統計區間分為更小的統計區間，更精確的統計計數。
在上面的例子中,假設QPS可以接受100次查詢/秒, 前一分鐘前40秒訪問很低,後20秒突增,並且這個持續了一段時間,直到第二分鐘的第40秒才開始降下來,根據前面的計數方法,前一秒的QPS為94,後一秒的QPS為92,那麼沒有超過設定引數,但是!但是在中間區域,QPS達到了142,這明顯超過了我們的允許的服務請求數目,所以固定視窗計數器不太可靠,需要滑動視窗計數器。
計數器演算法其實就是固定視窗演算法, 只是它沒有對時間視窗做進一步地劃分，所以只有1格；由此可見，當滑動視窗的格子劃分的越多，也就是將秒精確到毫秒或者納秒, 那麼滑動視窗的滾動就越平滑，限流的統計就會越精確。
需要注意的是,消耗的空間就越多。
限流實現
這一部分是限流的具體實現,簡單說說,畢竟長篇程式碼沒人願意看。
guava實現
引入包
<!-- https://mvnrepository.com/artifact/com.google.guava/guava -->
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>28.1-jre</version>
</dependency>
核心程式碼
LoadingCache<Long, AtomicLong> counter = CacheBuilder.newBuilder().
expireAfterWrite(2, TimeUnit.SECONDS)
.build(new CacheLoader<Long, AtomicLong>() {
@Override
public AtomicLong load(Long secend) throws Exception {
// TODO Auto-generated method stub
return new AtomicLong(0);
}
});
counter.get(1l).incrementAndGet();
令牌桶實現
穩定模式(SmoothBursty:令牌生成速度恆定)
public static void main(String[] args) {
// RateLimiter.create(2)每秒產生的令牌數
RateLimiter limiter = RateLimiter.create(2);
// limiter.acquire() 阻塞的方式獲取令牌
System.out.println(limiter.acquire());;
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println(limiter.acquire());;
System.out.println(limiter.acquire());;
System.out.println(limiter.acquire());;
System.out.println(limiter.acquire());;
System.out.println(limiter.acquire());;
System.out.println(limiter.acquire());;
}
```RateLimiter.create(2)`` 容量和突發量，令牌桶演算法允許將一段時間內沒有消費的令牌暫存到令牌桶中，用來突發消費。
漸進模式(SmoothWarmingUp:令牌生成速度緩慢提升直到維持在一個穩定值)
// 平滑限流，從冷啟動速率（滿的）到平均消費速率的時間間隔
RateLimiter limiter = RateLimiter.create(2,1000l,TimeUnit.MILLISECONDS);
System.out.println(limiter.acquire());;
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println(limiter.acquire());;
System.out.println(limiter.acquire());;
System.out.println(limiter.acquire());;
System.out.println(limiter.acquire());;
System.out.println(limiter.acquire());;
System.out.println(limiter.acquire());;
超時
boolean tryAcquire = limiter.tryAcquire(Duration.ofMillis(11));
在timeout時間內是否能夠獲得令牌，非同步執行
分散式系統限流
Nginx + Lua實現
可以使用resty.lock保持原子特性，請求之間不會產生鎖的重入
https://github.com/openresty/lua-resty-lock
使用lua_shared_dict儲存資料
local locks = require "resty.lock"
local function acquire()
local lock =locks:new("locks")
local elapsed, err =lock:lock("limit_key") --互斥鎖 保證原子特性
local limit_counter =ngx.shared.limit_counter --計數器
local key = "ip:" ..os.time()
local limit = 5 --限流大小
local current =limit_counter:get(key)
if current ~= nil and current + 1> limit then --如果超出限流大小
lock:unlock()
return 0
end
if current == nil then
limit_counter:set(key, 1, 1) --第一次需要設定過期時間，設定key的值為1，
--過期時間為1秒
else
limit_counter:incr(key, 1) --第二次開始加1即可
end
lock:unlock()
return 1
end
ngx.print(acquire())