RabbitMQ 在主题交流中展开
RabbitMQ 还很新，我们仍处于调查阶段，看看它是否适合我们的用例——
我们很容易得出结论，我们想要的拓扑将让我们部署一些基于主题的交换，然后从那里过滤到特定队列。例如，假设我们有一个用户和一个上传交换，其中用户队列可能会收到主题为“新注册”或“好友请求”的消息，而上传交换可能会收到“视频上传”或“好友请求”等消息。 “图片上传”。
创建队列，将它们路由到适当的队列，然后构建侦听器来处理各个队列的消息，这非常简单。
然而，我不清楚是否可以在主题交换上进行扇出？
即，我已经命名了绑定到我的主题交换的队列，但我希望能够在这些队列中抛出大量侦听器实例，以防止单点故障。但据我所知，RabbitMQ 以直接的循环方式对待这些监听器——例如，每条第 N 个消息总是发送到同一个第 N 个监听器，而不是将消息分派给第一个可用的消费者。这对我们来说通常是可以接受的，但考虑到我们预期的负载，我们希望避免在我们的消费者群中出现热点的可能性。
那么，是否有某种方法，无论是在队列或交换配置中还是在消费者代码中，我们可以将侦听器指向主题队列，但以扇出方式处理侦听器？
Pretty new to RabbitMQ and we're still in the investigation stage to see if it's a good fit for our use cases--
We've readily come to the conclusion that our desired topology would have us deploying a few topic based exchanges, and then filtering from there to specific queues. For example, let's say we have a user and an upload exchange, where the user queue might receive messages where the topic is "new-registration" or "friend-request" and the upload exchange might receive messages like "video-upload" or "picture-upload".
Creating the queues, getting them routed to the appropriate queue, and then building listeners to handle the messages for the various queues has been quite straight forward.
What's unclear to me however is if it's possible to do a fanout on a topic exchange?
I.e. I have named queues that are bound to my topic exchange, but I'd like to be able to just throw tons of instances of my listeners at those queues to prevent single points of failure. But to the best of my knowledge, RabbitMQ treats these listeners in a straight forward round robin fashion--e.g. every Nth message always go to the same Nth listener rather than dispatching messages to the first available consumer. This is generally acceptable to us but given the load we anticipate, we'd like to avoid the possibility of hot spots developing amongst our consumer farm.
So, is there some way, either in the queue or exchange configuration or in the consumer code, where we can point our listeners to a topic queue but have the listeners treated in a fanout fashion?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，通过使用不同的队列名称绑定侦听器，它们将以扇出方式进行处理。
不过，扇出是 1:N，即每个任务可以像 pub-sub 一样传递给多个侦听器。请注意，这不仅限于扇出交换，而且如果您使用相同的绑定键将多个队列绑定到直接交换或主题交换，也适用。 （安装管理插件并查看其中的交换可能有助于可视化有效的绑定。）
您当前的设置是一个任务队列。每条任务/消息都精确地传递给一个工作人员/侦听者。在同一个队列名称上放置更多侦听器，它们将按照您所说的循环处理任务。使用“扇出”（一个主题的单独队列），您将多次处理一个任务。
根据您的平台，可能有满足您要求的现有工作队列解决方案，例如用于 Ruby 的 Resque 或 DelayedJob、用于 Python 的 Celery 或用于 JVM 的 Octobot 或 Akka。
Yes, by having the listeners bind using different queue names, they will be treated in a fanout fashion.
Fanout is 1:N though, i.e. each task can be delivered to multiple listeners like pub-sub. Note that this isn't restricted to a fanout exchange, but also applies if you bind multiple queues to a direct or topic exchange with the same binding key. (Installing the management plugin and looking at the exchanges there may be useful to visualize the bindings in effect.)
Your current setup is a task queue. Each task/message is delivered to exactly one worker/listener. Throw more listeners at the same queue name, and they will process the tasks round-robin as you say. With "fanout" (separate queues for a topic) you will process a task multiple times.
Depending on your platform there may be existing work queue solutions that meet your requirements, such as Resque or DelayedJob for Ruby, Celery for Python or perhaps Octobot or Akka for the JVM.
这是一个迟到的答案，但万一其他人遇到这个问题......
听起来您想要的是公平调度而不是扇出模型（它将向每个队列发布给定的消息）。
公平调度将向下一个可用的工作人员发送消息，而不是使用简单的循环方法。这应该避免您关心的“热点”，而不会将相同的消息传递给多个消费者。
如果这就是您正在寻找的内容，请参阅此内容中的“公平调度”部分Rabbit 文档中的页面。预取计数为 1 是这里的关键。
This is a late answer, but in case others come across this question...
It sounds like what you want is fair dispatch rather than a fan out model (which would publish a given message to every queue).
Fair dispatch will give a message to the next available worker rather than using a simple round-robin approach. This should avoid the "hotspots" you are concerned about, without delivering the same message to multiple consumers.
If this is what you are looking for, then see the "Fair Dispatch" section on this page in the Rabbit docs. A
prefetchcount of 1 is the key here.我不知道事实，但我强烈怀疑 RabbitMQ 会跳过未确认消息的消费者，因此它永远不会成为单个卡住的消费者的瓶颈。 FAQ 上的评论似乎表明 RabbitMQ 将努力让事情顺利进行即使面对麻烦的消费者。
I don't know for a fact, but I strongly suspect that RabbitMQ will skip consumers with unacknowledged messages, so it should never bottleneck on a single stuck consumer. The comments on their FAQ seem to suggest that RabbitMQ will make an effort to keep things chugging along even in the presence of troublesome consumers.