Архитектура пула воркеров с разной сложностью задач и размерами ящиков

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

Работа разделена на «классы», но это различие выражается только в элементе записи базы данных в одной общей таблице базы данных. Все входящие единицы работы помещаются в одну и ту же таблицу, каждая из которых имеет идентификатор класса.

Каждый монитор задач снабжен списком выбора приоритетного класса. Например, список «ABC» означает, что он сначала выберет единицу работы класса A, если она есть, затем «B» и так далее. В режиме реального времени в атомарной транзакции базы данных он выбирает из списка и затем требует первого. «Маленький» сервер может вообще не иметь буквы «А» в своем списке.

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

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

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