如何在RabbitMQ中实现循环主题交换

我知道在主题交换中实现循环行为可能很棘手或不可能，所以我的问题实际上是，我是否可以从RabbitMQ中了解到什么，或者看看其他支持这种行为的消息队列

以下是我的申请要求的详细说明：

将有一个制作人，我们称之为

P

可能会有成千上万的消费者，让我们称他们为

Cn

每个消费者可以“订阅”一个或多个主题交换，多个消费者可以订阅同一主题

发布到主题中的每条消息只能由一个使用者使用

用例#1

假设：

话题

• foo.bar

• foo.baz

消费者

• 消费者

  C1

  已订阅主题

  #

• 消费者

  C2

  已订阅主题

  foo.*

• 消费者

  C3

  已订阅主题

  *.bar

制作人

p

发布以下消息：

发布

foo.qux

：

C1

和

C2

可能会使用此消息，但只有一个人会收到它

发布

foo.bar

：

C1

，

C2

和

C3

可能会使用此消息，但只有一个人会收到它

注 不幸的是，我不能为每个“主题”设置单独的队列，因此使用

直接交换

不起作用，因为主题组合的数量可能很大（成千上万）

据我所知，RabbitMQ没有现成的解决方案。是否有人知道一种变通方法，或者有另一种消息队列解决方案支持这种方法，例如Kafka、Kinesis等

---

谢谢

看来，交换的作用是路由消息，而队列的作用是为等待处理的消息提供等待位置。将消息导入一个或多个队列是exchange的工作，而将消息从队列导入多个使用者是队列的工作。循环赛只对后者起作用

基本上，

主题

交换通过复制消息进行操作，每个队列对应与消息发布的主题。因此，任何对循环行为的期望都是错误的，因为它违背了

主题

交换的定义

所有这些都是为了证明，根据定义，问题中提出的情景没有意义。这并不意味着期望的行为是不可能的，但术语和拓扑结构可能需要一些明确的调整

让我们退一步，看看一条消息所描述的生命周期：它只由一个生产者生产，由许多消费者中的一个消费。通常情况下，这是直接交换解决的方案。其中的复杂因素是，您的消费者对他们将使用的消息类型是有选择性的（或者，换句话说，您的生产者对其生成的消息类型不一致）

通常在面向消息的处理中，单个消息类型对应于单个使用者类型。因此，每种不同类型的消息都将获得自己相应的队列。但是，根据本问题中给出的描述，单个消息类型可能对应于多个不同的使用者类型。我的一个问题是以下声明：

不幸的是，我不能为每个“主题”设置单独的队列

从表面上看，这句话毫无意义，因为它真正说的是你有任意多（事实上，数量未知）的消息类型；如果是这样的话，那么您将如何编写代码来处理它们呢

因此，暂时忽略该语句，我们将看到RabbitMQ开箱即用的两种可能性：

使用直接交换并使用邮件类型作为路由密钥发布邮件。然后，让您的各种消费者只订阅他们可以处理的消息类型。这是最常见的消息处理模式

如您所做的那样，使用主题交换，并提出某种外部重复数据消除逻辑（可能是memcached），在这种逻辑中，消息将根据主题交换进行检查，如果另一个使用者已经开始处理，则会被丢弃

---

现在，这两个都没有明确涉及循环要求。由于没有解释这一点为何重要或如何重要，因此假定可以忽略这一点。如果没有，则需要进一步定义问题空间。

虽然我理解这个问题，并且发现它在理论上非常有趣（这可以说是100%足够提出这个问题），但我也很好奇这个问题的用例。在我看来，主题交换的目的是发布关于“主题”的消息，并让“人们”对接收它的某种类型的消息感兴趣。我不认为从主题交换中“生产/消费”有什么用处，但我肯定错了。就我个人而言，除了使用一些数据存储推迟获胜消费者的选举外，我看不到任何其他办法。我可能错了，我对卡夫卡和动觉知之甚少。我的观点是：如果必须通知所有（或部分）消费者消息已发送，那么就使用主题交换。如果只有一个消费者必须以生产者/消费者的方式使用消息，则使用直接或扇出交换。如果你两个都需要，两个都用！向两家交易所发布。但是这并不能解决问题，事实上，因为你会有错误的消费者消费。顺便说一句，虽然我不是卡夫卡专家，但我99%肯定这不会有帮助（甚至会更糟），因为它根本没有路由的概念。无论好坏，它都是酒吧/酒吧，这意味着它对制片人/消费者的东西都没有帮助