Node.js 跨多個磁盤驅動器的文件系統 I/O 性能：工作線程與否？

Question

我在這里閱讀了幾個關於 Node.js 以非阻塞方式快速處理文件 I/O 操作的能力與使用阻塞或非阻塞請求的工作線程相比的性能優勢的問題和答案，但似乎沒有回答我的問題。

我正在編寫一個 Node.js 應用程序，它將打開、散列和寫入存儲在多個硬盤驅動器上的非常大的文件（多個演出）。 我正在探索工作線程的想法，因為它們允許我將命令隔離到特定的硬盤驅動器。 例如：假設我有一個線程處理將硬盤 A 上的一個文件復制到硬盤 B，另一個線程處理將一個文件從硬盤 C 復制到硬盤 D。

假設我同時將其擴展到更多的硬盤驅動器，僅使用 Node.js 而不使用工作線程並讓它處理所有這些請求對我來說是否更有意義，或者如果我可以隔離 I/ O 按驅動器同時處理多個驅動器的請求？

鑒於我所讀到的內容，工作線程似乎是顯而易見的解決方案，但我也看到僅讓單個 Node.js 進程處理文件 I/O 隊列通常會更快。 感謝您提供的任何指導！

Answer 1

編輯：顯然（基於下面的評論），nodejs 只有一個線程池在所有工作線程之間共享。 如果是這種情況，那么為每個磁盤獲得一個單獨的池的唯一方法是使用多個進程，而不是多個線程。

或者，您可以擴大工作池，然后制作自己的排隊系統，一次只將對每個單獨磁盤的幾個請求放入工作池，從而在不同的驅動器之間提供更多的並行性。

原始答案（其中一些仍然適用）：

如果沒有工作線程，您將只有一個 libuv 線程池來處理所有磁盤 I/O 請求。 因此，它們會將所有 go 放入同一個池中，一旦該池中的線程繁忙（無論它們正在服務哪個磁盤），新請求將按照它們到達的順序排隊。 這可能不太理想，因為如果您對驅動器 A 有 5 個請求，對驅動器 B 有 1 個請求，對驅動器 C 有 1 個請求，您不希望首先用對驅動器 A 的 5 個請求填充池，因為這將使驅動器 B 和驅動器 C 的請求等到驅動器 A 上的多個請求完成后，它們才能開始。 這失去了一些跨單獨驅動器的並行性的機會。 當然，您是否真正在單獨的驅動器上獲得並行性還取決於驅動器 controller 的實現以及它們是否實際上具有單獨的 SATA 控制器。

如果您確實使用了工作線程，每個磁盤一個 nodejs 工作線程，您至少可以保證每個磁盤的線程池中都有一個單獨的操作系統線程池，並且更有可能沒有一組請求一個驅動器將阻止對其他驅動器的請求有機會啟動並錯過與對其他驅動器的請求並行運行的機會。

現在，當然，所有這些討論都是理論上的。 在磁盤驅動器、controller 卡、控制器之上的操作系統以及 libuv 之上的 nodejs 之上，理論討論有很多機會無法在現實世界的測量中得到證實。

因此，真正確定的唯一方法是實施工作線程選項，然后將其與具有多種不同磁盤使用場景的非工作線程選項進行基准比較，包括您認為可能是最壞的情況。 因此，與任何與性能相關的重要問題一樣，您將不可避免地必須進行基准測試和衡量才能確定其中一種方式。 而且，您的結果也需要非常仔細地構建基准測試才能發揮最大作用。

Answer 2

只是為了擴展每個進程 model，它看起來與 jfriend00 建議的工作線程相同，只是 IPC 機制發生了變化。

從“頭”管理器進程管理作業隊列，並將驅動/散列工作拆分為每個工作人員的節點進程，這樣每個工作人員就不會發生 IO/CPU 爭用。

讓每個工作人員一次從其驅動器（或驅動器組）的工作隊列中選擇一項工作。 您所需要的只是可靠性、監控未處理的工作人員以及工作人員完成/錯誤的返回渠道。

排隊機制並不重要，一個數據庫表就足夠了（或任何類型的.network messaging http、grpc、nanomsg、redis、nats、rabbitmq）。 這是基於除了簡單的工作消息“嘿工人，這是一個文件 go 處理它”，“我完成了這個文件”或“我打破了，幫助！”

| Manager                        |
| Pub 1 2 3                      |

| Sub 1    | Sub 2    | Sub 3    |
| Worker   | Worker   | Worker   |
|          |          |          |
| DriveA   | DriveC   | DriveE   |
| DriveB   | DriveD   | DriveF   |

如果進程最終受 CPU 限制，或者管理 IO 要求所需的數量，則每個內核運行一個工作程序。 隨着您添加驅動器或更多服務器，工作人員可以輕松擴展。