阅读常见消息排队系统（例如RabbitMQ，ActiveMQ）的文档，似乎负载平衡始终由排队系统（循环）或生产者使用消息上的多个队列或属性来完成。然而，在我们的应用程序中，没有人，甚至消费者都知道处理消息需要多长时间。它可以在几毫秒到几小时之间（它基本上计算任意输入x上的任意函数f）。因此，消费者应该执行负载平衡，因为他们只接受消息，如果他们正在加载＆＃34;低于阈值（负载可以是执行作业的数量，CPU负载等）。理想情况下，生产者将消息放入队列中，消息是＆＃34;提供＆＃34;对所有消费者而言，但只有一个消费者接受并处理消息。甚至可能发生这样的情况，即消费者在第一轮中没有接受它并且它会留在队列中直到一个消费者拥有免费资源。 所以可能有疑问：这是否可能与任何常见的消息排队系统有关，或者我们是否朝错误的方向看？
答案 0 :(得分：1)
由于这些系统的性质，这是可以实现的，没有任何真正的额外工作。在RabbitMQ中，您可以设置prefetch size，它指定要提前获取的作业数。您将此设置为0，以便每个消费者一次只能拥有一个作业。您希望将此功能与消息确认结合使用，以便消费者在收到消息之前必须提供消息。
所有空闲的消费者将排队等待作业，MQ将按FIFO顺序将作业假脱机。一旦他们完成了他们的工作处理，他们就会确定它并且MQ为他们提供队列中的下一个工作。如果没有消费者闲置并为作业做好准备，那么消息就会排在队列中，直到消费者可用。