何时通过扇出交换使用直接交换 [英] When to use direct exchange over fanout exchange

查看:105
本文介绍了何时通过扇出交换使用直接交换的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

据我所知,没有直接交换的适当用户案例,因为您可以使用扇出交换进行任何操作,只能扩展得多.

更具体地说,在阅读《 RabbitMQ in Action》 时,作者多次提到用例,例如:假设用户上传图片时需要生成缩略图.但是随后的营销也告诉您奖励上传照片的积分.使用RabbitMQ,您只需创建另一个队列即可,而制作人方面则无需任何工作!"

但是,如果您具有远见卓识,可以在生产者端创建一个扇出交换,那么这只是 .据我了解,直接交换无法完成此任务,仅在您实际上希望交换和队列之间紧密耦合时才适用(您不这样做,因为那是消息传递系统的重点.)

这是正确的还是实际的用例?

解决方案

与扇出交换相比,直接交换允许基于消息的路由密钥进行一些筛选,以确定哪些队列接收消息.使用扇出交换时,不会进行此类过滤,并且所有邮件都将进入所有绑定的队列.

因此,如果您与几个绑定有相同路由密钥的队列进行直接交换,并且所有消息都具有该密钥,那么您的行为与扇出交换相同.可以在RabbitMQ网站上的指南4 中对此进行更好的解释. >

在图片上传用例中,您可以使用:

  • 具有两个队列的扇出交换(一个用于缩略图工作人员,一个用于得分计算工作人员).路由密钥将被忽略.

    fanout-exchange
    |--> queue --> thumbnail-worker
    `--> queue --> score-worker
    

  • 再次与两个队列直接交换.例如,队列用image-processing键绑定,并且使用此键的邮件将同时排队到两个队列中.

    direct-exchange
    |--["image-processing"]--> queue --> thumbnail-worker
    `--["image-processing"]--> queue --> score-worker
    

    当然,在这种情况下,如果邮件的路由密钥与绑定密钥不匹配,则所有队列都不会收到邮件.

您不能将两个工作程序放在同一队列中,因为消息将在它们之间进行负载平衡:一个工作程序将看到一半的消息.

As far as I can tell, there is no proper user case for a direct exchange, as anything you can do with it you can do with a fanout exchange, only more expandably.

More specifically in reading RabbitMQ in Action the authors numerously refer to the use case that goes something like - "Suppose when a user uploads a picture you need to generate a thumbnail. But then later marketing also tells you to award points for uploading a photo. With RabbitMQ you just have to create another queue and do no work on the producer side!"

But that's only true if you've had the foresight to create a fanout exchange on the producer side. To my understanding a direct exchange cannot accomplish this and is only appropriate when you actually want tight coupling between exchange and queue, (which you don't, because that's the point of messaging systems.)

Is this correct or is there an actual use case?

解决方案

Compared to the fanout exchange, the direct exchange allows some filtering based on the message's routing key to determine which queue(s) receive(s) the message. With a fanout exchange, there is no such filtering and all messages go to all bound queues.

So if you have a direct exchange with several queues bound with the same routing key, and all messages have this key, then you have the same behavior as the fanout exchange. This is better explained in tutorial 4 on the RabbitMQ website.

In the image upload use case, you can use:

  • a fanout exchange with two queues (one for the thumbnail worker, one for the score computation worker). The routing key is ignored.

    fanout-exchange
    |--> queue --> thumbnail-worker
    `--> queue --> score-worker
    

  • a direct exchange with again two queues. Queues are bound with the image-processing key for instance, and messages with this key will be queued to both queues.

    direct-exchange
    |--["image-processing"]--> queue --> thumbnail-worker
    `--["image-processing"]--> queue --> score-worker
    

    Of course, in this situation, if the message's routing key doesn't match the binding key, none of the queues will receive the message.

You can't put the two workers on the same queue, because messages will be load balanced between them: one worker will see half of the messages.

这篇关于何时通过扇出交换使用直接交换的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆