是否应该在RabbitMQ中多次声明交换或队列？

Question

我与我的同事在Server A和Server B之间讨论RabbitMQ设计，这里是流程图如下。

Server A通过exchange A和Queue B将消息发送到Server B，并从通过Server BQueue A接收消息。反之亦然Server B。

在Server A中有两个类，用C++实现;一个是sender，另一个是receiver。使用JavaScript实现的Server B的代码结构相同。

对于sender和receiver在Server A。我的同事的想法是：

• 在发件人的初始化：
  • 创建rabbitmq
  • 连接声明exchange A
  • 声明Queue B
  • 绑定的关键是Queue B
• 最初化在接收器：
  • 创建rabbitmq
  • 连接声明exchange B
  • 声明Queue A
  • 结合的关键Queue A

同样的逻辑在Server B。

不过，我不认为Queue B和Exchange B应该在Server A声明。它们应在Server B中声明。

最后，我遵循我的同事的想法实施它，因为他之前做过一些相关的工作。

---

今天，Server A在功能amqp_queue_declare在Sender模块测试期间挂起，但重新启动后RabbitMQ效果很好。所以我怀疑我的同事想要初始化Sender。

我的想法：

• Server A
  • 在发件人
    • 创建rabbitmq
    • 连接的初始化声明Exchange A
  • 在接收器中的初始化
    • 创建rabbitmq
    • 连接创建Queue A
    • 结合的关键Queue A
• Server B
  • 在发件人初始化
    • 创建rabbitmq
    • 连接声明Exchange B
  • 初始化在接收机
    • 创建rabbitmq
    • 连接创建Queue B
    • 结合的关键Queue B

有人能告诉我有什么不对我的想法？还是有更好的解决方案？

---

编辑：从@Sigismondo

• 回答问题做所有需要被交付给消费者A/B的消息？

  没有

• 没有消费者A/B需要的情况下，通知的一些消息是失去了什么？

  不，我想知道消费者A如何知道消息丢失了？

• 在消费者A/B无法到达的情况下，预期行为是什么？

  如果消费者A不可达，则生产者B不会向A发送任何消息，反之亦然。 B怎么可能知道消费者A不可及？

  目前，在我的系统中，每条消息都有缺陷。所以B在前一种情况下不能从A得到答复，则B不会将消息发送给A.

• 如果生产者A/B停机，预期行为是什么？

  如果生产商B是下跌，那么A将不会收到来自B.所以任何消息将不会发送任何信息给B.

Answer 1

这是完全合法的，这两个服务器的申报队列和交换，在处理指定队列时通常是首选方法：通常是您希望生产者和消费者分离，并让队列和交换都声明（即：创建，如果缺少），您让两者都正确工作，并且您拥有即使在RabbitMQ全新安装中，也保证不会丢失任何消息，以防对方尚未启动。

尤其是很重要的：

• 消费者宣布，从必须消费信息（或将不能够从他们那里消费）队列。

• 生产者声明队列和的交流于此，它产生之前产生消息（否则将被丢失，在没有的情况下消费者已经创建了队列）。

这是使用命名队列时使用的典型方法，看起来你在这里做什么。

现在，如果您希望在消费者不在的情况下忘记消息，那么生产者将不会声明任何队列：消费者可以创建temporary queue并将其绑定到交易所。

最后，如果是这种情况，并且您希望在没有消费者的情况下收到通知（并且没有绑定到交换机的队列），则可以使用alternate exchanges。

所以，你会看到：有一些选项可以使用，但每个选项都有一个基本原理：你必须根据具体问题选择使用哪一个 - 而且这还没有被你的解释：即使非常详细，它缺少一些方面：

• 做所有消息需要传递给消费者的A/B？
• 消费者A/B是否需要通知，以防一些消息丢失？
• 消费者A/B无法到达的情况下的预期行为是什么？
• 如果生产商A/B出现故障，预期行为是什么？

然而amqp_queue_declare不应该挂在所有的：如果这是你面临的一个错误的情况下，或我不知道，但这不是它的预期的行为，据我所知。