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