高可用性的RabbitMQ集羣隊列鏡像：在時間t獲取主節點的ip隊列

根據我的理解，RabbitMQ集羣的可擴展性並非可用性，但使用鏡像隊列還可以提供可用性，因爲如果該主節點失敗，最新的奴隸可以晉升爲主人。高可用性的RabbitMQ集羣隊列鏡像：在時間t獲取主節點的ip隊列

從文檔：發佈到隊列

消息被複制到所有的奴隸。消費者無論連接到哪個節點都連接到主節點，從節點丟棄已在主節點確認的消息。隊列鏡像因此增強了可用性，但不會跨節點分發負載（所有參與節點都會完成所有工作）。

因此，跨給定隊列的節點間的負載均衡沒有意義，因爲這將始終爲與隊列主節點聯繫的節點添加額外的行程（除非我誤解了某些內容）。因此，我們希望始終能夠知道哪個節點是給定隊列的主節點。

我還沒有真正與RabbitMQ合作過，所以也許我只是在文檔中丟失了它，但是似乎沒有辦法確定鏡像隊列的主服務器的IP，如果出現主服務器故障和奴隸晉升爲主人。我看到的每個源代碼都只是說明了設置初始主節點的能力，這對我沒有多大幫助。對於任何時間t，如何找到給定隊列的主節點ip？如果只有一個網絡分區（即使在同一個局域網中的節點也可能發生），那麼在負載均衡器後面簡單地擁有節點似乎也不好，那麼我們可能會遇到節點，與隊長交流，或者更糟糕的是，如果你願意的話，我們可能會出現一個分裂的大腦。

來源

2016-05-09 Steve P.

您可以創建維護隊列鏡像拓撲的智能客戶端。可以使用Management Plugin及其REST API。

例如。爲隊列，curl -i -u guest:guest http://[HOST]:[PORT]/api/queues/[VHOST]/[QUEUE]將返回以下有效載荷：

{ 
    "messages": 0, 
    "slave_nodes": [ 
    "[email protected]", 
    "[email protected]" 
    ], 
    "synchronised_slave_nodes": [ 
    "[email protected]", 
    "[email protected]" 
    ], 
    "recoverable_slaves": [ 
    "[email protected]" 
    ], 
    "state": "running", 
    "name": "myQueue", 
=>"node": "[email protected]" 
}

對於myQueue中你的客戶，將有利於連接node2（在myQueue中主節點），以儘量減少HOP。

我不確定它是否值得花費。它會增加連接數量和客戶端的複雜性。如果您實施某些思想，我會很樂意收到反饋。

來源

2016-05-10 16:29:34

考慮更多關於它之後，額外的跳躍可能並不像試圖跳過跳躍引入的複雜性那麼大。 –

您不需要主節點的IP，您只需要隊列被鏡像，這樣隊列中的所有消息都在所有節點上。在你引用了一個以上的段落就是這句話

每一個鏡像隊列由一個主機和一個或更多的奴隸，與最古老的奴隸被提升到新的主如果舊主消失以任何理由。

這樣的話主和從涉及隊列，不RabbitMQ的節點，我猜這裏是混亂。有一次，我讀什麼的問題，然後再次的文檔，它讓我思考了一段時間，但我們不能說一個鏡像隊列由主站和RabbitMQ的節點的奴隸;）

至於負載均衡（？）羣集，您可以這樣做，以便客戶端始終通過使用實際的負載平衡器連接到活動的rabbitmq節點，或者使客戶端「更智能」 - 即它們應該重新連接到另一個節點（原始）主節點關閉。推薦第一種方法，只需查找連接到客戶端的羣集here。

來源

2016-05-10 05:08:22 cantSleepNow

高可用性的RabbitMQ集羣隊列鏡像：在時間t獲取主節點的ip隊列

回答

相關問題