Всем привет, у нас на кроне весит 2-3 задачки, каждая в своем интервале проверяет некоторые данные, и производит тяжелые фоновые работы.
Например, работу с каталогом, индексами, или импорт данных, если появился файл выгрузки.
У нас на текущий момент уже используется rabbitmq, и десяток консюмеров для других задач (для реал-тайм интеграции с поставщиком).
Вопрос: стоит ли бояться плодить консюмеров ? Насколько они сильно нагружаются систему, когда просто слушают очередь ?
Стоит ли переводить выполнение задач по крону, на очереди ? Создать очередь тасков, и одного консюмера, который при появлении задачи, будет ее запускать.
Дело в том, что за сутки крон запускает всего 4-5 задач, но проверяет их наличие каждые 5 мин, т.к. они могут появиться в любой момент.
Меня пугает то, что в варианте с очередями, консюмер 95% своего времени будет просто висеть и слушать очередь, т.к. сообщения падают 4-5 раз в сутки.
работает ? не трожь.
Будет реальная необходимость переделаете под новые условия.
А сейчас такое впечатление, что у Вас больше других доделок по проекту нет.
Нет, ничего критического не произойдет, если только вы не работаете с серверами из 80-х. Конкретно кролик держит огромные нагрузки отлично.
Про целесообразность:
Во-первых, выше верно пишут, пока работает - не трогай.
Во-вторых, опять же выше верно пишут, что на такое количество задач затея сомнительна.
В-третьих, очереди - это обычно нечто событийное. К тебе пришел клиент на сайт, загрузил свое фото, ты родил сообщение в очередь на бекенде сайта, что фото должно быть проверено саппортами, это событие получила CRM-система саппортов и они выполнили какие-то действия. А в описанной в вопросе модели кто будет рождать такие события? Некий таймер? Он же опять скорее всего на кроне будет, смысл городить огород тогда с кроликом? Если не на таймере, а на каком-то событии, возникающим в приложении в нужный момент времени - ну ок. Но скорее всего, будет все-таки иначе.
В целом, все перенес уже на кролика, и все вроде работает!
Задача такая была:
1С по http запросу в произвольный момент времени присылает огромную xml для импорта.
Естественно к контексте того же http-запроса я не могу запустить импорт файла - слишком долгий процесс для http.
Ранее, у нас каждый 3-5 мин крон проверял наличие нового файла, и запускал процесс импорта.
А сейчас, по при получении нового файла - добавляю таск в очередь, а консюмер при появлении нового сообщения - запускает импорт.
Меня настораживает одно в этой новой схеме:
запрос на импорт файла - поступает примерно 2-3 раза в сутки. получается, что все остальное время консюмер простаивает, слушая очередь - является ли серьезной это нагрузкой ?
запрос на импорт файла - поступает примерно 2-3 раза в сутки. получается, что все остальное время консюмер простаивает, слушая очередь - является ли серьезной это нагрузкой ?
То я на самом деле уже ответил выше - нет, никакой нагрузки там не будет и в помине. Очередь в самом кролике не занимает практически ничего. Подписчик, слушающий сообщения в ней, лично у нас написан на Rust (открытое решение, возможно и у вас он же), и он тоже ровным счетом ничего не ест.
Тяжёлые работы лучше выполнять поочерёдно, а не параллельно. Хотя это зависит от количества ядер процессора и от количества дисков; это нетривиальная задача по оптимизации.
Я не понял, что значит "проверяет наличие задач каждые 5 мин". Что именно проверяется?
Если надо оперативно запускать программы - то надо сделать так, чтобы "источник задач" (тот, кто порождает необходимость запустить задачу) сам запускал задачу. Есть много механизмов, могу обсудить.
Можно сделать такой вариант запуска задач:
Планировщик задач запускает программу, проверяющую какие-то условия и когда получено решение о выполнении задачи, отправляет в очередь указание с необходимыми для выполнения аргументами и затем программа сразу завершается. При такой схеме не будет висеть процесс программы долгое время, а консюмеры будут обрабатывать задачи асинхронно и поочередно.
Но для такого малого количества задач затея сомнительна.
