Последние год-полтора у меня были кардинальные изменения в ритме жизни и, как следствие, недостаток времени на полноценные “исследовательские” работы и посты. Я не вижу смысла и дальше оттягивать этот момент: я объединяю все свои блоги в один и прекращаю писать в специализированный блог “только о Python”.
Добавляйте в закладки:
Если бы не Александр Соловьев, то я бы прошел мимо Mongrel2. А всё потому, что первый Mongrel был Ruby-специфичным инструментом и никогда особо меня не интересовал.
Другое дело Mongrel2. Во-первых, он написан на C. Во-вторых, он не привязан ни к какому из языков. В-третьих, он использует ZeroMQ как транспорт.
По сути, Mongrel2 это балансирующий прокси, который парсит http и отдает запросы в виде сообщений в ZeroMQ и так же получает ответы.
Mongrel2 интересен несколькими моментами.
Быстрый. Все операции по парсингу http (сам Mongrel2) и передачи сообщений (ZeroMQ) берет на себя быстрый C-код.
Не привязан к языкам По сути, всё что вам нужно, чтобы начать работать с mongrel - это биндинг к ZeroMQ, которые есть для всех более-менее мажорных языков. Так что используя любой язык для работы с Mongrel (Erlang, Python, Ruby, Lua), вы уже получаете распарсенный запрос, причем с гарантией, что не получите специфичных для данного языка багов.
Асинхронные сообщения Это самая интересная фишка Mongrel2 и тут стоит остановиться чуть подробнее.
Дело в том, что современные балансировщики нагрузки работают как сервисы «переднего края», принимающие запросы, и как «командные центры», которые опеределяют, какому бэкенду следует отправить данный запрос. Как следствие, при добавлении бэкенда нужно донастраивать балансировщик.
Mongrel делает иначе — он принимает запрос и, ничего не зная о бэкендах и их количестве, ставит запрос в очередь. Запрос из очереди берет тот бэкенд, который освобождается первым.
Это действительно здорово, когда вы просто добавляете бэкенд и он сразу начинает работать.
Бэкенд является демоном, который подписывается на определенные сообщения в ZeroMQ, при получении обрабатывает и по готовности ответа шлет другое сообщение, на которое уже подписан Mongrel2. Если говорить о WSGI, то нужен коннектор между Mongrel2/ZeroMQ и WSGI-приложением (он вроде бы есть, и даже не в единственном экземпляре, но код OMG-OMG).
Итог. У Mongrel2 интересная концепция и он обещает быть весьма полезным на практике. Я бы не рискнул сейчас его ставить в продакшн, но вот поиграться — вполне.
P.S. А еще у Mongrel2 конфиг в SQLite :)
Эти слайды изначально были подготовлены для доклада в формате Печа Куча для 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 за великолепные фото.