限流可以認(rèn)為是一種降級(jí)，一般是根據(jù)后臺(tái)的負(fù)載提前預(yù)估的一個(gè)閾值(也可以動(dòng)態(tài)調(diào)整)。超過了這個(gè)值，就要進(jìn)行一些旁路處理。根據(jù)業(yè)務(wù)形態(tài)，會(huì)有直接拒絕、延遲處理、保持等待、部分穿透、默認(rèn)返回等響應(yīng)方式。

concurrent包中的信號(hào)量，由于使用簡單，易于理解，被廣泛應(yīng)用。但是，你要是直接用了網(wǎng)友們分享的簡單代碼而不經(jīng)過認(rèn)真測試，那可以送你一部電影觀賞一下：《當(dāng)故障來敲門》。

看下面簡單的代碼，acquire和release是一對(duì)同命鴛鴦，我們把release貼心的放在了finally塊中，一切顯得非常和諧。

1)模擬的業(yè)務(wù)請(qǐng)求，耗時(shí)大約是100毫秒

2)acquire的參數(shù)5代表同一時(shí)間允許5個(gè)線程進(jìn)行處理

3)每次執(zhí)行完畢，輸出一下本次執(zhí)行的具體耗時(shí)，加上等待時(shí)間

我們啟動(dòng)1000個(gè)線程去執(zhí)行req方法。

SemaphoreLimiterBadChecker limiter = new SemaphoreLimiterBadChecker(); 
ExecutorService executor = Executors.newCachedThreadPool(); 
for (int i = 0; i < 1000; i++) { 
    executor.submit(() -> { 
        while (true) { 
            System.out.println(limiter.req()); 
        } 
    }); 
} 

下面是執(zhí)行結(jié)果。

可以看到，雖然我們的接口耗時(shí)只有100ms，實(shí)際的執(zhí)行時(shí)間，卻長的多，而且并沒有出現(xiàn)fail的情況。運(yùn)行稍長一點(diǎn)時(shí)間，能夠發(fā)現(xiàn)有大量的線程處于餓死的狀態(tài)。改為公平鎖并不能改善這一情況。

這就是故障。

原因就在于。web端(如tomcat)的資源也是有限的。當(dāng)我們的限流器產(chǎn)生了作用，而實(shí)際并發(fā)請(qǐng)求比處理能力高的時(shí)候，這種線程阻塞情況就會(huì)逐級(jí)傳遞。服務(wù)器的響應(yīng)可能會(huì)有以下過程：

1)壓力普通，正常服務(wù)，耗時(shí)正常 。

2)壓力上升，服務(wù)開始出現(xiàn)大面積超時(shí)，由于使用不公平鎖競爭，偶爾會(huì)有正常耗時(shí)的請(qǐng)求。

3)壓力繼續(xù)增大，服務(wù)器開始進(jìn)入假死狀態(tài)，幾乎不能再接受新的請(qǐng)求。

表現(xiàn)在用戶端，既不能出現(xiàn)服務(wù)不能處理的提示，也無法中斷請(qǐng)求，所有的請(qǐng)求都在轉(zhuǎn)圈。繼續(xù)加大tomcat的連接數(shù)和線程數(shù)，并不會(huì)起到多大的作用。

把a(bǔ)cquire改成tryAcquire?依然不能解決問題。tryAcquire返回的是bool類型，失敗的時(shí)候依然能夠往下執(zhí)行，包括finally塊。有個(gè)毛用?

if(!tryAcquire()){ 
    return TOO_MANY_REQUESTS; 
} 

上面多加了一個(gè)判斷，這個(gè)才是正途。tryAcquire還可以加超時(shí)參數(shù)，不至于立馬返回失敗，也不至于讓調(diào)用者無限等待，而是將成功的請(qǐng)求控制在一個(gè)合理的響應(yīng)時(shí)間。

響應(yīng)時(shí)間=超時(shí)時(shí)間+業(yè)務(wù)處理時(shí)間

具體做法，拿spring來說，你可以在preHandle中獲取這個(gè)許可，然后在postHandle中釋放它;也可以使用定時(shí)器以一定的頻率去重制信號(hào)量。

當(dāng)然你也要區(qū)別對(duì)待。

1、像上面提到的web服務(wù)，可以直接拒絕服務(wù)。快速響應(yīng)才是重要的

2、像一些秒殺、下單等，可以通過排隊(duì)或者等待解決(部分的)

3、像消息消費(fèi)等，如果沒有順序需求，我覺得，無限等待還可能是個(gè)好的方式

4、對(duì)于大多數(shù)可有可無的業(yè)務(wù)結(jié)果，使用一些默認(rèn)值直接返回，效果會(huì)好的多。雖然是限流，但干的是熔斷的活

使用者一定要注意區(qū)分。

End

非常讓人奇怪的是，java抽象了使用場景并不是很高(相對(duì))的CyclicBarrier，但是并沒有一個(gè)通用的限流方法。信號(hào)量雖然可以模擬實(shí)現(xiàn)這個(gè)過程，但它不太友好，太容易出錯(cuò)。限流還是使用guava的組件進(jìn)行控制比較好(非分布式)，我們會(huì)在后面的文章來探討它。