Как отправить сообщения, чередующиеся из 2 очередей, в рабочие в RabbitMQ или Kafka? - PullRequest
1 голос
/ 18 мая 2019

Чтобы вычислить сложный алгоритм для огромного набора данных, мы хотим использовать MQ, такой как Kafka (или любой другой MQ, например Activemq или AMQP), для размещения двух очередей, каждая из которых представляет семантически разные части набора данных.Сообщения исходят от веб-службы, которая - на основе двух разных ролей пользователя - помещает их в правильную очередь.

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

Чтобы предотвратить некоторые проблемы с параллельными вычислениями, мы хотим, чтобы все работники одинаково работали либо с очередью 1, либо с очередью 2, но не смешивали работу над ними (поскольку это потребовало бы огромного количества блокировок и проверок и дополнительного доступа к базе данныхдля работы в очередях).

Внутри очереди порядок вычислений строго не требуется, но приветствуется.

Первая часть:

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

Вторая часть:

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

Третья часть (бонус):

Также мы не уверены, где мы должны накапливать результаты работников, чтобы отправить их в БД.Решение будет основано на использовании оперативной памяти, но при необходимости, где служба должна располагаться в архитектуре, которая извлекает дополнительные данные для текущих x сообщений из БД и позже помещает промежуточные и окончательные результаты обратно в БД?

Заключительные слова

Возможно ли это с Kafka или RabbitMQ или любым другим брокером?Где должен находиться наш планировщик с архитектурной точки зрения?

1 Ответ

0 голосов
/ 21 мая 2019

Сложные правила планирования лучше подходят для вашей инфраструктуры обмена сообщениями.

Было бы более гибко и проще реализовать этот планировщик как службу, которая получает сообщения от queue1 и queue2 в чередующихся пакетах, а затем повторнопоместите их в одну рабочую очередь для использования вашими работниками.

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

Для вашей последней части бонус , особенно если окончательные результаты получены в результате объединения этих данных (в отличие от одного результата для исходной задачи очереди), я не вижу причин, почему этиработники не могут напрямую записывать результаты в базу данных.

Это должно быть возможно при использовании в основном любого брокера сообщений;Определенно возможно как с RabbitMQ, так и с Kafka.

...