Лучший доступный работник вместо кругового

Question

Я реализовал рабочую очередь на основе rabbitmq примера 2 с qos и ack. Все отлично работает, даже приоритеты работы.

Но сами рабочие места очень зависят от локальности данных. Например, у меня есть эти серверы:

1. работник1 с хранилищем
2. работник2 с хранилищем
3. работник3 без хранения
4. работник3 без хранения

Задания относятся к данным, хранящимся на работниках с хранилищами, например

{ 
   job_id: 1,
   data: "worker2/pool5/dataset7"
}

Мне нужно отправить это сообщение на worker2, если оно доступно, в противном случае оно должно быть отправлено следующему доступному работнику. Поэтому в основном мне нужна конфигурация маршрутизатора, которая могла бы учитывать локальность данных

Что мне использовать?

Answer 1

Спасибо за ответ.

Под «работник недоступен» я имел в виду «все работники на этом сервере заняты обработкой заданий».

Создайте разные очереди для каждого неидентичного потребителя и обновите логику маршрутизации, чтобы в каждой очереди появлялись только соответствующие сообщения.

Единственная проблема, о которой производитель не знает, это наличие работника (способного обрабатывать задания).

Я постараюсь объяснить.

У нас есть несколько серверов, каждый из которых содержит большой объем данных. Объем данных, обрабатываемых за одно задание, велик - от 100 ГБ до нескольких ТБ на одно задание, поэтому потоковая передача их даже по сети 10 ГБ не очень быстрая.

В настоящее время все наши работники равны и потребляют задания из одной очереди, используя qos и ack, используя сетевые ресурсы.

Итак, мы думаем о том, чтобы расставить приоритеты для работников, которые могут обрабатывать данные без их потоковой передачи.

Answer 2

Существует некоторое фундаментальное предположение при потреблении из определенной очереди, что все работники, потребляющие из очереди, идентичны - один и тот же код, то же оборудование и т. Д. Когда это предположение нарушается, вы вносите некоторую контролируемую изменчивость в ваш система, и изменчивость обычно приводит к нестабильности и плохим результатам.

Таким образом, я думаю, что для вашей цели у вас есть два возможных пути решения:

1. Изменить потребителей так, чтобы они были идентичны, включая идентичный доступ к любому конкретному хранилищу, или
2. Создайте отдельную очередь для каждого неидентичного потребителя и обновите логику маршрутизации, чтобы в каждой очереди появлялись только соответствующие сообщения.

Помимо этого, есть некое смутное понятие «если работник недоступен» - я не уверен, что это значит. В RabbitMQ существует множество понятий «доступность», и, хотя брокер может справиться со многими из них, издателю обычно считается плохой практикой проектирования, чтобы точно знать, когда и как используется каждое сообщение. Если бы вы могли дать какое-то разъяснение, я мог бы обновить свой ответ.