我刚刚开始研究 AMQP，我想知道我是否会将它用于它不是为它设计的东西。这是我想做的事情：
ClientA 确实在做自己的事 并将其状态发布给某些人 交换（如果我使用 任何地方的错误术语）。
ClientB 连接到同一个代理 和“说出版商是什么 在这里发表？我选择你， 客户 B.怎么回事？”。
ClientA 说“我的 foo 是 bar 而我的 baz 是真的”
ClientB 说“好的。将您的 baz 设置为 假”
编辑一个不太抽象的例子”
ClientA 通话/收听硬件 设备，比如视频投影仪。什么时候 ClientB上线，想找 任何投影仪客户端（如 ClientA） 连接然后知道 投影机的状态（是 灯亮着？），如果需要，还可以更改状态 （关灯）。所以 ClientA 是 保持某种状态（灯熄灭）和 可以在请求时将其发送出去，并且 呼叫也响应来自的命令 交换和转换并将它们传递给 投影仪（打开灯泡）。
【问题讨论】：
标签： amqp
我发现很难效仿您的示例，但听起来您希望这些 A 型和 B 型彼此之间进行来回对话。对吗？
AMQP 更适合异步消息传递，并且要添加您所描述的那种点对点样式，您需要设置请求和回复队列，以便客户端可以发送和接收消息。让客户端同时发布和消费消息当然是可能的。
【讨论】：
这是可能的，如果您的示例中的不同参与者是联网设备，这将是有意义的，因为 AMQP 将提供一种松散耦合的消息传递方式。
需要注意的一点是客户端 B 说“好的，设置一些属性”的最后一个抽象行。这听起来有点像子程序调用返回一些值然后进行下一步的场景。 AMQP 当然可以模拟那种 RPC，但是当进程可以发送消息并且不必等待完成时，它会更好地工作。
如果您的大部分消息传递不涉及等待周转回复，那么 AMQP 听起来很适合您正在做的事情。但如果你的大部分需求是 RPC，那么它可能不是最佳选择。
当有未来的可能性时，AMQP 确实会大放异彩，例如在您的场景中，如果您需要添加几千个投影仪、10,000 个客户端 B 以及其他几种也需要交换状态的设备类型。 AMQP 的松散耦合使得向代理添加其他应用程序变得容易，只需声明新的交换即可。
【讨论】：