在基于PHP（或Java / ASP.NET / Ruby）的Web服務(wù)器中，每個(gè)客戶端請求都在新線程上實(shí)例化。但是在Node.js中，所有客戶端都在同一線程上運(yùn)行（它們甚至可以共享相同的變量！）我知道I / O操作是基于事件的，因此它們不會阻塞主線程循環(huán)。我不明白為什么Node的作者選擇了它為單線程？這使事情變得困難。例如，我無法運(yùn)行CPU密集型功能，因?yàn)樗鼤枞骶€程（并且會阻止新的客戶端請求），因此我需要產(chǎn)生一個(gè)進(jìn)程（這意味著我需要?jiǎng)?chuàng)建一個(gè)單獨(dú)的JavaScript文件并在其上執(zhí)行另一個(gè)節(jié)點(diǎn)進(jìn)程） ）。但是，在PHP cpu中，密集型任務(wù)不會阻止其他客戶端，因?yàn)檎缥姨岬降哪菢?，每個(gè)客戶端都在不同的線程上。與多線程Web服務(wù)器相比，它有什么優(yōu)勢？注意：我已經(jīng)使用集群解決了這個(gè)問題，但這并不是很漂亮。
3 回答
森林海
TA貢獻(xiàn)2011條經(jīng)驗(yàn) 獲得超2個(gè)贊
Node.js是作為異步處理中的實(shí)驗(yàn)而顯式創(chuàng)建的。從理論上講，與典型的基于線程的實(shí)現(xiàn)相比，在典型的Web負(fù)載下對單個(gè)線程執(zhí)行異步處理可以提供更高的性能和可伸縮性。
你知道嗎？我認(rèn)為理論已經(jīng)被證實(shí)。與Apache或IIS或其他基于線程的服務(wù)器相比，不占用大量CPU資源的node.js應(yīng)用程序可以運(yùn)行數(shù)千個(gè)并發(fā)連接。
單線程異步性質(zhì)的確使事情變得復(fù)雜。但是，老實(shí)說，您認(rèn)為它比線程處理還要復(fù)雜嗎？一種種族狀況可能會破壞您的整個(gè)月！或由于某處的某些設(shè)置而清空線程池，并觀察響應(yīng)時(shí)間變慢以進(jìn)行爬網(wǎng)！更不用說死鎖，優(yōu)先級反轉(zhuǎn)以及與多線程相關(guān)的所有其他回旋。
最后，我不認(rèn)為它普遍好壞。這是不同的，有時(shí)更好，有時(shí)則不是。使用正確的工具完成工作。
料青山看我應(yīng)如是
TA貢獻(xiàn)1772條經(jīng)驗(yàn) 獲得超8個(gè)贊
服務(wù)器的“每個(gè)請求一個(gè)線程”模型的問題在于，與事件循環(huán)線程模型相比，它們在幾種情況下無法很好地?cái)U(kuò)展。
通常，在I / O密集型方案中，請求花費(fèi)大部分時(shí)間等待I / O完成。在此期間，在“每個(gè)請求一個(gè)線程”模型中，鏈接到該線程的資源（例如內(nèi)存）未使用，內(nèi)存是限制因素。在事件循環(huán)模型中，循環(huán)線程選擇要處理的下一個(gè)事件（I / O完成）。因此，線程總是很忙（如果正確編程的話）。
事件循環(huán)模型看起來很新鮮，所有問題的解決方案都取決于您需要解決的情況，但是要使用哪種模型。如果您具有密集型I / O方案（如代理），則將以事件基模型為準(zhǔn)，而并行進(jìn)程數(shù)量較少的CPU密集型方案將最適合基于線程的模型。
在現(xiàn)實(shí)世界中，大多數(shù)情況都將處于中間位置。您將需要在可伸縮性的實(shí)際需求與開發(fā)復(fù)雜性之間找到平衡，以找到正確的體系結(jié)構(gòu)（例如，具有事件基前端，該事件基前端可以委托后端執(zhí)行CPU密集型任務(wù)。前端將使用很少的資源來等待任務(wù)與任何分布式系統(tǒng)一樣，它需要付出一些努力才能使其正常工作。
如果您不費(fèi)吹灰之力地尋找適合任何情況的銀色子彈，那么最終您將獲得一枚子彈。
- 3 回答
- 0 關(guān)注
- 973 瀏覽
添加回答
舉報(bào)
0/150
提交
取消