Spring Cloud Stream RabbitMQ на основе многораздельной и параллельной обработки

Question

Я создаю прототип приложения, которое получает от клиентов долгосрочные задания, которые они могут приостановить и возобновить через Интернет. Каждое задание содержит тысячи элементов, которые должны обрабатываться с определенной скоростью в минуту. Задание становится недействительным через x часов, поэтому вся работа с остальными элементами может быть прекращена.

Пример сценария -

Customer A uploads job 1 with 10000 elements

Customer A uploads job 2 with 5000 elements   

Customer A uploads job 3 with 8000 elements 

Customer B uploads job 4 with 50000 elements 

Customer B uploads job 5 with 1000 elements 

Customer C uploads job 6 with 200000 elements 

Каждое задание может быть выбрано для запуска с разными уровнями пропускной способности, например, максимум 10, 20 или 30 элементов в минуту. И каждая работа может быть приостановлена ​​и возобновлена ​​заказчиком.

Я оцениваю Spring Cloud Stream RabbitMQ для разработки основного механизма обработки заданий.

Как лучше всего сконструировать это так, чтобы каждое задание распределялось и обрабатывалось одновременно?

Должен ли я изучать создание динамических потребителей для каждой работы или иметь отдельные сообщения опроса потребителей по идентификатору работы?

В реальной системе могут существовать сотни одновременных заданий с совокупными элементами в миллионах.

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

Answer 1

Я не могу сейчас создать фрагмент кода, но вот как я это реализовал (и реализовывал подобные сценарии в прошлом):

1. Иметь услугу (назовем ее requester), которая заполняет очередь с выбранной скоростью, со всеми указанными вами опциями паузы / возобновления / тайм-аута.
2. Предполагая, что элементы для всех заданий обрабатываются одинаково, пусть все они идут в одну очередь с заголовком, идентифицирующим клиента.
3. Иметь масштабируемый микросервис (давайте назовем его processor) извлекать из очереди как можно быстрее (поэтому очередь всегда должна быть почти пустой) и возвращать результат в очередь ответов вместе с клиентом. заголовок.
4. Имейте масштабируемый микросервис (давайте назовем его responder), слушайте очередь результатов и делайте с результатом все, что вам нужно (сохранить в БД, уведомить клиента, журнал и т. Д.).

Этот тип настройки гарантирует, что скорость контролируется requester, который, в свою очередь, контролируется клиентом в соответствии с вашей спецификацией, а все другие услуги (processor, responder) масштабируются в зависимости от нагрузки. генерируется им.