無論是因爲可伸縮性,安全性還是任何其他任意問題,考慮在不同服務器之間分配應用程序邏輯的情況並不少見。在這種情況下,在獨立的模塊或應用程序之間建立可靠的通信渠道非常重要。連接在不同服務器上運行的Node.js應用程序
的實際情況可能是這樣的:
- (服務器#1)你有一個數據庫表填滿了任務(在表條目的形式)需要進行處理。
- (服務器#2)您有獲取這些任務一個接一個,以處理它們在某些特定的方式仲裁員。
- (服務器#3 - #N)您有收到仲裁任務,並將結果返回到它的多個工作者應用程序。
現在想象這一切都是編程Node.js的您希望工作服務器能夠在需要更多資源時產生,並在處理負載較低時終止。當一個工作節點被創建時,它必須連接回仲裁器來表示它已準備好接收任務。
哪些與仲裁使得仲裁員可檢測出一個新的工作節點連接到它與數據在兩者之間能夠開始流動通訊的工作節點的可用選項。或者換句話說,如何着手在兩個遠程Node.js應用程序之間創建可靠的全狀態通信通道?
瞭解可以解決這個問題的不同技術是很好的,但是,描述可以更好地解決這個問題的範例也很好。例如,發佈 - 訂閱模型可以爲此工作還是應該使用另一種架構? – UndeadKernel
您的情況可能需要工人隊列或rpc範例。在pub/sub方法中,您可以讓多個「工作人員」訂閱單個事件;這意味着每個工作人員都會參與該活動。這在工作人員執行不同任務的情況下很好,但是在您的情況下聽起來好像所有工作人員都執行相同的任務,並且只是爲了可伸縮性而複製。閱讀RabbitMQ站點上的不同示例,試圖解釋每個用例的優點。 –