В очередь ∞
Эти слайды изначально были подготовлены для доклада в формате Печа Куча для PyCon UA, 24 октября 2010 года.
Веб-приложение — как игра в теннис, вы не должны задерживать "мяч" у себя. Получили запрос — как можно быстрее обработали его — отдали ответ.
Но что если задание не "влезает" в цикл запрос-ответ. Например, вам нужно отправить несколько сотен писем, или послать твит, а твиттер перегружен, вариантов множество
В этом случае вы принимаете запрос, быстро его обрабатываете и как можно быстрее ставите задание в очередь. А очередь через некоторое время выполнит задание.
Естественно, вначале хочется чего-то очень простого, без дополнительных сервисов и зависимостей, например, чтобы использовалось основное хранилище данных приложения.
Плохая новость…
Я таких инструментов не знаю.
Хорошая новость в том, что я знаю, где отложеннные задания и очереди уже есть…
Это Google App Engine
Здесь уже есть всё то, что вам нужно для фонового выполнения отложенных задач. За вас хорошенько подумали и сконструировали неплохую архитектуру. Другое дело, что особой альтернативы в рамках AppEngine у вас нет.
Если рассматривать что-то более серьезное, что требует внешнего хранилища…
То в этой категории мне очень нравится pyres. Он прост и незатейлив, но покрывает весь необходимый функционал. Он как любимая отвёртка, которая просится к вам в руку.
Pyres использует Redis как хранилище заданий и очередей. Я думаю,
вы уже всё знаете о Redis благодаря великолепным докладам
У pyres отличный веб-интефейс в котором вы видите работающих worker'ов, актуальные очереди, задания с ошибками. Вы можете сделать retry таким заданиям или удалить их. И конечно это WSGI, так что проблем с интеграцией с существуещим приложением не будет.
Pyres весьма компактен. Вы за час-полтора сможете сделать ревью кода. Причем вы можете облегчить его на треть, если вдруг вам не нужен веб интерфейс.
Pyres действительно хорош и в 90% вам просто не нужны те фичи, которых нет.
Конечно, существуют и более функциональные системы, где всё по-взрослому.
И, конечно, первую скрипку на этой сцене играет Celery. В нем много всего: много бэкендов, много фич, много документации и, как следствие, много кода.
Celery по умолчанию поддерживает AMQP-бэкенд и рекомендует использовать RabbitMQ. Но через специальный адаптер работает и с redis (мой выбор), ZeroMQ и многими другими.
У Celery есть очень интересные возможности: он позволяет не только выполнять отложенные задания, но планировать их выполнение и выполнять их периодически; умеет работать с веб-хуками, так что он не ограничивает клиентов толкьо Python; он умеет ограничивать частоту выполнения заданий; ему можно настроить повтор определенных заданий; группировать задания в "тасксеты" и хранить результаты выполнения используя различные бэкенды.
Обратная сторона богатого набора фич Celery — его размер. Согласитесь, ставить в зависимостях Celery для небольшого приложения будет перебор. Поэтому я бы рекомендовал Celery в том случае, если вы действительно не можете жить без его фич.
Вероятно вы хотели бы, чтобы я упомянул о чем-нибудь еще, но формат не позволяет осветить больше. Возможно что-нибудь из этого вам покажется интересным.
Друзья, я прошу вас использовать, развивать, рекламировать, пропагандировать уже существующие решения. Они действительно хороши. Хватит наколенных поделок и велосипедов!
Спасибо за внимание. Если у вас есть вопросы или комментарии к слайдам — воспользуйтесь FriendFeed ;)
Спасибо Flickr и Creative Commons за великолепные фото.
