我刚刚开始研究AMQP，我想知道我是否会将它用于它不适合的东西。这就像我想做的事情：
ClientA确实关注它的业务 并将其状态发布给某些人 交换（如果我使用，请纠正我 错误的条款任何地方）
ClientB连接到同一个代理 并且“说出版商是什么 在这里发布？我选择你， clientB。发生了什么事？“。
ClientA说：“我的foo是酒吧和我的baz 是真的“
ClientB说“好的。把你的巴兹设置为 假“
编辑一个不太抽象的例子“
ClientA会话/收听硬件 设备，比如视频投影仪。什么时候 ClientB上线，它想找到 任何投影机客户（如ClientA） 连接然后知道 投影仪的状态（是 灯开？）并且如果需要，也改变状态 （关闭灯泡）。所以ClientA是 保持一些状态（灯关闭）和 可以在要求时发送，并且 call也响应来自的命令 交换和转换并传递给他们 投影机（打开灯泡）。
答案 0 :(得分：1)
我发现很难效仿你的例子，但听起来你希望这些A和B类型之间能够相互进行来回交谈。这是对的吗？
AMQP更适合异步消息传递，并且要添加您所描述的点对点样式要求您设置请求和回复队列，以便客户端可以发送和接收消息。客户端发布和使用消息当然是可能的。
答案 1 :(得分：1)
这是可能的，如果您的示例中的不同参与者是联网设备，那将是有意义的，因为AMQP将提供松散耦合的消息传递方式。
需要注意的一件事是客户B说“好的，设置一些属性”的最后一个抽象线。这听起来像一个子程序调用返回一些值然后下一步发生的情况。 AMQP当然可以模拟这种RPC，但是当进程可以发送消息而不必等待完成时，它可以更好地工作。
如果您的大部分消息都不涉及等待周转回复，那么AMQP听起来很适合您正在做的事情。但如果您的大部分需求都是RPC，那么它可能不是最佳选择。
如果您需要添加几千个投影仪，10,000个客户端B以及其他一些还需要交换状态的设备类型，那么在未来可能性的情况下，AMQP会非常闪耀。通过宣布新的交换，AMQP的松散耦合使得向代理添加其他应用程序变得容易。