Nodejs中怎么解決CPU密集型任務(wù)

這篇文章給大家介紹Nodejs中怎么解決CPU密集型任務(wù)，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

沂源ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：13518219792（備注：SSL證書合作）期待與您的合作！

一. 方案對比

二. 其他的線程池方案

1 Libuv和nginx的線程池：線程數(shù)固定，多個線程共享一個任務(wù)隊(duì)列，沒有任務(wù)時主動掛起，不會主動退出。

2 Java：線程數(shù)運(yùn)行時可以動態(tài)增加，支持空閑退出、任務(wù)過載多種處理策略，多種類型的線程池。

三. 訴求

1 提交一個js文件處理cpu型任務(wù)，這樣比較方便。而不是傳一個函數(shù)，需要經(jīng)過各種序列化反序列化。

2 一個全局的線程池，可以支持多種類型的任務(wù)，類似libuv線程池

3 空閑過久的線程可以主動退出

4 任務(wù)過載可以動態(tài)擴(kuò)展線程數(shù)

Nodejs線程池的調(diào)研：

1 machenjie/node-thread-pool 任務(wù)只能是代碼字符串，固定線程數(shù)，不支持空閑線程主動退出

2 Truth2984/thread_pools 任務(wù)只能是代碼字符串，沒有實(shí)現(xiàn)池化，每次創(chuàng)建一個線程，執(zhí)行完任務(wù)退出。

3 bruno303/node-workers-pool 任務(wù)只能是代碼字符串，不支持空閑退出

4 zebrajaeger/threadpool 不是線程池的概念 5

psastras/node-threadpool 沒有實(shí)現(xiàn)池化，不支持空閑退出

6 node-worker-threads-pool 周下載量20k左右，star 80。任務(wù)只能是代碼字符串，不支持空閑線程退出,固定線程數(shù)

7 threads 周下載量20k左右，star 1.1k 是對線程模塊的封裝，沒有實(shí)現(xiàn)池化能力

8 poolifier 周下載量5000左右，star 59，任務(wù)可以是js文件，一個類型的任務(wù)新建一個線程池，無法共享線程池

目前的npm包看起來還不太能滿足需求。所以決定寫一個。

四.線程池的設(shè)計(jì)需要考慮的問題

1 對于純cpu型的任務(wù)，線程數(shù)和cpu核數(shù)要相等才能達(dá)到最優(yōu)的性能，否則過多的線程引起的上下文切換反而會導(dǎo)致性能下降。

2  對于io型的任務(wù)，更多的線程理論上是會更好，因?yàn)榭梢愿绲亟o硬盤發(fā)出命令，磁盤會優(yōu)化并持續(xù)地處理請求。當(dāng)然，線程數(shù)也不是越多越好。線程過多會引起系統(tǒng)負(fù)載過高，過多上下文切換也會帶來性能的下降。

3 使用方便、簡單

整體架構(gòu)(原圖[1])

五. 設(shè)計(jì)思想

1 任務(wù)隊(duì)列的設(shè)計(jì)

1.1傳統(tǒng)的線程池設(shè)計(jì) 維護(hù)一個共享的任務(wù)隊(duì)列，然后多個線程通過加鎖互斥的方式訪問該隊(duì)列，取出任務(wù)執(zhí)行。比如libuv，nginx。

1.2 我們的設(shè)計(jì)  因?yàn)槲覀兪峭ㄟ^js使用nodejs線程池的，隊(duì)列也是使用js數(shù)據(jù)結(jié)構(gòu)表示的。所以我們無法通過加鎖的方式互斥訪問共享隊(duì)列。這就會引起競態(tài)條件。我們使用的方式是，每個子線程維護(hù)自己的任務(wù)隊(duì)列，調(diào)度中心把任務(wù)提交給子線程，子線程自己插入所維護(hù)的隊(duì)列中。

2 線程類型和任務(wù)數(shù)  把線程分為核心線程和替補(bǔ)線程。分為幾個關(guān)鍵的概念：子線程當(dāng)前的任務(wù)數(shù)，線程池的總?cè)蝿?wù)數(shù)、核心線程數(shù)和最大線程數(shù)。在總?cè)蝿?wù)數(shù)還沒有得到閾值時，所有任務(wù)都由核心線程處理，達(dá)到閾值后，會創(chuàng)建替補(bǔ)線程處理。

3 過載處理策略和選擇線程的策略  任務(wù)過載時，就會觸發(fā)過載處理策略。分為報錯、在主線程執(zhí)行任務(wù)、繼續(xù)交給子線程處理、刪除最老的任務(wù)。選擇線程的策略為選擇任務(wù)數(shù)最少的線程。

4 空閑策略 當(dāng)沒有任務(wù)可處理的時候，線程池的線程怎么辦?

4.1 傳統(tǒng)的設(shè)計(jì)  使用條件變量機(jī)制，把線程阻塞在條件變量中，這時候操作系統(tǒng)不會調(diào)度該線程執(zhí)行，所以不會浪費(fèi)cpu，等到有新任務(wù)到來時，主線程會喚醒被阻塞的子線程。不過阻塞的線程依然占據(jù)著系統(tǒng)資源，如果一直沒有任務(wù)，則浪費(fèi)資源。

4.2 我們的設(shè)計(jì)  我們在js層無法像底層線程一樣使用條件變量，所以我們無法阻塞自己，這就意味著我們會一直在空轉(zhuǎn)、浪費(fèi)資源。所以我們設(shè)計(jì)了線程的空閑退出時間，達(dá)到這個時間后，線程退出。盡快釋放資源。

5 如何設(shè)計(jì)用戶和線程池的通信 用戶提交任務(wù)后，如果知道任務(wù)什么時候執(zhí)行完?如何拿到執(zhí)行結(jié)果?執(zhí)行任務(wù)的時候，參數(shù)如何傳進(jìn)去?

5.1 傳統(tǒng)的設(shè)計(jì) 用戶把需要處理的邏輯封裝到函數(shù)中，然后子線程中阻塞時執(zhí)行，執(zhí)行完后，同步拿到結(jié)果。

5.2 我們的設(shè)計(jì)  但是在nodejs中不太一樣。Nodejs使用work_thread模塊創(chuàng)建的線程，其實(shí)是一個和主線程獨(dú)立的事件循環(huán)。所以我們在子線程里執(zhí)行任務(wù)時，其實(shí)就相當(dāng)于在執(zhí)行一個nodejs的實(shí)例，這就意味著我們可以以同步和異步的方式編程我們?nèi)蝿?wù)函數(shù)代碼。那么以異步方式進(jìn)行處理的任務(wù)，我們?nèi)绾文玫浇Y(jié)果?為了解決以上問題，我們使用函數(shù)和Promise方案。用戶提交的任務(wù)具體表現(xiàn)為一個返回Promise的函數(shù)，使用函數(shù)是因?yàn)槲覀兛梢栽谔幚砣蝿?wù)(執(zhí)行函數(shù))時，把用戶自定義的參數(shù)傳進(jìn)去，使用Promise可以等到用戶返回的Promise決議時，拿到返回的值，從而返回給用戶。

具體實(shí)現(xiàn)：用戶定義的邏輯test.js

module.exports = function() {     return new Promise((resolve, reject) => {         setTimeout(() => {             resolve({code: 0});         },3000)     }) }

子線程邏輯

const result = await require('./test')(options);

六.成果

線程池支持的參數(shù)

1 coreThreads：核心線程數(shù)，默認(rèn)10個 2 maxThreads：最大線程數(shù)，默認(rèn)50，只在支持動態(tài)擴(kuò)容的情況下，該參數(shù)有效，否則該參數(shù)等于核心線程數(shù) 3 sync：線程處理任務(wù)的模式，同步則串行處理任務(wù)，異步則并行處理任務(wù)，不同步等待用戶代碼的執(zhí)行結(jié)果 4 discardPolicy：任務(wù)超過閾值時的處理策略，策略如下 5 preCreate：是否預(yù)創(chuàng)建線程池 6 maxIdleTime：線程空閑多久后自動退出 7 pollIntervalTime：線程隔多久輪詢是否有任務(wù)需要處理 8 maxWork：線程池最大任務(wù)數(shù)  9 expansion：是否支持動態(tài)擴(kuò)容線程，閾值是最大線程數(shù)

支持的線程池類型

// 串行處理任務(wù)隊(duì)列里的任務(wù) const defaultSyncThreadPool = new SyncThreadPool(); // 并行處理任務(wù)隊(duì)列里的任務(wù) const defaultAsyncThreadPool = new AsyncThreadPool(); // 針對cpu密集型任務(wù)的線程池，線程數(shù)等于cpu核數(shù) const defaultCpuThreadPool = new CPUThreadPool(); // 線程數(shù)固定的線程池 const defaultFixedThreadPool = new FixedThreadPool(); // 只有一個線程的線程池，任務(wù)在線程池中按序執(zhí)行 const defaultSingleThreadPool = new SingleThreadPool();

七. 使用方式

方式1

nodejs子線程和nodejs主線程共享一個libuv線程池，如果在子線程中使用了libuv的線程池，會和主線程競爭libuv子線程。從而影響主線程的任務(wù)執(zhí)行。如果是純cpu的計(jì)算，則可以這樣使用。下面是這種使用方式下，nodejs的架構(gòu)。

方式2

在nodejs主進(jìn)程外開啟一個新的進(jìn)程進(jìn)行任務(wù)的處理，和主進(jìn)程保持獨(dú)立，保證穩(wěn)定性的同時，也不會和主進(jìn)程競爭libuv的線程。如果在子線程中需要用到libuv線程池，則使用方式2比較好。下面是方式2對應(yīng)的nodejs架構(gòu)。

八. 具體例子

關(guān)于Nodejs中怎么解決CPU密集型任務(wù)就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

本文標(biāo)題：Nodejs中怎么解決CPU密集型任務(wù)
瀏覽地址：http://www.muchs.cn/article20/ishijo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、App設(shè)計(jì)、靜態(tài)網(wǎng)站、電子商務(wù)、網(wǎng)站改版、營銷型網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)