直接和扇出交换的需求是什么？
根据我的理解，直接和扇出交换的所有功能或用例都可以使用主题交换来实现。主题交换支持功能超集。那么问题来了，为什么 RabbitMQ 有直接和扇出式交换？是否有任何用例可以使用直接/扇出交换来实现，但不能使用主题交换来实现？
共有2个答案
你可以用主题交换来替换直接和扇出的功能，但你也可以实现一个大的“动物”类，而不必费心实现“猫”和“狗”类......
不同的交易所类型根据您的需求提供特异性。您可以使用主题交换进行广播，但是您需要强制每个客户端了解#的含义，并要求他们在绑定时使用该路由密钥;或者只是使用扇出交换。
在实现方面，实现主题交换有点复杂，需要一个数据结构，要求更多的簿记，而不是普通的扇出或直接交换。
我会说这是一个简化的问题。例如，如果您只需要一个拓扑，其中每个特定的路由密钥与一个队列1:1映射（RabbitMQ文档中引用了同一应用程序中多个工作人员之间的任务循环分配），那么直接交换可能更易于使用和处理，这就是您所需要的。这并不是说你不能用主题交换来完成同样的事情（你可以）。
同样，对于Fanout交换，如果您有需要简单地广播消息的情况，您可能会发现Fanout交换更容易使用。同样，这并不是说你不能使用主题交换来完成同样的事情（你可以）。
我通常只使用主题交换，因为我重视它们提供的灵活性。随着应用程序的扩展，它们可以在同一交换中处理更多种类的用例，而其他两种类型可能不是这种情况。因此，我可以避免随着应用程序的增长而不得不在中游更改拓扑的可能性。
正如RabbitMQ文档中关于主题交流的陈述:
主题交换具有非常广泛的用例集。每当问题涉及多个有选择地选择要接收的消息类型的使用者/应用程序时，应考虑使用主题交换。
关于这些概念的更多信息，包括插图，这个页面有相当多的信息:https://www.rabbitmq.com/tutorials/amqp-concepts.html
-
我一直在尝试使用RabbitMQ，但遇到了以下问题（与此非常类似：RabbitMQ中的主题交换与直接交换）。 我需要密集地广播大约800种类型的消息（因此每种消息类型都会有很多消费者），我想知道以下哪种方法更好： > 创建一个直接交换，在该交换中，消息将使用路由密钥（消息类型名称）发送，每个消费者都将通过绑定了相应路由密钥的临时队列连接到该交换。（因为没有像“key1.key2.*”这样复杂的路由
-
我能够使用Publish/SubscribeRabbitMQ Java教程创建扇出交换，任何连接的使用者都将收到一个消息的副本。我想在连接任何使用者之前创建交换和绑定，而不是动态/编程地声明交换和绑定。我已经通过RabbitMQ管理控制台完成了这一点。然而，由于某种原因，我的消费者以循环方式接收消息，而不是全部接收消息的副本。我错过了什么？下面是一些代码片段： 发布者： 消费者： ...在Rabb
-
AMQP/RabbitMQ新手。试图掌握概念/原则，并偶然发现了这一点。 以下两种范式之间有什么区别？ Fanout Exchange：FanoutExchange- 相对 直接交换:直接交换- 两者不是都达到相同的效果吗？如果没有，请有人可以阐明它有什么不同，以及在哪些情况下比其他情况更可取？ 为什么它们有这两种类型的交换，而这两种交换都可以通过调整绑定中的路由键来实现？ 谢谢
-
我正在使用RabbitMQ，我对使用扇出交换和类的（或)方法感到困惑。 例如，我有两个持久队列的使用者QUEUE-01和QUEUE-02，它们绑定到持久扇出交换fanout-01。并将1个发布服务器发送到FANOUT-01。我理解当消息使用（或)方法发布时会发生什么，消息将被复制到每个队列并由每个使用者处理。但我不确定如果我将调用方法会发生什么？我会从哪位消费者那里得到回复？有什么特别的行为吗？我
-
在我的应用程序中，我使用spring cloud stream集成Rabbit MQ。默认情况下，spring cloud streams将目标创建为Rabbit MQ中的交换类型主题。如何配置spring cloud stream以创建fanout类型的交换？
-
我们有一个队列和交换集群来支持消息。 null 我们每个队列都有一个交换，以便在重试超时期间后将重试的消息发送回特定的队列。 在这个场景中，我们有3个交换（“foo-exchange”、“foo-exchange-dead”、“baz-exchange-retry（每个队列1个fanout exchange）”和3个队列（“baz-queue”、“baz-queue-delay”、“baz-que