Реализация очереди заданий
Реализация очереди заданий
Ребят, необходимо решить следующую задачу: в проекте будет несколько парсеров xml фидов с различных сайтов. У каждого парсера будут следующие параметры: уникальное имя, частота запуска, когда последний раз запускался и запущен ли сейчас. Идея реализации через базу данных кажется примитивной. Пока взгляд пал на Gearman. Но так как опыта в данном вопросе мало, нет уверенности в правильности выбора инструмента. Может кто то сталкивался с похожей проблемой?
Re: Реализация очереди заданий
Да, в секундах. Например какой то парсер необходимо запускать каждые 3600 секунд, другой каждые 300 секунд. Причем не должно быть наложения процессов. Парсер сайта допустим site.ru не должен запускаться в 2 и более потоков.Sam Dark писал(а):Частота запуска?
Re: Реализация очереди заданий
таблица xml:
id url frequency next_start is_running
кроном каждую минуту проверяем что надо запустить и кидаем в любой сервер очередей. хэндлер таски соответственно проставляет при запуске флажок is_running, по окончании снимает флажок и проставляет время следующего запуска.
вопрос в сервере очередей? какая разница. если у вас всего немного и парсеры на yii, тогда бы делал все нативно без стороннего ПО на БД.
id url frequency next_start is_running
кроном каждую минуту проверяем что надо запустить и кидаем в любой сервер очередей. хэндлер таски соответственно проставляет при запуске флажок is_running, по окончании снимает флажок и проставляет время следующего запуска.
вопрос в сервере очередей? какая разница. если у вас всего немного и парсеры на yii, тогда бы делал все нативно без стороннего ПО на БД.
Re: Реализация очереди заданий
Тоже так раньше казалось. Пока не запустили несколько сотен парсеров. Начались свои проблемы.zelenin писал(а):вопрос в сервере очередей? какая разница. если у вас всего немного и парсеры на yii, тогда бы делал все нативно без стороннего ПО на БД.
Re: Реализация очереди заданий
тоже интересно. у меня в проекте аналогично сотни парсеров фидов и другие задачи. реализаций очередей за 5 лет накопилось куча (вчера нашел даже на файлах)Sam Dark писал(а):Какие?
в контексте темы не понимаю какие могут проблемы - сервер очередей опрашивает таблицу в бд на предмет новых тасок и менеджерит их. тут не были названы цифры при которых могут начаться проблемы в контексте БД.
Re: Реализация очереди заданий
В принципе все эти проблемы решаемы при помощи того же MySQL. Вопрос в том насколько правильный подход. Например приходится изощряться писать errorHandler, чтобы обрабатывать ошибки парсинга для того случая, когда до конца скрипта интерпретатор не доходит.Sam Dark писал(а):Какие?
Re: Реализация очереди заданий
причем тут mysql и errorHandler? то есть у вас очередь задач на чем бы они ни была все равно будет один тот же скрипт запускать.VeerUP писал(а):В принципе все эти проблемы решаемы при помощи того же MySQL. Вопрос в том насколько правильный подход. Например приходится изощряться писать errorHandler, чтобы обрабатывать ошибки парсинга для того случая, когда до конца скрипта интерпретатор не доходит.Sam Dark писал(а):Какие?
Re: Реализация очереди заданий
Ну как при чем. Вот запустился парсер сайта sitename.ru. Внештатных ситуаций может быть много. Допустим в фиде есть синтаксическая ошибка или какой то сайт медленно отвечает по таймауту курл вывалился с ошибкой. Соответственно в той структуре, что вы привели is_running будет стоять как истина. Как я уже писал у нас есть правило не запускать парсер конкртного сайта в несколько потоков. Соответственно парсер данного сайта более не запустятся.zelenin писал(а):причем тут mysql и errorHandler? то есть у вас очередь задач на чем бы они ни была все равно будет один тот же скрипт запускать.VeerUP писал(а):В принципе все эти проблемы решаемы при помощи того же MySQL. Вопрос в том насколько правильный подход. Например приходится изощряться писать errorHandler, чтобы обрабатывать ошибки парсинга для того случая, когда до конца скрипта интерпретатор не доходит.Sam Dark писал(а):Какие?
Re: Реализация очереди заданий
а как по вашему эту ситуация разрулит не-БД очередь задач? есть вообще представление как это работает? где-то в проекте срабатывает триггер, в очередь кидается таска, менеджер очередй моментально таску запускает (моментально - в порядке приоритета, FIFO).VeerUP писал(а):Ну как при чем. Вот запустился парсер сайта sitename.ru. Внештатных ситуаций может быть много. Допустим в фиде есть синтаксическая ошибка или какой то сайт медленно отвечает по таймауту курл вывалился с ошибкой. Соответственно в той структуре, что вы привели is_running будет стоять как истина. Как я уже писал у нас есть правило не запускать парсер конкртного сайта в несколько потоков. Соответственно парсер данного сайта более не запустятся.zelenin писал(а):причем тут mysql и errorHandler? то есть у вас очередь задач на чем бы они ни была все равно будет один тот же скрипт запускать.VeerUP писал(а): В принципе все эти проблемы решаемы при помощи того же MySQL. Вопрос в том насколько правильный подход. Например приходится изощряться писать errorHandler, чтобы обрабатывать ошибки парсинга для того случая, когда до конца скрипта интерпретатор не доходит.
Re: Реализация очереди заданий
Вы почитайте первый пост, вопрос был в том что может быть есть какой то инструмент для решения подобного рода задач, речь шла не конкретно про сервер очередей.zelenin писал(а): а как по вашему эту ситуация разрулит не-БД очередь задач? есть вообще представление как это работает? где-то в проекте срабатывает триггер, в очередь кидается таска, менеджер очередй моментально таску запускает (моментально - в порядке приоритета, FIFO).
Re: Реализация очереди заданий
да, конечно, я по первому посту и веду дискуссию. Просто там изначально упомянут Gearman, в контексте него и менджеров очередей в целом и веду диалог.VeerUP писал(а):Вы почитайте первый пост, вопрос был в том что может быть есть какой то инструмент для решения подобного рода задач, речь шла не конкретно про сервер очередей.zelenin писал(а): а как по вашему эту ситуация разрулит не-БД очередь задач? есть вообще представление как это работает? где-то в проекте срабатывает триггер, в очередь кидается таска, менеджер очередй моментально таску запускает (моментально - в порядке приоритета, FIFO).
Т.е. вам по сути нужно дополнительно чекать умершие парсеры, который is_running в таблице. Стороннее ПО не сможет ничего сделать, кроме как проверять pid запущенного парсера и поднимать его, если он умер (а он столкнувшись с той же ошибкой в процессе парсинга опять умрет и опять будет поднят, что просто зациклит выполнение парсера). надо что-то дополнительно придумать.
я бы на самом деле сделал конкретно под задачу на go менеджер, который бы первоначальную инфу брал бы из бд, создавал внутри себя пулы, отслеживал бы время, запускал итд - в рамках одного менеджера, который все умеет намного легче все разрулить - он знает и о том, что парсер умер и запустит его при необходимости. Думаю тут строк на 200 кода максимум.
Re: Реализация очереди заданий
https://github.com/bamzi/jobrunner вот кстати что-то похожее