Блог

В моем веб-приложении выполняется длительный процесс (создание отчета Excel), который необходимо выполнять в фоновом режиме.

Некоторые подробности о приложении и среде.

Приложение состоит из множества экземпляров, где у каждого клиента есть отдельный экземпляр (с настраиваемой бизнес-логикой), в то время как все размещено на нашем сервере. Функциональность, которая создает Excel, та же.

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

Однако в таком дизайне есть недостаток, когда, скажем, пользователи из одного экземпляра будут ставить в очередь множество сложных отчетов (стоит ~ 10 минут работы), а пользователь из другого экземпляра будет ставить в очередь простой отчет (1-2 минуты), и ему придется ждать, пока другие закончат.

Для каждого экземпляра приложения могут быть отдельные очереди, но в этом случае мне нужно будет создать по одному потребителю на экземпляр. Учитывая, что существует более 100 экземпляров atm, это не выглядит жизнеспособным подходом.

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

Звучит ли это как возможный подход? Если нет, пожалуйста, дайте предложение.

Спасибо

Как я правильно понял тему, все находится на одном сервере — RabbitMQ, веб-приложение, разные экземпляры для каждого клиента и потребители сообщений. В этом случае я скорее помещаю разные темы в сообщение (https://www.rabbitmq.com/tutorials/tutorial-five-python.html ) и ввести приоритеты потребителей (https://www.rabbitmq.com/consumer-priority.html ). На основе этих параметров во время публикации сообщения я создам комбинацию темы и приоритета сообщения — издатель будет знать количество уже отправленных отчетов для каждого клиента, выбранные параметры и решит, является ли это высоким, низким или обычным приоритетом. Логика для извлечения сообщений на основе этих данных будет у потребителя, поэтому потребитель не получит тяжелые темы, когда в процессе уже 3 (пример).

Основываясь на общем количестве сообщений в очереди (это не точно на 100%) и предыдущих темах и приоритетах, вы можете реализовать своего рода стратегию утечки, чтобы получить контроль над ресурсами — максимальное количество отчетов 100, генерируемых одновременно.

Вы можете рассмотреть возможность использования ZeroMQ (http://zeromq.org ) для вашего случая это, возможно, более подходит, чем RabbitMQ, потому что это более простое и не требующее брокера решение.