如何在 go 中實(shí)現(xiàn)一個(gè) worker-pool?
之前寫過一篇文章，它有個(gè)響亮的名字:Handling 1 Million Requests per Minute with Go使用 Go 每分鐘處理百萬請求
這是國外的一個(gè)作者寫的，我做了一篇說明，起的也是這個(gè)標(biāo)題。
沒想到閱讀量是我最好的一篇，果然文章都是靠標(biāo)題出彩的…..
今天偶然看到另一篇文章(原文在文末[1])。兩篇文章原理相似:有一批工作任務(wù)(job)，通過工作池(worker-pool)的方式，達(dá)到多worker并發(fā)處理job的效果。
他們還是有很多不同的點(diǎn)，實(shí)現(xiàn)上差別也是蠻大的。
首先上一篇文章我放了一張圖片，大概就是上篇整體的工作流。
每個(gè)
worker處理完任務(wù)就好，不關(guān)心結(jié)果,不對結(jié)果做進(jìn)一步處理。只要請求不停止，程序就不會(huì)停止，沒有控制機(jī)制，除非宕機(jī)。
這篇文章不同點(diǎn)在于:
首先數(shù)據(jù)會(huì)從generate(生產(chǎn)數(shù)據(jù))->并發(fā)處理數(shù)據(jù)->處理結(jié)果聚合。
圖大概是這樣的,
然后它可以通過context.context達(dá)到控制工作池停止工作的效果。
最后通過代碼，你會(huì)發(fā)現(xiàn)它不是傳統(tǒng)意義上的worker-pool，后面會(huì)說明。
下圖能清晰表達(dá)整體流程了。
順便說一句，這篇文章實(shí)現(xiàn)的代碼比 使用 Go 每分鐘處理百萬請求 的代碼簡單多了。
首先看job。
這個(gè)可以簡單過一下。最終每個(gè)job處理完都會(huì)包裝成Result返回。
下面這段就是核心代碼了。
整個(gè)WorkerPool結(jié)構(gòu)很簡單。jobs是一個(gè)緩沖channel。每一個(gè)任務(wù)都會(huì)放入jobs中等待處理woker處理。
results也是一個(gè)通道類型，它的作用是保存每個(gè)job處理后產(chǎn)生的結(jié)果Result。
首先通過New初始化一個(gè)worker-pool工作池,然后執(zhí)行Run開始運(yùn)行。
初始化的時(shí)候傳入worker數(shù)，對應(yīng)每個(gè)g運(yùn)行work(ctx,&wg,wp.jobs,wp.results),組成了worker-pool。
同時(shí)通過sync.WaitGroup,我們可以等待所有worker工作結(jié)束，也就意味著work-pool結(jié)束工作，當(dāng)然可能是因?yàn)槿蝿?wù)處理結(jié)束，也可能是被停止了。
每個(gè)job數(shù)據(jù)源是如何來的？
對應(yīng)每個(gè)worker的工作，
每個(gè) worker 都嘗試從同一個(gè)jobs獲取數(shù)據(jù)，這是一個(gè)典型的fan-out模式。當(dāng)對應(yīng)的g獲取到job進(jìn)行處理后，會(huì)把處理結(jié)果發(fā)送到同一個(gè)results channel中,這又是一個(gè)fan-in模式。
當(dāng)然我們通過context.Context可以對每個(gè)worker做停止運(yùn)行控制。
最后是處理結(jié)果集合，
那么整體的測試代碼就是:
看了代碼之后，我們知道，這并不是一個(gè)傳統(tǒng)意義的worker-pool。它并不像上篇這篇文章一樣，初始化一個(gè)真正的worker-pool，一旦接收到job,就嘗試從池中獲取一個(gè)worker，把對應(yīng)的job交給這個(gè)work進(jìn)行處理，等work處理完畢，重新進(jìn)行到工作池中，等待下一次被利用。
附錄
[1]https://itnext.io/explain-to-me-go-concurrency-worker-pool-pattern-like-im-five-e5f1be71e2b0#fe56
???