Хуевая затея
+
Матрос
Таймураз
Нагородить велосипедов, а потом с этим же возиться..
Матрос
крон не про очереди
Таймураз
Именно
Матрос
общесистемные одминские задачи - пожалуйста. но очереди in app - фу фу фу
?
Сломать себе мозг, как и архитектуру- раз плюнуть
ок заюзать любой другой готовый планировщик, вон нод крон советуют, сути дела не меняет - не велосипедить это
Sergey
зачем планировщик для очередей?
Матрос
+
Таймураз
Есть еще дополнительный нюанс.
Есть задачи с приоритетом.
Т.е. когда "стартанет" блок с задачами, будут также приходить задачи по расписанию, штука в том, что задачи, которые по расписанию приходят, должны выполняться первее, чем те, которые в блоке.
Если тебе важна очередность- создавай по очереди на каждый период времени (какой- установи сам) и начни исполнять очередь в нужный тебе момент
Матрос
от того что топором можно забить гвоздь, топор молотком не станет
Nikolay
Для очередей redis нелохо затачивается, если чо.
?
у него там частично функционал планировщика, частично очереди - очередь любую можно взять - async js например или чето еще более простое
Матрос
да берите любой bull/kue/bee и иже с ними
Таймураз
Блядь, да задача в изи решается, какой блядь крон блядь
Столько мата вставил спецом (я художник я так вижу)
?
редис то как-то дофига жирно для тулы на коленке
?
янукович жпег
Матрос
redis это не Oracle. что в нем жирного-то???
?
задача в том чтобы сделать раз или два npm install и написать пару строчек? ну да, изи
Sergey
не везде)
?
и его не надо отдельно плясать и мейнтейнить
?
покажи мне ось в коротой нет планировщика из коробки
Sergey
ох бля)
Таймураз
КГМ (крон головного мозга)
O.
Если тебе важна очередность- создавай по очереди на каждый период времени (какой- установи сам) и начни исполнять очередь в нужный тебе момент
Было бы все так просто.
Если задачам устанавливать периоды сразу же - задача не решается.
Таймураз
Sergey
вот надо поменять время
Sergey
будешь лезть на сервак и менять руками?
Алексей
и его не надо отдельно плясать и мейнтейнить
у крона свои проблемы (если таска должна была выполниться когда компьютер лежал) крон не выполнит ее по включению
Матрос
ладно, хорош говносрачить - чем не годятся redis-based либы под ноду для очередей?
?
у крона свои проблемы (если таска должна была выполниться когда компьютер лежал) крон не выполнит ее по включению
не было всех этих требований вроде выше
Таймураз
плясать над тем чтобы тупо заскедулить таску на определенное время?
У меня тут таска на 3 месяца вперед на определенную минуту
Поставлю крон, чтобы дергал базу и проч проч проч ради этого
?
чувак с тривиальной таской пришел вы уже какие-то сложности сочиняете на ходу
Алексей
тоже верно
?
вот когда скажет что ему надо чтобы это 50 человек менеджило и параллелить это на миллион серверов тогда будет вопрос о гибкости крона, а чтобы тупо таску на время забить - более чем достаточно же
Anton
нихуя не понятно, чуваку очередь или планировщик
Sergey
Sergey
либо всю жизнь пишешь хуйню
O.
Не понял
Приходит 20 запросов не по расписанию.
Необходимо данные 20 запросов начать (ключевое слово) обрабатывать на следующий день в 11:30 (к примеру).
Т.е. данная "пачка" задач стартует в 11:30.
Берем первую задачу и выполняем ее (после выполнения там еще запрос по API и ожидание данных от другого сервиса), остальные сидят и ждут выполнения. Как только выполняется задача - выполняется следующая и т.д.
Матрос
очередь
Матрос
и планировщик
Матрос
😂
?
не все вещи требуют того чтобы быть сделанными адекватно сразу
Таймураз
Приходит 20 запросов не по расписанию.
Необходимо данные 20 запросов начать (ключевое слово) обрабатывать на следующий день в 11:30 (к примеру).
Т.е. данная "пачка" задач стартует в 11:30.
Берем первую задачу и выполняем ее (после выполнения там еще запрос по API и ожидание данных от другого сервиса), остальные сидят и ждут выполнения. Как только выполняется задача - выполняется следующая и т.д.
В чем проблема консюмить сообщения рекурсивно?
O.
В сторону CRON и прочих аналогов - молчу и не рассматриваю. Спасибо.
Mike
лучший планировщик задач - это setTimeout. главное дельту в посчитать правильно в миллисекундах
O.
тебе за деньги в продакшен адекватно сразу или говно на коленке на раз для себя?
Варианты с "коленками" не нужны.
O.
Решение мне в принципе понятно.
Anton
Планировщик с очередью)
ну пусть прикрутит планировщик - не роект саенс же, есть куча либ планировщиков под любые платформы. сделать сервис общающийся с очередью и туда же встроить планировщик. в чём проблема то.
?
Nikolay
лучший планировщик задач - это setTimeout. главное дельту в посчитать правильно в миллисекундах
Нода отвалилась, сервис сдох.
Nikolay
Админов сбил автобус.
?
воруй убивай требования вангуй
Таймураз
Приходит 20 запросов не по расписанию.
Необходимо данные 20 запросов начать (ключевое слово) обрабатывать на следующий день в 11:30 (к примеру).
Т.е. данная "пачка" задач стартует в 11:30.
Берем первую задачу и выполняем ее (после выполнения там еще запрос по API и ожидание данных от другого сервиса), остальные сидят и ждут выполнения. Как только выполняется задача - выполняется следующая и т.д.
Можно забрать одно сообщение, обработать, запросить второе, обработать и тд
O.
Вот, да.
O.
Придумал схему с блоками.
Таймураз
Вот, да.
Можно на уровне ноды складировать и рекурсивно дергать массив, пока не закончатся записи
Таймураз
Сейчас ищу вариант, чтобы дергать с помощью amqplib и заново подписываться на одно сообщение
O.
Когда поступают задачи не по расписанию - складывать их в этакий блок, блок сразу же запускать.
Когда наступает время блока - блок запускается, вытаскивает первую задачу, сам "умирает" (в очереди), выполняется первая задача и из блока тащит вторую и т.д.
O.
Что скажешь?
?
велосипедостроение, ниче так
Nikolay
Бля, редис прям идеально под задачу подходит.