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