限制到兔子隊列的連接數？

Question

我在ubuntu-16.04 rabbitmq-3.6.6 pika-0.10.0與rabbitmq-3.6.6代理一起使用。 我設計了一個請求/回復服務。 所有客戶端都推送他們的請求的是一個“請求”隊列。 每個客戶端都創建一個唯一的Reply隊列：服務器將針對此客戶端的回復推送到此唯一隊列。 我的API可以看作兩條消息： init和run 。

init消息包含大圖像，因此init是一個大而緩慢的請求。 run消息更輕，服務器重用以前的圖像。 該服務器可以為多個客戶端提供服務。 通常，client＃1 init然后run多次。 如果client＃2進入init和init ，它將替換client＃1在服務器上發送的圖像。 並且由client＃1發出的進一步run將使用錯誤的圖像。 然后我問：

• 是否可以限制連接到隊列的數量？ 例如，服務器一次服務一個客戶端。
• 另一個選擇是：服務器將圖像綁定到客戶端，保存它們，然后在該客戶端運行時重新使用它們。 它需要更多的工作，並且如果兩個或多個客戶的請求緊密交錯，將會影響性能。
• 在每個運行請求中發送圖像不是一種選擇，這太慢了。

Answer 1

我認為您的設計有問題。 從邏輯上講，每個run對應於某個init因此必須將它們連接起來。 我將相關ID字段放入init和run事件中。 當服務器接收run它將檢查是否已處理了相應的init並使用該init的結果。

談到性能：您可以使init worker隊列並使多個處理服務器監聽它。 該示例在RabbitMQ文檔中。然后，當發出init請求時，一台可用的服務器將其拾取，並存儲您的圖像和相關ID。 如果您同時有多個init請求-沒問題，則最終將處理它們（如果服務器空閑則同時處理）

然后執行該過程的服務器將答復消息發送到客戶端隊列，說明init工作已完成，並發送必須發布run請求的隊列的名稱。

准備就緒后，客戶端會將其run請求發送到正確的隊列。

直接回答問題：

有一個常見的誤解，就是您發布到queue 。 在RabbitMQ的發布到一個exchange的是關心你的消息路由到多個隊列。 因此，您的問題真的變成了can I limit number of publishing connections to an exchange嗎？ 我很確定經紀人方面沒有辦法。 即使有限制連接數的方法，也可以想象一下情況：

1. Client1進來，推送其“ init”請求。
2. Client1保持其連接，等待推送run 。
3. Client1失敗或發生網絡分區，其連接被斷開。
4. Client2進入並推送其init請求。
5. Client2失敗
6. Client1重新啟動並推動其run並獲取Client2的映像。

連接是暫時的，不能作為事務處理機制來依賴。