Использование сообщений очереди с ресурсом обработки в зависимости от типа сообщения

Question

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

В основном очередь может выглядеть следующим образом: A, A, A, A, A, B, B, A, B, A, A, A, A, A, C, B, A.

Т.е.. Сообщения A встречаются гораздо чаще, чем другие сообщения.

Наша система имеет разные значения параллелизма для каждого из типов сообщений, например, мы можем выполнить только 3 сообщения A одновременно, но мы можем выполнить 5 сообщений B и 4 сообщения C одновременно.

Мой текущий (неработающий) алгоритм состоит в том, чтобы один поток считывал данные с начала очереди и отправлял в пул потоков каждое задание, причем тело каждого задания ожидает достаточного количества ресурса, чтобы стать доступным, прежде чем выполнять фактическую полезную нагрузку.

Это означает, что если сначала поступит достаточное количество сообщений A, то они могут «заполнить» очередь пула потоков, а сообщения B + C будут голодать гораздо дольше, чем необходимо.

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

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

Answer 1

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

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

Answer 2

Прежде всего, допустимы ли следующие предположения?

• Неважно, в каком порядке фактически выполняются задания.
• Очередь - это просто механизм записи выполняемых заданий.
• Все работы независимы.
• Всегда есть несколько заданий, ожидающих обработки.

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

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

Answer 3

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

Что касается альтернатив, вы можете создать оболочку вокруг пула потоков и реализовать очередь приоритетов (http://en.wikipedia.org/wiki/Priority_queue).). Эта неявность будет назначать приоритет определенным сообщениям. В вашем случае, поскольку C является наименее распространенным, он всегда может расставить приоритеты C выше. Я думаю, вы поняли.