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

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

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

1)模擬的業(yè)務請求，耗時大約是100毫秒

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

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

我們啟動1000個線程去執(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í)行結果。

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

這就是故障。

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

1)壓力普通，正常服務，耗時正常 。

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

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

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

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

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

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

響應時間=超時時間+業(yè)務處理時間

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

當然你也要區(qū)別對待。

1、像上面提到的web服務，可以直接拒絕服務?？焖夙憫攀侵匾?/p>

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

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

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

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

End

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