задача в том чтобы сделать раз или два npm install и написать пару строчек? ну да, изи

а крон нет?

он есть в системе из коробки

не везде)

и его не надо отдельно плясать и мейнтейнить

покажи мне ось в коротой нет планировщика из коробки

ох бля)

КГМ (крон головного мозга)

и его не надо отдельно плясать и мейнтейнить

ты будешь плясать с кроном

Если тебе важна очередность- создавай по очереди на каждый период времени (какой- установи сам) и начни исполнять очередь в нужный тебе момент

Было бы все так просто. Если задачам устанавливать периоды сразу же - задача не решается.

Было бы все так просто. Если задачам устанавливать периоды сразу же - задача не решается.

Не понял

ты будешь плясать с кроном

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

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

бля

вот надо поменять время

будешь лезть на сервак и менять руками?

и его не надо отдельно плясать и мейнтейнить

у крона свои проблемы (если таска должна была выполниться когда компьютер лежал) крон не выполнит ее по включению

ладно, хорош говносрачить - чем не годятся redis-based либы под ноду для очередей?

у крона свои проблемы (если таска должна была выполниться когда компьютер лежал) крон не выполнит ее по включению

не было всех этих требований вроде выше

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

У меня тут таска на 3 месяца вперед на определенную минуту Поставлю крон, чтобы дергал базу и проч проч проч ради этого

чувак с тривиальной таской пришел вы уже какие-то сложности сочиняете на ходу

тоже верно

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

нихуя не понятно, чуваку очередь или планировщик

нихуя не понятно, чуваку очередь или планировщик

Планировщик с очередью)

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

блядь либо делаешь адекватно сразу

либо всю жизнь пишешь хуйню

Не понял

Приходит 20 запросов не по расписанию. Необходимо данные 20 запросов начать (ключевое слово) обрабатывать на следующий день в 11:30 (к примеру). Т.е. данная "пачка" задач стартует в 11:30. Берем первую задачу и выполняем ее (после выполнения там еще запрос по API и ожидание данных от другого сервиса), остальные сидят и ждут выполнения. Как только выполняется задача - выполняется следующая и т.д.

блядь либо делаешь адекватно сразу

оверкилл может оказаться надо требования уточнять

очередь

Планировщик с очередью)

Именно.

и планировщик

?

не все вещи требуют того чтобы быть сделанными адекватно сразу

Приходит 20 запросов не по расписанию. Необходимо данные 20 запросов начать (ключевое слово) обрабатывать на следующий день в 11:30 (к примеру). Т.е. данная "пачка" задач стартует в 11:30. Берем первую задачу и выполняем ее (после выполнения там еще запрос по API и ожидание данных от другого сервиса), остальные сидят и ждут выполнения. Как только выполняется задача - выполняется следующая и т.д.

В чем проблема консюмить сообщения рекурсивно?

В сторону CRON и прочих аналогов - молчу и не рассматриваю. Спасибо.

Именно.

тебе за деньги в продакшен адекватно сразу или говно на коленке на раз для себя?

лучший планировщик задач - это setTimeout. главное дельту в посчитать правильно в миллисекундах

тебе за деньги в продакшен адекватно сразу или говно на коленке на раз для себя?

Варианты с "коленками" не нужны.

Решение мне в принципе понятно.

не все вещи требуют того чтобы быть сделанными адекватно сразу

ну вот и ответ

Планировщик с очередью)

ну пусть прикрутит планировщик - не роект саенс же, есть куча либ планировщиков под любые платформы. сделать сервис общающийся с очередью и туда же встроить планировщик. в чём проблема то.

лучший планировщик задач - это setTimeout. главное дельту в посчитать правильно в миллисекундах

красавец, че

лучший планировщик задач - это setTimeout. главное дельту в посчитать правильно в миллисекундах

Нода отвалилась, сервис сдох.

Нода отвалилась, сервис сдох.

сервер сдох админы повесились

Админов сбил автобус.

воруй убивай требования вангуй

В чем проблема консюмить сообщения рекурсивно?

Каким образом?

Приходит 20 запросов не по расписанию. Необходимо данные 20 запросов начать (ключевое слово) обрабатывать на следующий день в 11:30 (к примеру). Т.е. данная "пачка" задач стартует в 11:30. Берем первую задачу и выполняем ее (после выполнения там еще запрос по API и ожидание данных от другого сервиса), остальные сидят и ждут выполнения. Как только выполняется задача - выполняется следующая и т.д.

Можно забрать одно сообщение, обработать, запросить второе, обработать и тд

Вот, да.

Можно забрать одно сообщение, обработать, запросить второе, обработать и тд

Именно.

Придумал схему с блоками.

Вот, да.

Можно на уровне ноды складировать и рекурсивно дергать массив, пока не закончатся записи

Сейчас ищу вариант, чтобы дергать с помощью amqplib и заново подписываться на одно сообщение

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

Что скажешь?

велосипедостроение, ниче так

Бля, редис прям идеально под задачу подходит.

велосипедостроение, ниче так

Предлагай :)

Предлагай :)

да вон выше уже кучу вариантов напредлагали, редис бери

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

да вон выше уже кучу вариантов напредлагали, редис бери

Используется Kue так-то :)

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

http://www.rabbitmq.com/consumer-prefetch.html basicQos

Используется Kue так-то :)

и оно такое тупэнькэ что не умеет то что тебе нужно из коробки в две строчки?

http://www.rabbitmq.com/consumer-prefetch.html basicQos

На уровне "кролика" находил решения. Опишу что есть: - Node.js - Kue (Redis)

и оно такое тупэнькэ что не умеет то что тебе нужно из коробки в две строчки?

Пожалуйста прочитай чат с первого моего сообщения.

Спасибо!

Спасибо!

прочитал, вопрос актуален, оно не умеет это делать?

ERROR: S client not available

прочитал, вопрос актуален, оно не умеет это делать?

Что именно?

Создавать очередь - умеет.

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

Отложенные задачи и все остальное - умеет.

Зависимость между задачами нужна.

соответственно напрашивается вопрос - почему оно должно не уметь это из коробки?

Зависимость между задачами нужна.

дык скедули задачу как враппер над новой очередью :3

Зависимость между задачи не решается при помощи Redis.

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

Сейчас пока нет.

из того что я вижу по описанию достаточно любую джобу заворачивать в enqueue от последней добавленной джобы и этого достаточно чтобы им задать порядок и расписание

Сейчас пока нет.

а планируется усложнение логики зависомстей?

а вообще за либу спасибо, полезно выглядит

Да. Будут задачи другого типа. Будут параметры, определяющие зависимость одной от другой.

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

А такое может быть, вполне.

Получится что задачи выполняются одновременно.

так отдельная же очередь будет

Да. Будут задачи другого типа. Будут параметры, определяющие зависимость одной от другой.

есть такой вариант тогда, но он попахивает тырпрайзом. складируй задачи в базе, а их логику подачи уже определяй всякми триггерами и хранимками. а для более гладкого получения сами задачи уже из базы тяни встроенной очередью - oracle AQ или pg notify (вроде он как аналог aq). также в самой же бд можешь настроить планировщик на процедуры

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

это вопрос приоритизации же только - у обработчика очереди всегда должен быть приоритет ниже (не проверял можно ли этому доверять наверняка)

есть такой вариант тогда, но он попахивает тырпрайзом. складируй задачи в базе, а их логику подачи уже определяй всякми триггерами и хранимками. а для более гладкого получения сами задачи уже из базы тяни встроенной очередью - oracle AQ или pg notify (вроде он как аналог aq). также в самой же бд можешь настроить планировщик на процедуры

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

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

это вкусовщина. /me некоторые вещи наоборот упростил за счёт хранимок, так как не нужно было ебаться с атомарностью и отказоустойчивостью, так как кластер оракла давал это из коробки, например

это вкусовщина. /me некоторые вещи наоборот упростил за счёт хранимок, так как не нужно было ебаться с атомарностью и отказоустойчивостью, так как кластер оракла давал это из коробки, например

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

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

Создаем задачу block:start в очереди на 11:30. Создаем блок в базе: 1) jobId 2) jobType 3) tasks В блок добавляем задачи. Наступает 11:30. В процессинге блока достаем первую задачу и ложим в очередь сразу же выполняться. В процессинге задачи выполняем саму задачу, по выполнению достаем следующую и т.д.

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

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

Хранимки это боль.

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

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

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

Создаем задачу block:start в очереди на 11:30. Создаем блок в базе: 1) jobId 2) jobType 3) tasks В блок добавляем задачи. Наступает 11:30. В процессинге блока достаем первую задачу и ложим в очередь сразу же выполняться. В процессинге задачи выполняем саму задачу, по выполнению достаем следующую и т.д.

достать можно в общем-то и до завершения выполнения

Хранимки это боль.

нит же. это просто инструмент, можно использовать органично, а можно и ногу острелить