Rabbitmq: 谁来创建 Queue 和 Exchange

2022-05-05 15:14:11 浏览数 (1)

**Rabbitmq: 谁来创建 Queue 和 Exchange**

文章目录

  • 原文地址
  • 译文
    • 1. 区分责任
    • 2. 生产者创建一切
    • 3. 消费者创建一切
    • 4. 两者都不创建任何东西
    • 总结

原文地址

原文地址: link 水平有限, 翻译的不准确的地方请多多指出来~

译文

消息传递是任何一个分布式系统中的基本的组成部分. 它允许一个生产者发送一段消息给任意数量的消费者, 并且不必要知道任何关于消费者信息. 这对真正意义上的异步和解耦通信有很大的帮助

当你使用 RabbitMQ 的时候, 上面的示图展示了很基础但很典型的一种结构. 一个生产者给交换机发送一段消息. 交换机根据路由逻辑, 把消息放到绑定该交换机的队列里面. 更近一步说, 如果是一个广播类型的交换机, 这个消息的复制会重复的发送给每一个队列. 一个消费者随后可以接收并处理这个消息.

对于上面这种结构能够工作即生产者和消费者能够成功运行的一个很重要的猜想是, 所有 RabbitMQ 的组件(即 队列, 交换机和绑定关系)必须事先创建好. 一个消费者不能给交换机发送消息如果这个交换机不存在的话, 一个消费者同样也不能从一个不存在的队列中处理消息.

因此, 这个并不是难理解的, 在生产者/消费者发送消息/接收消息之前,让一个生产者/消费值去创建队列, 交换机和绑定关系. 让我们看一看这个如果去做即每一种方式的优缺点.

1. 区分责任

图片翻译(1.生产者创建交换机 2. 消费者创建队列并把队列绑定到交换机上)

为了让生产者和消费者充分的解耦, 理想情况下, 生产者仅仅知道关于交换机的信息(而不是队列), 并且消费者仅仅知道关于队列的信息(而不是交换机). 绑定关系表明交换机和队列的关系

一种可能能方式是让生产者处理交换机的创建, 消费者创建队列并将队列绑定在交换机上. 这种去耦合的方式的优点是, 如果消费者需要队列, 仅仅是按照需求, 简单的创建队列并绑定它们就可以了, 并不需要让生产者知道任何关于队列的信息. 但这并不是充分的解耦: 因为消费者为了绑定必须要知道这个交换机.

2. 生产者创建一切

在生产者运行的时候, 可以配置去创建所有需要的组件(交换机, 队列和绑定关系). 这种方式的好处是, 没有消息会丢失掉(因为队列已经创建好并绑定到交换机上了, 并不需要让任何消费者先启动).

然而, 这就意味着, 生产者必须要知道所有需要和交换机绑定的队列. 这是一种耦合度很高的方式. 原因是每次需要添加新队列的时候, 生产者必须要重新配置和部署以用来创建队列和绑定队列

3. 消费者创建一切

相反的方式是, 在消费者运行的时候, 让消费者去创建它需要的交换机, 队列和绑定关系. 和前一种方式一样, 这种方式产生了耦合, 因为消费者必须要知道它们要绑定队列的交换机的信息. 交换机如果有了任何改动(例如重命名), 意味着所有的消费者必须要重新配置和部署. 当存在大量队列和消费者时, 这种复杂性可能会令人望而却步.

4. 两者都不创建任何东西

一个完全不同的方法是既不让生产者也不让消费者去创建任何要求的组件. 相反, 它是事先使用管理插件的用户界面或管理 CLI 去创建. 这种方式由下面几种优点:

  • 生产者和消费者可以完全的解耦. 生产者知道的仅仅是交换器, 消费者知道的仅仅是队列.
  • 这可以很容易地作为部署管道的一部分进行脚本化和自动化
  • 任何更改(例如新的队列)都可以添加, 而不需要触及任何现有的, 已经部署的发布者和消费者

总结

在分布式系统中, 异步消息是一种很有用的方式实现解耦, 但是为了保持它们解耦, 维护底层消息传递结构(在RabbitMQ中, 这些是队列、交换和绑定) 的有效策略是必要的.

虽然发布者和使用者服务可能自己负责创建它们需要的内容, 但在初始消息丢失、耦合和操作维护(在配置和部署方面) 方面可能会付出沉重的代价

最好的方法可能是在它所属的地方处理消息传递系统配置: 在应用程序之外编写脚本. 这确保了服务保持解耦, 并且队列系统可以根据需要动态更改, 而不必影响大量现有服务。

0 人点赞