你好呀，我是歪歪。

前兩天在一個(gè)技術(shù)群里看到有人拋出一張圖片，提出了這樣的一個(gè)問題：

請教一下，線程池可以做到根據(jù)任務(wù)的類型，來指定特定線程執(zhí)行嗎？

圖片

了解了一下背景，是批量任務(wù)觸發(fā)，從訂單表中查詢出“處理中”狀態(tài)的訂單，訂單可能屬于不同的通道，所以需要調(diào)用不同通道的接口。

現(xiàn)在的方案是把訂單查出來之后，往線程池里面扔，在異步任務(wù)里面判斷當(dāng)前訂單是屬于哪個(gè)通道，就調(diào)用哪個(gè)通道的查詢接口：

圖片

這是常規(guī)做法，看起來沒有毛病。

但是現(xiàn)在提問的這個(gè)哥們遇到了一個(gè)問題：有一個(gè)通道的查詢接口特別慢，會(huì)占著線程池里面的線程資源，影響了其他兩個(gè)通道的訂單查詢。

舉個(gè)極端的例子，比如你的線程池核心線程數(shù)就三個(gè)。

假設(shè)一共有 5 筆數(shù)據(jù)，前 3 筆是通道 A 的，后面兩筆分別是通道 B 和通道 C 的。

結(jié)果現(xiàn)在通道 A 出問題了：

圖片

直接把你的核心線程都占滿了，剩下的兩筆對應(yīng) B 和 C 通道的數(shù)據(jù)就在隊(duì)列里面排著隊(duì)，等著。

你說這個(gè)合不合理？

非常不合理，對不對？

但是這個(gè)問題確實(shí)也是很常規(guī)，常規(guī)到它甚至沒有資格作為一個(gè)場景面試題出現(xiàn)在面試環(huán)節(jié)中。

問題在于不同的通道在共用同一個(gè)線程池，從而導(dǎo)致的相互影響。所以解決思路主要就是怎么把資源隔離開來。

一般來說，大家能想到的第一個(gè)解決方案就是用 MQ 嘛：

圖片

利用不同的隊(duì)列，天然就把不同通道的訂單給區(qū)分開了，在監(jiān)聽側(cè)各自處理各自通道的數(shù)據(jù)，這樣就達(dá)到了資源隔離的效果。

這個(gè)方案應(yīng)該是很常規(guī)了，但是這個(gè)常規(guī)方案立馬就被斃了。

因?yàn)椋?/p>

圖片

需要注意的是，他這里說的“系統(tǒng)內(nèi)部”是指同一個(gè)微服務(wù)，也就是不允許一個(gè)微服務(wù)使用 MQ 來做“自產(chǎn)自銷”。

我個(gè)人認(rèn)為是“自產(chǎn)自銷”沒有任何問題的，在這個(gè)場景下我完全可以借助它的特性幫我做數(shù)據(jù)分隔、異步處理數(shù)據(jù)，而且代碼簡單，邏輯清晰。

但是既然是公司規(guī)定，可能有一些因地制宜的考慮，我們也不好去做過多的批判。

反正就是 MQ 可以解決這個(gè)問題，但是老板并不采取這個(gè)方案。

沒關(guān)系，小腦殼一轉(zhuǎn)，大多數(shù)同學(xué)就能立馬就掏出了另外一個(gè)解決方案。

你前面出問題的原因不是因?yàn)椴煌耐ǖ涝诠灿猛粋€(gè)線程池嗎？

那很簡單，每個(gè)通道各自搞一個(gè)線程池。然后和 MQ 的方案類似，根據(jù)不同的通道扔到對應(yīng)的線程池中去，自己玩自己的：

這樣即使某個(gè)通道出問題了，由于在線程池層面做了線程資源隔離，所以也不影響另外的通道進(jìn)行數(shù)據(jù)處理。

這個(gè)就是線程池隔離的方案。

其實(shí)關(guān)于這個(gè)方案，我當(dāng)時(shí)還想到了另外一種原理一致，實(shí)現(xiàn)形式不一樣，但是最終被認(rèn)為是比較 low 的一個(gè)回答。

因?yàn)樗麙伋龅倪@個(gè)圖片，我第一眼理解錯(cuò)了，我以為是按照通道分組，然后用單線程一個(gè)個(gè)的去調(diào)用查詢接口，避免并發(fā)調(diào)用：

圖片

所以我提到了一個(gè)叫做 KeyAffinityExecutor 的魔改線程池：

圖片

這個(gè)線程池，它有一個(gè)比較厲害的特性，可以確保投遞進(jìn)來的任務(wù)按某個(gè)維度劃分出任務(wù)，然后按照任務(wù)提交的順序依次執(zhí)行。這個(gè)線程池可以通過并行處理(多個(gè)線程)來提高吞吐量、又能保證一定范圍內(nèi)的任務(wù)按照嚴(yán)格的先后順序來運(yùn)行。

對比到當(dāng)前的這個(gè)問題中。

可以按照通道維度進(jìn)行任務(wù)劃分，然后把任務(wù)往線程池扔的時(shí)候，就會(huì)被分配到不同的線程中去。

關(guān)于這個(gè)線程池，我之前寫了這篇文章，有興趣的可以去了解一下，不贅述了：《看到一個(gè)魔改線程池，面試素材加一！》

本質(zhì)上還是線程池隔離的思路，只不過一個(gè)是分多個(gè)不同的業(yè)務(wù)線程池，線程池和業(yè)務(wù)綁定。一個(gè)是一個(gè)大線程池里面包了多個(gè)線程池，線程池可以通過分配規(guī)則的方式指定。

同一個(gè)思路的不同實(shí)現(xiàn)方案而已。

但是為什么我說我提出的這個(gè)魔改線程池的方案 low 呢？

因?yàn)槿思抑皇切枰纸M的特性，而不需要“按照任務(wù)提交的順序依次執(zhí)行”的特性。

反而會(huì)出現(xiàn)如果一個(gè)通道的訂單多，只有一個(gè)線程來處理，導(dǎo)致性能不夠，任務(wù)堆積的情況。

但是，話說回來，你也可以魔改一下這個(gè)魔改線程池，把里面的小線程池的核心線程數(shù)搞多點(diǎn)，就行了。

總之，都是線程池隔離的思路。

好了，這個(gè)方案我又講完了，誰贊成，誰反對？

看著沒有任何問題，但是實(shí)際情況是：

圖片

臥槽，50 多個(gè)？

這特么的，簡歷還給我，我不面了，告辭。

確實(shí)，如果是只有三個(gè)通道，或者多說點(diǎn)，五個(gè)通道嘛，我覺得用上面這個(gè)方案做線程池維度的隔離，都是可以接受的。

但實(shí)際情況是 50 多個(gè)通道，一想起項(xiàng)目里面有 50 多個(gè)線程池在跑，這個(gè)就有點(diǎn)難受了。

好了，現(xiàn)在 MQ 和線程池隔離的方案都被否決了，接下來的思路是什么？

沒有思路沒有關(guān)系，我們再來讀讀題：批量任務(wù)觸發(fā)，從訂單表中查詢出“處理中”狀態(tài)的訂單，訂單可能屬于不同的通道，所以需要調(diào)用不同通道的接口。但是某個(gè)通道慢，導(dǎo)致影響了其他通道訂單的查詢。

問怎么辦？

某個(gè)通道慢，該怎么辦？

有的通道慢，有的通道快，我該怎么辦？

等等...

前面我們按照通道維度分線程池被否了的原因是通道太多了。

但是其實(shí)針對響應(yīng)快的通道，我們完全不需要做線程池隔離，他們完全可以使用同一個(gè)線程池嘛，反正都是唰唰唰的就查回來了。

所以，我們只需要搞兩個(gè)線程池，一個(gè)處理通道響應(yīng)快的，比如把接口調(diào)用的超時(shí)時(shí)間設(shè)置為 1s。另外一個(gè)處理通道響應(yīng)慢的，超時(shí)時(shí)間直接拉滿到 30s，自己慢慢玩去：

圖片

至于怎么去判斷通道到底是快是慢呢？

這里又可以大致分為三個(gè)不同的方案了。

第一個(gè)方案就是已知某幾個(gè)通道是慢的，那就代碼里面寫硬編碼都行。雖然不優(yōu)雅，但是這確實(shí)也是一個(gè)在實(shí)際生產(chǎn)中常常被提及的一個(gè)快速解決問題的方案。

第二個(gè)方案就是配置化，可以做個(gè)配置表，來配置通道的快慢標(biāo)識(shí)。程序里面根據(jù)當(dāng)前訂單的通道，來表里面獲取當(dāng)前通道的快慢標(biāo)識(shí)，從而把訂單扔到不同的線程池中去。

在這個(gè)方案中，用配置表代替了硬編碼，但是還是需要人工基于線下溝通或者數(shù)據(jù)監(jiān)控的方式去調(diào)整通道的快慢標(biāo)識(shí)。

你知道的，線上程序這玩意，一旦涉及到人工介入，就遭老罪了，很不爽。

所以這個(gè)方案，有一點(diǎn)優(yōu)雅，但是不多。

第三個(gè)方案就是配置化加自動(dòng)化這一套組合拳。

配置化還是指前面提到的配置表。

但是這個(gè)表中通道的快慢標(biāo)識(shí)，就不需要人工來介入了，完全由程序自己收集信息，進(jìn)行判斷。

比如，我們可以假設(shè)一開始的時(shí)候所有的通道都能快速響應(yīng)。但是突然某個(gè)通道開始“扯拐”，響應(yīng)時(shí)長出現(xiàn)波動(dòng)，1s 內(nèi)沒有響應(yīng)成功，那么這個(gè)任務(wù)就會(huì)超時(shí)，就可以把這個(gè)任務(wù)扔到慢通道線程池中去處理，同時(shí)對該通道的失敗次數(shù)進(jìn)行記錄。

當(dāng)某個(gè)時(shí)間段失敗次數(shù)超過某個(gè)閾值之后，則在配置表中標(biāo)識(shí)該通道為慢通道。

這樣當(dāng)下一個(gè)屬于該通道的訂單過來時(shí)，就會(huì)直接被扔到慢通道線程池中去。

這樣，就由程序完成了通道由“快標(biāo)識(shí)”到“慢標(biāo)識(shí)”的處理。

那么當(dāng)這個(gè)通道的問題解決之后，它又變成一個(gè)快通道時(shí)，怎么去修改它在配置表中的標(biāo)識(shí)呢？

很簡單，同樣的邏輯，在慢通道線程池處理的過程中，記錄某個(gè)時(shí)間段某個(gè)通道的平均響應(yīng)時(shí)長，如果低于指定閾值，比如 1s，則在配置表中重新標(biāo)識(shí)該通道為快通道。

整個(gè)過程，不管標(biāo)識(shí)怎么變化，都是基于程序自動(dòng)的數(shù)據(jù)統(tǒng)計(jì)來的，完全不需要人工介入。

甚至你還可以加一個(gè)邏輯：當(dāng)配置表中的通道都是快通道時(shí)，兩個(gè)線程池都可以用起來，實(shí)現(xiàn)資源利用的最大化。

優(yōu)雅，非常優(yōu)雅。

至于怎么去統(tǒng)計(jì)線程池中的任務(wù)“某個(gè)時(shí)間段失敗次數(shù)”和“某個(gè)時(shí)間段某個(gè)通道的平均響應(yīng)時(shí)長”這樣的統(tǒng)計(jì)信息，在線程池里面，專門留了這兩個(gè)方法給你去在任務(wù)執(zhí)行之前和之后搞事情，完全可以基于這兩個(gè)方法做一些統(tǒng)計(jì)工作：

java.util.concurrent.ThreadPoolExecutor#runWorker

圖片

圖片

就目前提出的方案來說，把通道分為快慢通道，然后劃分為線程池是最滿足提問者的需求的。

最后應(yīng)該就拿著這個(gè)方案去匯報(bào)了。

匯報(bào)題目我都幫忙想好了：

《基于通道關(guān)鍵指標(biāo)收集分析的全自適應(yīng)、高敏感度、資源利用最大化的調(diào)度方案匯報(bào)》

剩下的，就看你怎么去吹了。

除去前面的方案外，其實(shí)我還想到一個(gè)“比較奇葩”的解決方案。

因?yàn)樗臉I(yè)務(wù)場景是定時(shí)任務(wù)嘛，所以我想起了之前寫過的這篇文章：《又被奪命連環(huán)問了！從一道關(guān)于定時(shí)任務(wù)的面試題說起?！?/p>

既然能區(qū)分出來通道的快慢，那么在定時(shí)任務(wù)啟動(dòng)之后，我們就可以把“快慢標(biāo)識(shí)”傳遞到服務(wù)器中去，服務(wù)器就能把訂單分為快慢兩大類，然后一臺(tái)機(jī)器處理通道慢的訂單數(shù)據(jù)，一臺(tái)處理快的：

圖片

這樣我就能從服務(wù)器這個(gè)物理層面就把數(shù)據(jù)區(qū)分開了。

所以只要能標(biāo)識(shí)開區(qū)分?jǐn)?shù)據(jù)，那么理論上不僅可以在代碼中區(qū)分，也可以往上抽離一層，通過服務(wù)器維度區(qū)分。

但是好處是什么呢？

呃...

看起來確實(shí)沒什么好處，只是這個(gè)方案比較奇葩，一般沒人想到，我就是順便提一嘴，主要是顯擺一下。

不顯擺一下，裝裝逼，總感覺不得勁。

類似的場景

基于提問者的這個(gè)問題，歪師傅也想起了兩個(gè)類似的場景。

一個(gè)是我參與開發(fā)過的一個(gè)對客發(fā)送短信的消息系統(tǒng)，簡化一下整個(gè)流程大概是這樣的：

圖片

上面這個(gè)圖片會(huì)出現(xiàn)什么問題呢？

就是消息堆積。

當(dāng)某個(gè)業(yè)務(wù)系統(tǒng)調(diào)用短信發(fā)送接口，批量發(fā)送消息的時(shí)候，比如發(fā)送營銷活動(dòng)時(shí)，大量的消息就在隊(duì)列里面堆著，慢慢消費(fèi)。

其實(shí)堆積也沒有關(guān)系，畢竟?fàn)I銷活動(dòng)的實(shí)時(shí)性要求不是那么高，不要求立馬發(fā)送到客戶手機(jī)上去。

但是，如果在消息堆積起來之后，突然有用戶申請了驗(yàn)證碼短信呢？

圖片

需要把前面堆積的消費(fèi)完成后，才會(huì)發(fā)送驗(yàn)證碼短信，這個(gè)已經(jīng)來不及了，甚至驗(yàn)證碼已經(jīng)過期很久了你才發(fā)過去。

客戶肯定會(huì)罵娘，因?yàn)楂@取不到驗(yàn)證碼，他就不能進(jìn)行后續(xù)業(yè)務(wù)。

如果大量客戶因?yàn)槭詹坏津?yàn)證碼不能進(jìn)行后續(xù)業(yè)務(wù)，引起群體性的客訴，甚至用戶恐慌，這個(gè)對于企業(yè)來說是一個(gè)非常嚴(yán)重的事件。

怎么辦呢？

解決方案非常簡單，再搞一個(gè)“高速”隊(duì)列出來：

圖片

驗(yàn)證碼消息直接扔到“高速”隊(duì)列中去，這個(gè)隊(duì)列專門用來處理驗(yàn)證碼、動(dòng)賬通知這一類時(shí)效性要求極高的消息，從業(yè)務(wù)場景上分析，也不會(huì)出現(xiàn)消息堆積。

不是特別復(fù)雜的方案，大道至簡，問題得到了解決。

類比到前面說的“快慢”線程池，其實(shí)是一樣的思想，都是從資源上進(jìn)行隔離。

只不過我說的這個(gè)場景更加簡單，不需要去收集信息進(jìn)行動(dòng)態(tài)判斷。業(yè)務(wù)流程上天然的就能區(qū)分出來，哪些消息實(shí)時(shí)性比較高，應(yīng)該走“高速”隊(duì)列；哪些消息慢慢 發(fā)沒關(guān)系，可以應(yīng)該走“常規(guī)”隊(duì)列。

而這個(gè)所謂的“高速”和“常規(guī)”，只是開發(fā)人員給一個(gè)普通隊(duì)列賦予的一個(gè)屬性而已，站在 MQ 的角度，這兩個(gè)隊(duì)列沒有任何區(qū)別。

另外一個(gè)場景是我想起了之前寫過的這篇文章：《我試圖給你分享一種自適應(yīng)的負(fù)載均衡?！?/p>

我們還是先看看前面出現(xiàn)的這個(gè)圖：

圖片

圖中的線程池，不管是快的還是慢的，本質(zhì)上他們處理的請求都是一樣的，即拿著訂單去對應(yīng)的通道查詢訂單結(jié)果。

那我們是不是可以把這兩個(gè)線程池抽象一下，理解為部署了同一個(gè)服務(wù)的兩個(gè)不同的服務(wù)器，一個(gè)服務(wù)器的性能好，一個(gè)服務(wù)器的性能差。

現(xiàn)在有一個(gè)請求過來了，理論上這兩個(gè)服務(wù)器都能處理這個(gè)請求，所以我們通過某個(gè)邏輯選一個(gè)服務(wù)器出來，把請求發(fā)過去。

這個(gè)“某個(gè)邏輯”不就是我們常說的負(fù)載均衡算法嗎？

負(fù)載均衡算法的算法有很多：

圖片

其中這幾個(gè)都是需要統(tǒng)計(jì)服務(wù)端的相關(guān)數(shù)據(jù)，基于數(shù)據(jù)進(jìn)行分析，最終覺得把當(dāng)前請求發(fā)個(gè)哪個(gè)服務(wù)器：

圖片

這個(gè)邏輯，和我們前面提到的這句話，其實(shí)是一脈相承的，都是信息收集、指標(biāo)分析、閾值設(shè)定：

去統(tǒng)計(jì)線程池中的任務(wù)“某個(gè)時(shí)間段失敗次數(shù)”和“某個(gè)時(shí)間段某個(gè)通道的平均響應(yīng)時(shí)長”這樣的統(tǒng)計(jì)信息

你想想我們最開始的問題是“一個(gè)通道慢了，影響了其他通道的數(shù)據(jù)，怎么辦？”

現(xiàn)在我?guī)е愠兜搅恕柏?fù)載均衡策略”。

這兩個(gè)場景不能說八竿子打不著吧，但是它們確實(shí)在一定程度上有相似性，轉(zhuǎn)好幾個(gè)彎之后，也能聯(lián)系到一起。

你要是再發(fā)散一點(diǎn)，你甚至能想到 Serverless 的彈性場景，通過收集 CPU、Mem 指標(biāo)、QPS、RT、TCP 連接數(shù)等指標(biāo)，進(jìn)行綜合判斷，彈性擴(kuò)容，也無需人工介入，手動(dòng)擴(kuò)容。

所以，朋友，這個(gè)事情告訴我們一個(gè)什么道理？

向上抽象問題的能力，把看看似不一樣的場景抽離成類似的問題模型的能力很重要。

還有，“一個(gè)通道慢需要進(jìn)行資源隔離”這個(gè)問題的關(guān)鍵不在于“一個(gè)通道”上，雖然可以在通道層面做隔離，但是這樣并沒有抓住問題的關(guān)鍵。問題的關(guān)鍵在于“通道慢”，所以可以在“快慢”的維度上做隔離，這才是問題的關(guān)鍵。

關(guān)鍵問題，就是要找到問題的關(guān)鍵。

這也是我在這一次群聊的討論中學(xué)習(xí)到的東西。