message-queue - 消息困惑: Pub/Sub vs Multicast vs Fan Out

标签 message-queue messaging rabbitmq publish-subscribe amqp

我一直在评估我公司的消息传递技术,但我对几个术语之间的概念差异感到非常困惑:

Pub/Sub vs 多播 vs 扇出 我正在使用以下定义:

  • Pub/Sub 让发布者将每条消息的单独副本发送给 每个订阅者都意味着存在保证交付的机会
  • 扇出有一个队列推送到所有监听 客户。
  • 多播只是发送垃圾数​​据,如果有人正在监听 那么好吧,如果没有,也没关系。无法保证客户端一定会收到消息。

这些定义正确吗?或者 Pub/Sub 模式和多播、直接、扇出等实现该模式的方法吗?

我正在尝试将开箱即用的 RabbitMQ 定义应用到我们的架构中,但目前我只是在原地踏步,试图为我们的应用程序编写规范。

请有人告诉我我的说法是否正确?

最佳答案

我对您选择的三个术语进行比较感到困惑。在 RabbitMQ 中,Fanout 和 Direct 是交换类型。 Pub-Sub 是一种通用消息传递模式,但不是交换类型。你甚至没有提到第三种也是最重要的交换类型,即主题。事实上,您只需声明具有相同绑定(bind)键的多个队列即可在主题交换上实现扇出行为。您可以通过使用 * 作为通配符绑定(bind)键声明队列来定义主题交换上的 Direct 行为。

发布-订阅通常被理解为一种应用程序发布消息并由多个订阅者使用的模式。

对于 RabbitMQ/AMQP,重要的是要记住消息总是发布到交换器。然后交换路由到队列。队列将消息传递给订阅者。交换的行为很重要。在主题交换中,来自发布者的路由 key 与来自订阅者的绑定(bind) key 相匹配,以便做出路由决策。绑定(bind) key 可以具有通配符模式,这进一步影响路由决策。更复杂的路由可以done based on the content of message headers使用 header 交换类型

RabbitMQ 不保证消息的传送,但您可以通过选择正确的选项(持久消息的传送模式 = 2)并在运行应用程序之前声明交换和队列来保证消息的传送,以便消息不会被丢弃。

关于message-queue - 消息困惑: Pub/Sub vs Multicast vs Fan Out,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8261654/

相关文章:

message-queue - MassTransit:契约(Contract)类的模式和实践

php - 如何安排电子邮件发送

ruby - 使用 EM-HTTP 消费队列 : unable to create new socket: Too many open files

Java - MDB - 如何避免并发问题

JMS 消息重新传递延迟

ios - 在 iOS 中创建消息屏幕

java - Spring websocket 和消息传递支持有多成熟?

apache-kafka - Kafka 如何保证消费者跨分区处理的消息顺序?

python - 使用鼠兔的 start_consuming 方法中断线程

rabbitmq - RabbitMQ 中的 celeryev 队列变得非常大