2015-06-19 58 views
1

我是新來的RabbitMQ,需要一些建議。我可以使用RPCClient進行扇出交換嗎?

我有一種情況,需要廣播一條消息,然後及時等待響應。換句話說,廣播消息期望在所有訂閱消費者的超時期限內作出響應。直接交換很簡單。我可以使用RPCClient等待響應。它如何與扇出交換一起工作?它會知道有多少用戶需要等待?或者在第一個響應之後它會成功返回?

如果創建扇出交換並在創建RPCClient對象時將其傳入。然後實現我自己的消費者,並且來自同一交換機和消費者的消費者消費者發送到相同的回覆隊列。它會起作用嗎?

請指教。謝謝!

回答

0

是的,它會工作。 RPC是一種模式(如果我們排除直接回復)不受限於直接交換。您可以將此模式應用於扇出交換。

而不是等待one reply,而是等待預期的回覆或直到到達timout。

預期回覆和扇出交換的知識通常是反對的。所以你只能依靠超時。

+0

我同意。但是RPCClient將如何工作?默認情況下,RPCClient只等待一個響應。所以我需要破解代碼並放入循環來執行響應檢索?這很混亂。如何在分佈式系統中完成心跳命令? –

0

這是你的問題:

廣播消息預計從所有訂閱消費者超時時間內做出答覆。

我加了重點來說明設計中的反模式。廣播背後的概念是廣播公司既不知道也不在乎誰在傾聽。通過爲廣播公司制定一個約束來了解誰在收聽,你已經有效地將廣播變成了一堆單播,但是卻試圖在沒有真正承認的情況下這樣做。

現在,讓我描述一個更可行的方案,而不使用單詞all

  1. 您通過扇出或話題交換髮送廣播消息。
  2. 消費者收到消息
  3. 消費者通過原始廣播消息中指定的直接交換向應答隊列發送新消息。
  4. 消費者從回覆隊列中讀取消息直到超時期結束。

希望所有的消費者都回復了,但是沒有辦法知道。如果消費者和廣播公司之間需要1對1的通信,則情況會變得更加複雜,廣播不再是合適的場所。

+0

我同意。我試圖更新一些以JMS編寫的遺留代碼,它看起來像使用主題隊列,就好像它是一個常規隊列。由於我沒有真正的測試用例,這使得它更難以理解。我沒有得到的部分是,當我創建一個RPCClient時,它在一個回覆隊列中偵聽。那麼現在,這個廣播的RPCClient將等待多個請求?或者我需要破解RPCClient? –

+0

如果我不使用現有的RPCClient類,我不知道如何最好地添加超時。你能建議嗎?謝謝。 –

+0

爲了解決您的第一條評論 - 我認爲您確實需要問您團隊/前任的問題,或者是要求您修改代碼的人,以瞭解您正在嘗試執行的操作。這聽起來很奇怪,這意味着他們試圖達到的基本目標可能是告訴你「怎麼」而不是「什麼」 – theMayer

相關問題