信號量限流，高并發場景不得不說的秘密
限流可以認為是一種降級，一般是根據后臺的負載提前預估的一個閾值(也可以動態調整)。超過了這個值，就要進行一些旁路處理。根據業務形態，會有直接拒絕、延遲處理、保持等待、部分穿透、默認返回等響應方式。
concurrent包中的信號量，由于使用簡單，易于理解，被廣泛應用。但是，你要是直接用了網友們分享的簡單代碼而不經過認真測試，那可以送你一部電影觀賞一下：《當故障來敲門》。
看下面簡單的代碼，acquire和release是一對同命鴛鴦，我們把release貼心的放在了finally塊中，一切顯得非常和諧。
1)模擬的業務請求，耗時大約是100毫秒
2)acquire的參數5代表同一時間允許5個線程進行處理
3)每次執行完畢，輸出一下本次執行的具體耗時，加上等待時間
我們啟動1000個線程去執行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());
- }
- });
- }
下面是執行結果。
可以看到，雖然我們的接口耗時只有100ms，實際的執行時間，卻長的多，而且并沒有出現fail的情況。運行稍長一點時間，能夠發現有大量的線程處于餓死的狀態。改為公平鎖并不能改善這一情況。
這就是故障。
原因就在于。web端(如tomcat)的資源也是有限的。當我們的限流器產生了作用，而實際并發請求比處理能力高的時候，這種線程阻塞情況就會逐級傳遞。服務器的響應可能會有以下過程：
1)壓力普通，正常服務，耗時正常 。
2)壓力上升，服務開始出現大面積超時，由于使用不公平鎖競爭，偶爾會有正常耗時的請求。
3)壓力繼續增大，服務器開始進入假死狀態，幾乎不能再接受新的請求。
表現在用戶端，既不能出現服務不能處理的提示，也無法中斷請求，所有的請求都在轉圈。繼續加大tomcat的連接數和線程數，并不會起到多大的作用。
把acquire改成tryAcquire?依然不能解決問題。tryAcquire返回的是bool類型，失敗的時候依然能夠往下執行，包括finally塊。有個毛用?
- if(!tryAcquire()){
- return TOO_MANY_REQUESTS;
- }
上面多加了一個判斷，這個才是正途。tryAcquire還可以加超時參數，不至于立馬返回失敗，也不至于讓調用者無限等待，而是將成功的請求控制在一個合理的響應時間。
響應時間=超時時間+業務處理時間
具體做法，拿spring來說，你可以在preHandle中獲取這個許可，然后在postHandle中釋放它;也可以使用定時器以一定的頻率去重制信號量。
當然你也要區別對待。
1、像上面提到的web服務，可以直接拒絕服務。快速響應才是重要的
2、像一些秒殺、下單等，可以通過排隊或者等待解決(部分的)
3、像消息消費等，如果沒有順序需求，我覺得，無限等待還可能是個好的方式
4、對于大多數可有可無的業務結果，使用一些默認值直接返回，效果會好的多。雖然是限流，但干的是熔斷的活
使用者一定要注意區分。
End
非常讓人奇怪的是，java抽象了使用場景并不是很高(相對)的CyclicBarrier，但是并沒有一個通用的限流方法。信號量雖然可以模擬實現這個過程，但它不太友好，太容易出錯。限流還是使用guava的組件進行控制比較好(非分布式)，我們會在后面的文章來探討它。
