java高并發(fā)場景下的限流策略是什么

為什么需要限流

         

舉個比較簡單的例子，正常來說，一個員工A他每天能夠處理的工作是10個，突然某一天來了100個工作量，這時候，如果員工A還處理100個，只有一種可能，這個員工被壓垮。

如果我們能預(yù)先知道會有100個任務(wù)會來，我們通過增加員工數(shù)或定義消息隊列等等來臨時解決。

但是我們很多時候無法預(yù)料這些意外的。根據(jù)墨菲定律，壞事往往會接踵而來，有可能某個點掛了會引起全局的掛掉（雪崩）。因此我們不得不對我們的系統(tǒng)做一些保護措施。限流是其中之一。

針對秒殺這類場景，我們也可以做一些限流措施，而不影響到系統(tǒng)全局。

         

限流方式之計數(shù)器(滑動窗口協(xié)議)

         

思路：限速，我們可能第一個想到的應(yīng)該是，我通過一個計數(shù)器，進行技術(shù)，如果超過了計數(shù)器閥值，表示速度太快了。一秒一個計數(shù)器。

 

為了便于閱讀，我只截圖了主要的代碼片段。

 

這樣有個問題就是：粒度太大了，不均勻，針對1秒以下的，沒法辨析。

我們能不能把粒度拆細了，1秒拆成10個100毫秒。每一個100毫秒有一個計數(shù)器。了解TCP/IP的應(yīng)該知道，TCP/IP為了增加傳輸速度和控制傳輸速度，有個叫“滑動窗口協(xié)議”。

就算拆得再細，也無法解決勻速限制速度的問題。

而且還有個臨界點問題，假如，一秒限制10個請求，在第1秒和第2秒之間，第1秒后半段時間10個請求，第2秒前半段10個請求，那第1秒后半段+第2秒前半段時間組成的一秒鐘里就有20個請求，沒有起到限速的作用。

有沒有更好的辦法呢？

         

限速方式之漏桶算法

         

在生活中，如果一桶有一個細眼，我們往里面裝水，可以看到水是一滴一滴勻速的下落的，哪我們能不能通過程序來實現(xiàn)這種方式呢。

思路：桶為容器，一滴水為一請求。如果桶滿了就拒絕請求，沒滿處理請求。

 

代碼片段

 

• 首先計算這次請求與上次請求來的時候，總共漏了多少水。

• 看一下桶里面還剩多少水，有沒有溢出。

• 如果溢出了拒絕請求，如果沒有添加當(dāng)前一滴水。處理請求。

對于很多應(yīng)用場景來說，除了要求能夠限制數(shù)據(jù)的平均傳輸速率外，還要求允許某種程度的突發(fā)傳輸。這時候漏桶算法可能就不合適了，令牌桶算法更為適合。

什么意思呢？就是說我服務(wù)前面閑了很久，突然來了很多請求（在桶的容量內(nèi)），我得快速的把這些處理了。

         

限速方式之令牌桶算法

         

思路：勻速的產(chǎn)生令牌，往桶里面丟，每次請求來，看是否有多余的令牌。如果有獲取令牌執(zhí)行正常業(yè)務(wù)，偌沒有限速。

 

代碼片段

 

• 請求來的時候先計算目前放入桶中的令牌數(shù)，這里計算，就可以不用啟動一個線程勻速放置令牌了，這個叫惰性計算。

• 然后計算桶擁有的令牌數(shù)。然后獲取令牌。做拒絕還是處理動作。

以上代碼，可在Github查看。
https://github.com/hirudy/java_lib/tree/master/src/main/java/com/hirudy/limiter 

         

單機限速器RateLimiter

         

安利大家一個高效的限速器。

google的基礎(chǔ)庫guava中包含了一個基于令牌桶的限速器RateLimiter。使用也很簡單。

 到此，相信大家對“java高并發(fā)場景下的限流策略是什么”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！