2009-06-22 8 views
48

Последняя версия приложения Google App Engine поддерживает новый Task Queue API в Python. Я сравнивал возможности этого API с уже существующим Cron service. Для фоновых заданий, которые не инициируются пользователем, например, захват RSS-канала и его синтаксический анализ на ежедневный интервал. Может ли и должен использоваться API очереди задач для запросов, не инициированных пользователем?Google App Engine - Task Queues vs Cron Jobs

ответ

24

Я бы сказал «своего рода». То, что нужно запомнить о очередях задач:

1) ограничение операций в минуту/час/день - это не то же самое, что повторять что-то через регулярные промежутки времени. Даже если размер маркера маркера установлен равным 1, я не думаю, что вам гарантировано, что эти повторения будут равномерно распределены. Это зависит от того, насколько они серьезны, когда говорят, что очередь реализована как маркерная ведро, и должен ли этот оператор быть гарантированной частью интерфейса. Это лаборатория, пока ничего не гарантировано.

2) если задача не удалась, то она запрашивается. Если задание cron завершается с ошибкой, оно регистрируется и не возвращается до тех пор, пока оно не будет возвращено. Таким образом, задание cron не ведет себя так же, как задача, которая добавляет копию самого себя, а затем обновляет ваш канал или как задачу, которая обновляет ваш канал, а затем добавляет копию самого себя.

Возможно, можно будет макетировать задания cron, используя задачи, но я сомневаюсь, что это того стоит. Если вы пытаетесь обойти работу cron, которая занимает более 30 секунд для запуска (или удаляет любой другой лимит запроса), вы можете разделить работу на части и выполнить задание cron, которое добавит все части к очереди задач. Был какой-то разговор (в блоге GAE?) Об асинхронном urlfetch, который может быть лучшим способом обновления RSS-каналов.

+1

асинхронной UrlFetch существует сегодня, см http://code.google.com/appengine/docs/python/urlfetch/asynchronousrequests.html - но я не уверен, как это будет лучшим способом обновления RSS-каналов; возможно, у вас есть что-то еще в виду? –

+1

По какой-то причине я ожидал чего-то, что бы перезвонить URL-адрес при поступлении полученных данных. Не знаю, откуда у меня эта идея, возможно, мое воображение. Однако, если вы обновляете множество каналов RSS, вам нужно, чтобы HTTP-запросы каким-то образом были параллельными, а очереди задач только позволяли так много одновременных экземпляров. Вполне возможно, что API, на который вы указываете, уже выполняет эту работу. –

+4

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

5

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

Я только говорю это, потому что в прошлом мне приходилось изгонять многие пользовательские поисковые запросы Twitter с регулярными интервалами и с заданиями Cron, которые я закончил, создав очень плохую систему Queuing для выполнения запросов, которые нужно было запустить - t, это не помогло, и наименьший интервал, который может выполнять задание cron, составляет всего 1 минуту (у меня было больше запросов на выполнение, чем минут в день).

Замечательная вещь о задачах заключается в том, что вы можете дать им ETA, так что вы можете сказать, что я хотел бы, чтобы это было выполнено 47 секунд в будущем, или я хотел бы, чтобы это было выполнено в 12:30.

15

Я не очень хорошо разбирался в различиях, пока не просмотрел видеоролик Google I/O, где они объясняют это. Официальный источник, как правило, самый лучший.

youtube video

slides from the presentation

Смежные вопросы