Когда я реализовал очень схожую работу (для производственной системы), я закончил тем, что каждый сервер выбирал типы заданий случайным образом. Это было мое рассуждение -
перенасыщение работ от одного пользователя не должно влиять на возможность других пользователей, имеющих свои рабочие места запуска (пользователь-пользователь справедливости)
перенасыщение одного jobtype не должно повлиять на шансы других jobtypes запускаемых (пользователь-работа и работа-работа справедливости)
, если есть только один jobtype от одного пользователя в ожидании запуска, все серверы должны быть запущены эти рабочие места (не впустую мощности)
система должна выполнять задания «справедливо», т. Е. Пропорционально количеству ожидающих пользователей и типам рабочих мест, а не общим ожиданиям (большой объем одного типа рабочих мест не должен вызывать расписание в пользу его) (справедливость по типу работы)
количество серверов может отличаться и не известно заранее
Ожидаемые задания, типы рабочих мест и метаданные пользователей известны планировщику, но не данные о задании (то есть имена пользователей, имена рабочих мест и подсчеты, но не полезная нагрузка)
Я также хотел, чтобы каждый сервер был автономным, чтобы запланировать собственную работу автономно, не имея необходимости знать о г-серверы
Решение я остановился на том, чтобы отслеживать ожидания рабочих мест их {пользователем, jobtype} атрибут кортежа, и имеют каждый шаг планирования случайным образом выбрать 5 кортежи и от каждого кортежа до 10 заданий для запуска следующего , Выбранные задания были внесены в короткий список, чтобы работать следующим доступным бегуном. Всякий раз, когда возможности освобождаются для запуска большего количества заданий (либо из-за того, что задания завершены, либо из-за вторичных ограничений, которые они не могли выполнить), он запускал еще один этап планирования, чтобы получить дополнительную работу.
Работы были заперты атомарно как часть извлечения; блокировки не позволяли им снова появляться или участвовать в дальнейших решениях о планировании. Если они не смогли запустить, они были разблокированы, фактически возвратив их в пул. Блокировки были отключены, поэтому сервер, на котором они выполнялись, отвечал за обновление обновленных блокировок (если сервер разбился, другие будут блокировать свои блокировки и будут запускать и запускать задания, которые были запущены, но не завершены)
Для моего случая использования я хотел, чтобы пользователи A и B с заданиями A.1, A.2, A.3 и B.1 получали 25% ресурсов (хотя это означает, что пользователь A получал 75% для пользователя B 25 %). Выбор случайным образом между четырьмя кортежами вероятностно сходится к этому 25%.
Если вы хотите, чтобы у пользователей A и B каждый был разделен на 50-50 ресурсов, а A, A.2 и A.3 получили равную долю в B.1 B, вы можете запустить двухуровневый планировщик и произвольно выбирайте пользователей, и от этих пользователей выбирают рабочие места. Это будет распределять ресурсы среди пользователей одинаково, и в рамках каждого пользовательского задания поровну между типами заданий.
Огромное количество заданий определенного типа работы займет много времени, но это всегда будет так. Выбирая из разных пользователей, тогда типы заданий не будут отрицательно влиять на оперативность обработки заданий.
Существует множество дополнительных ограничений, которые могут быть добавлены (например, не более 5 вызовов в секунду для ссылки в), но вышеописанное является сердцем системы.