AMQP客戶可以是發佈商和訂閱者嗎？

我剛剛開始研究AMQP，我想知道如果我將它用於某些未設計的東西。這裏的東西像什麼，我想做的事：AMQP客戶可以是發佈商和訂閱者嗎？

客戶端A不會去了解它的業務並公佈它的狀態，一些交換（糾正我，如果我用錯誤條款的任何地方）。

ClientB連接到同一代理和「怎麼說出版商在這裏出版？我選擇了你， clientB。這是怎麼回事？」。

客戶端A說：「我的foo是吧，我的巴茲是真正的」

ClientB說：「OK。設置你的巴茲到假」

編輯用於不那麼抽象例如」

ClientA正在討論/收聽硬件設備，例如視頻投影機。當ClientB上線時，它想要找到 a如果投影機客戶端（如ClientA）已連接，然後知道投影機的狀態（即指示燈？），並且如果需要，還會更改狀態（關閉指示燈）。因此ClientA爲保持某種狀態（指示燈熄滅），並且可以在請求時發出，而呼叫也會響應來自交換機的命令，並將其轉換爲並將其傳遞給投影機（打開指示燈）。

來源

2011-04-12 tladuke

我發現很難按照你的例子，但它聽起來像你希望這些A和B類型之間有來回的對話。那是對的嗎？

AMQP更適合異步消息傳遞，並且添加您描述的點對點樣式要求您設置請求和回覆隊列，以便客戶端既可以發送也可以接收消息。客戶當然可以發佈和使用消息。

來源

2011-04-13 03:57:06

謝謝。可能的，但正確的工具？ – tladuke 2011-04-13 18:03:40

這真的很難說。你能詳細說明你的例子嗎？這會有很大的幫助。而不是「富」和「酒吧」，而是嘗試具體的事情。 – 2011-04-14 01:40:20

你的假設是非常正確的。我又增加了一個例子，但我不知道它有多大幫助。我沒有想過如何設置它。 – tladuke 2011-04-19 21:28:53

這是可能的，如果您的示例中的不同參與者是聯網設備，這是有意義的，因爲AMQP將提供鬆散耦合的消息傳遞方式。

需要注意的一件事是客戶B說「確定，設置一些屬性」的最後一條抽象線。這聽起來像是子例程調用返回一些值然後下一步發生的場景。 AMQP當然可以模擬這種RPC，但是當進程可以發送消息並且不必等待完成時，AMQP會更好。

如果你的大部分消息不涉及等待週轉回覆，那麼AMQP聽起來像是適合你正在做的事情。但是如果你的大部分需求都是RPC，那麼它可能不是最好的選擇。

當未來有可能性時，例如在您的場景中，如果您需要添加幾千臺投影儀，10,000個客戶端Bs和其他幾種需要交換狀態的設備類型，AMQP纔會真正發光。 AMQP的鬆耦合使得向代理添加其他應用程序變得很容易，只需聲明新的交換。

來源

2011-04-26 07:03:13

AMQP客戶可以是發佈商和訂閱者嗎？

回答

相關問題