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

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

Извините, если я использую здесь неправильную терминологию.

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

  1. Я думал, что один из способов может состоять в том, чтобы иметь совершенно отдельный сервис для каждого, тогда, если большие задачи будут выполнены, он может начать потреблять из небольшой очереди. (см. изображение ниже) Однако это казалось проблематичным с доставкой «по крайней мере один раз» и, возможно, другими проблемами.

  1. Я подумал, что отдельный способ может заключаться в том, чтобы иметь как в одной службе, так и в одной и той же базе данных, но использовать шаблон обмена сообщениями «входящие», чтобы большой ящик читал другой «входящий ящик», если в нем не было сообщений по умолчанию. Что мне показалось странным в этом, так это то, что разные экземпляры в одной и той же службе будут настроены по-разному. Это не то, что я делал раньше, поэтому для меня это пахнет рыбой.

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

Есть ли «типичный» способ решения этой проблемы? Должен ли я просто избегать всего этого вместе и просто забыть о попытках заставить «большую службу задач» обрабатывать небольшие задачи?

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

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

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

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

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

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


LetsCodeIt, 5 января 2023 г., 05:44