Алгоритм эффективного управления ресурсами соединения

Question

трудно найти это, если об этом уже спрашивали, так как я не знаю его названия. Итак, вот так:

Я делаю этот сервер, который подключается к шлюзам обмена сообщениями для отправки сообщений. Для сеанса с этим шлюзом требуется комбинация имени пользователя и пароля. Таким образом, шлюз знает, кому выставить счет.

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

Так что эффективно это вопрос спроса и предложения с ограничениями:

У меня есть шлюз, который может обрабатывать только N одновременных соединений (имя пользователя / pw combo) У меня сложено X сообщений, принадлежащих Y, из этих соединений

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

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

Я сам сделал несколько попыток, но я чувствую, что все еще не создаю элегантное решение, но каким-то образом получаю длинные вложенные операторы if

спасибо

Answer 1

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

1. Для каждого соединения (имя пользователя / пароль) создайте простую очередь LIFO. Модуль, который получает сообщения, должен ставить их в очередь для соответствующего пользователя.
2. Диспетчерский модуль должен поддерживать отсортированные по приоритетам очереди. Это означает, что у вас есть функция priority(queue), которая вычисляет приоритет для данной очереди на основе количества сообщений, приоритета учетной записи, времени с момента последней отправки и т. Д. Реализация priority(queue) оставлена ​​читателю в качестве упражнения.
3. Внутренний цикл диспетчера убирает из очередей N N очередей с наивысшим приоритетом, устанавливает соединение со шлюзом для каждого имени пользователя / пароля и отправляет все сообщения в этих очередях. Вновь очищенные очереди возвращаются в очередь. Пересчитать приоритет для всех очередей, промыть и повторить.

В идеале отправляющая сообщения часть шага # 3 может быть многопоточной.

Альтернативной реализацией шага # 3 будет отправка сообщений из каждой очереди до тех пор, пока приоритет этой очереди не опустится ниже приоритета следующей очереди ожидания. Однако это означает, что вы пересчитываете priority(queue) после каждой отправки, что может быть дороже, чем стоит.

Answer 2

Концептуально вы хотите реализовать приоритетную очередь .

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

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

Если ваш шлюз даже немного медленнее, чем алгоритм маршрутизации, вы получите чистое увеличение скорости, сделав алгоритм маршрутизации как можно более умным.

Answer 3

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

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

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