信號(hào)量限流，高并發(fā)場(chǎng)景不得不說(shuō)的秘密
限流可以認(rèn)為是一種降級(jí)，一般是根據(jù)后臺(tái)的負(fù)載提前預(yù)估的一個(gè)閾值(也可以動(dòng)態(tài)調(diào)整)。超過(guò)了這個(gè)值，就要進(jìn)行一些旁路處理。根據(jù)業(yè)務(wù)形態(tài)，會(huì)有直接拒絕、延遲處理、保持等待、部分穿透、默認(rèn)返回等響應(yīng)方式。
concurrent包中的信號(hào)量，由于使用簡(jiǎn)單，易于理解，被廣泛應(yīng)用。但是，你要是直接用了網(wǎng)友們分享的簡(jiǎn)單代碼而不經(jīng)過(guò)認(rèn)真測(cè)試，那可以送你一部電影觀賞一下：《當(dāng)故障來(lái)敲門》。
看下面簡(jiǎn)單的代碼，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í)間，卻長(zhǎng)的多，而且并沒有出現(xiàn)fail的情況。運(yùn)行稍長(zhǎng)一點(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ì)有以下過(guò)程：
1)壓力普通，正常服務(wù)，耗時(shí)正常 。
2)壓力上升，服務(wù)開始出現(xiàn)大面積超時(shí)，由于使用不公平鎖競(jìng)爭(zhēng)，偶爾會(huì)有正常耗時(shí)的請(qǐng)求。
3)壓力繼續(xù)增大，服務(wù)器開始進(jìn)入假死狀態(tài)，幾乎不能再接受新的請(qǐng)求。
表現(xiàn)在用戶端，既不能出現(xiàn)服務(wù)不能處理的提示，也無(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)用者無(wú)限等待，而是將成功的請(qǐng)求控制在一個(gè)合理的響應(yīng)時(shí)間。
響應(yīng)時(shí)間=超時(shí)時(shí)間+業(yè)務(wù)處理時(shí)間
具體做法，拿spring來(lái)說(shuō)，你可以在preHandle中獲取這個(gè)許可，然后在postHandle中釋放它;也可以使用定時(shí)器以一定的頻率去重制信號(hào)量。
當(dāng)然你也要區(qū)別對(duì)待。
1、像上面提到的web服務(wù)，可以直接拒絕服務(wù)。快速響應(yīng)才是重要的
2、像一些秒殺、下單等，可以通過(guò)排隊(duì)或者等待解決(部分的)
3、像消息消費(fèi)等，如果沒有順序需求，我覺得，無(wú)限等待還可能是個(gè)好的方式
4、對(duì)于大多數(shù)可有可無(wú)的業(yè)務(wù)結(jié)果，使用一些默認(rèn)值直接返回，效果會(huì)好的多。雖然是限流，但干的是熔斷的活
使用者一定要注意區(qū)分。
End
非常讓人奇怪的是，java抽象了使用場(chǎng)景并不是很高(相對(duì))的CyclicBarrier，但是并沒有一個(gè)通用的限流方法。信號(hào)量雖然可以模擬實(shí)現(xiàn)這個(gè)過(guò)程，但它不太友好，太容易出錯(cuò)。限流還是使用guava的組件進(jìn)行控制比較好(非分布式)，我們會(huì)在后面的文章來(lái)探討它。
