nodejs的工作隊列？

我正在開始使用節點的集羣API和貓鼬爲節點編寫一個工作隊列。nodejs的工作隊列？

我注意到有很多庫已經做到了，但是使用了redis和fork。分叉與使用集羣API有沒有很好的理由？

編輯現在我也發現這個：https://github.com/xk/node-threads-a-gogo - 太多的選擇！

由於我已經使用了mongo，我寧願不添加redis。另外，我的要求非常寬鬆，我想要持久性，但在第一個版本中可能沒有它。

問題的第二部分：什麼是最穩定/使用nodejs工作隊列庫今天有嗎？

來源

2013-06-03 mkoryak

其中很多可能是在Cluster不可用時啓動的，或者由於它仍標記爲「實驗性」，因此不希望使用它們。使用集羣和域的工作隊列實現完全可能比fork方法更好。 –

穩定/使用的工作隊列：zeroMQ –

沒有nodejs綁定zeromq - 即時尋找一個lib節點的支持，理想情況下不需要單獨的服務器。重量輕。 – mkoryak

想跟進此事。我的解決方案最終成爲了自己的集羣impl，其中一些集羣員工是專職的工作人員（即他們只有代碼才能工作）。

我使用agenda進行作業調度。

Cron類型作業由集羣主機調度。其餘作業在非工作人員集羣中根據需要創建。（驗證電子郵件等）

在此之前，我使用kue，但因爲我的應用程序的其餘部分使用mongodb而放棄它，我不想僅使用redis來進行作業調度。

來源

2014-01-21 16:20:24 mkoryak

Have you tried https://github.com/rvagg/node-worker-farm？它重量輕，不需要單獨的服務器。

來源

2013-06-12 15:01:47 rafaelcastrocouto

非常好。謝謝。 –

我個人很偏向集羣主控。

https://github.com/isaacs/cluster-master

我喜歡集羣主設備的原因是因爲它確實非常少，除了在邏輯上添加對分叉的過程，並給您管理您正在運行的進程的數量的能力，一點點記錄/恢復啓動！我發現過於臃腫的流程管理庫往往不穩定，有時甚至會導致速度緩慢。

該庫將是對你有好處，如果滿足下列條件：

你的模塊主要是異步
您不必不同類型的事件觸發
事件數額巨大該火有少量的工作要做，但你有很多類似的事件發射（如網絡服務器的東西）

上述列表的原因是爲什麼threads-ag ogo可能對你有好處，原因相反。如果你的代碼中有幾個位置，你的事件循環中有很多工作要做，像thread-a-gogo這樣專門爲這項工作啓動一個「線程」是非常棒的，因爲你沒有確定提前產生多少工人，而是在需要時催生他們去做工作。注意：如果可能產生大量潛在的產卵，如果你開始啓動過多的過程，事實上可能會停滯，但這也可能是不好的，但我會離題。總之，如果你的模塊已經基本上是異步的，你真正想要的是一個工作池。最大限度地減少進程沒有監聽事件時的停機時間，並最大限度地提高可用的處理器數量。除非你有一個非常繁忙的同步調用，否則單個節點事件循環將會利用甚至是單個處理器核心的麻煩。在這種情況下，您最好使用集羣主控。我推薦的是做一個基準測試，看看你的程序在「最壞的情況下」可以使用多少核心。假設這是一個核心的33％。如果你有一臺四核心機器，那麼你告訴集羣主機啓動12名工人。

希望這有助於！

來源

2013-06-12 22:02:17 ChrisCM

非常基本，完美適合我目前的獨特情況，但對於未來的搜索者......它已被放棄。 –

nodejs的工作隊列？

回答

相關問題