1

我正在尝试为系统中的所有节点设置广播消息。当一个新节点加入系统时，它会向其他所有人发布消息以宣布其进入。我设计的方式是，存在一个所有节点都将绑定自己的队列的交换。每当一个新节点加入系统时，它都会将其队列绑定到交换器并向交换器发布消息。所有节点都会收到这个消息（包括它自己），所有其他节点（除了这个消息）都会发送一个“ack”消息，这样新节点就会知道系统中的可用节点。但不知何故，我无法让这个工作。我的广播消息不会传播到系统中的每个节点。一个简单的单节点发布和休息消耗正在工作。但是同一个节点的发布和消费在某个地方搞砸了。

除了上面提到的逻辑之外，还有其他有效的方法吗？或者从rabbitmq的角度来看是否有任何限制来实现上述目标，或者我的代码有问题，我是否必须仔细研究一下。

4

2 回答 2

1

按照您描述的方式，您的解决方案应该有效。但是，如果没有更详细的代码示例（“播音员”中的消费/发布逻辑和其他对等点中的消费/确认-发布逻辑），很难调试。

但是，一些常见问题可能会让您感到困惑：

  • 如果您正在考虑“我是否从所有其他节点得到响应”作为“其他节点是否收到我的公告消息？”的权威，您可能需要确认（basic.ack在 AMQP 中）您的播音员正在接收的消息得到他们。否则，由于消费者预取，您可能看不到后续消息，但在大多数客户端库中，您必须先在某个地方显式打开它。
    • 确保您的其他对等方（接收“通知”并发送回消息的对等方）也在确认消息，或者正在“无确认”模式下消费。否则，如果它们被阻塞（通过流量、速率限制或预取），它们可能会收到一段时间的通知，然后停止。
    • 确保您使用的是“扇出”类型的交换。听起来你想要无条件的扇出行为，所以你不需要搞砸主题路由。如果您使用主题或直接交换，您的路由逻辑中可能存在错误，在这种情况下切换到扇出将起作用。我怀疑你已经在这样做了。
    • 这可能不是问题，但是：您提到您的同行（不是播音员）正在“确认”该公告。确保他们通过直接将新消息发布回播音员的队列（没有交换，只有一个路由密钥）而不是通过发送 abasic.ack到 RabbitMQ（不通知发送者任何事情）来确认通知，而不是通过将收到的公告发布到 fanout 交换。

顺便说一句，我不知道您为什么要使用 declare-queue/bind/publish 而不是 publish/declare-queue/bind；您是否有充分的理由需要一个通知节点来接收自己的通知消息？如果您在进行“自测”行为，我认为最好只执行一个定期的“事情可以成功宣布吗？” 而是在某个地方进行健康检查，尽管这完全是主观的。

于 2018-01-29T15:06:40.637 回答
0

您是否尝试过带有您在广播消息的属性中标识的回调队列的 RPC 样式消息？就像在rabbitmq 教程中一样。

于 2013-09-17T14:52:04.967 回答