Я выступал с докладом «Приемы разработки высоконагруженных приложений на Twisted/Python». В докладе получилась (вполне сознательно) сборная солянка из советов и приемов о том, как писать приложения на Twisted (и похожих frameworkах). Из-за большого количества разных тем не получилось углубиться ни в одну, каюсь…

Тезисы:

1. Запуск и шедулинг многих однопоточных процессов на одном сервере.
2. Key-value storage и приемы работы с ним.
3. Обслуживание сотен тысяч соединений на одном сервере.
4. HTTP-сервисы и балансировка нагрузки, локализация нагрузки.
5. Сбор статистики, интеграция с системой мониторинга.
6. Шина обмена сообщениями на примере AMQP.
7. Поиск и устранение memory leak.
8. Оптимизация по времени отклика и пропускной способности.
9. Мифы и правда о Python как языке разработки нагруженных приложений.

Презентация:

Утащить:

• В формате PDF
• Модуль py-numа, который упоминался в докладе

Запускаем наше приложение с включенным профайлингом:

twistd -n --savestats --profile=myprog.hotshot myprog

Подаем нагрузку, профайл собирается. Теперь с помощью утилиты hotshot2cg из поставки KCachegrind превращаем hotshot-профайл в calltree-профайл, который уже умеет KCachegrind «кушать».

hotshot2cg myprog.hotshot > myprog.calltree

Запускаем KCachegrind, открываем в нем полученный профайл:

kcachegrind myprog.calltree

Введение

Последнее время в области web происходит смещение внимания с тяжелых application-серверов, которые тратят на обработку запроса сотни миллисекунд, а то и секунды, к более легковесным сервисам, передающим меньшие объемы данных с минимальной задержкой. Переход от генерации десятков и сотен килобайт HTML-кода в ответ на запрос к передаче изменений в данных, запакованных в JSON и измеряемых сотнями байт. В качестве примеров таких сервисов можно привести Gmail, FriendFeed, Twitter Live Search и т.п.

Для обеспечения минимальной задержки для пользователя необходимо либо поддерживать постоянное соединение (например, Adobe Flash, RTMP) или использовать технику HTTP long polling в сочетании с keep alive. Так или иначе на стороне сервера это приводит к появлению большого количества одновременных соединений (тысячи, десятки тысяч), по каждому из которых передается не такой большой объем данных. Эту ситуацию называют обычно проблемой C10k.

Для обработки соединений архитектурный выбор на стороне сервера не такой большой: процесс на соединение, нить на соединение, комбинированный вариант процесс-нити или асинхронный ввод-вывод (возможно, в сочетании с дополнительными процессами или нитями). При наличии более 10 тысяч одновременных соединений с точки зрения расхода ресурсов совершенно невозможно представить создание 10 тысяч процессов; 10 тысяч нитей также вряд ли будет разумным решением. Необходимо дополнительно учесть, что при наличии такого большого числа соединений объем работы по каждому из них относительно невелик, большинство их них простаивают в ожидании поступления новых данных. Поэтому бóльшая часть процессов или нитей будет просто находиться в состоянии ожидания, расходуя впустую системные ресурсы. Асинхронный ввод-вывод позволяет осуществлять неблокирующийся сетевой ввод-вывод по тысячам открытых сокетов в рамках одной нити выполнения (одного процесса). Механизмы реализации в разных ОС разные, например: select(), poll(), epoll(), kqueue() и т.п. Примеры приложений, использующих асинхронный ввод-вывод:

• nginx (используются дополнительные процессы для обслуживания задач, требующих большего объема CPU);
• haproxy;
• memcached;
• и другие.

Тем не менее, асинхронный ввод-вывод не является универсальным решением: для сервера БД это вряд ли было бы хорошим способом организации обслуживания соединений, так как для обработки каждого запроса требуется большой объем дискового ввода-вывода и процессорного времени, что не позволяет это сделать в рамках одного процесса.

Twisted Framework — это обширный набор классов и модулей для реализации асинхронных сетевых приложений. Twisted Framework — это:

• ядро, абстрагирующее все операции асинхронного ввода-вывода и использующее соответствующий механизм конкретной ОС;
• концепция Deferred, которая позволяет реализовать в простой форме обслуживание запроса: асинхронные сетевые обращения (например, к БД, memcached), обработку ошибочных ситуаций; Deferred является аналогом обычных конструкций последовательного программирования для асинхронной модели программирования;
• обширный набор уже реализованных сетевых протоколов: HTTP, DNS, SMTP, IMAP, memcached, Jabber, ICQ и т.д.; еще большее количество протоколов доступно в виде дополнительных модулей;
• дополнительная инфраструктура: unit-testы с поддержкой Deferred, пулы нитей, процессов и т.д.;
• качественная концепция разработки — полное покрытие unit-testами, строгий review любого изменения.

Основная часть доклада будет посвящена конкретным примерам приложений, реализованными с помощью Twisted — с архитектурой, конкретными параметрами производительности, приемами оптимизации, преимуществами и недостатками Twisted для решения данной задачи:

• RTMP-сервер pyFMS, сервер вещаний сервиса Smotri.Com (сотни трансляций, десятки тысяч зрителей);
• backend-сервер проекта MDC – хранение и обработка истории общения пользователей, хранение настроек и т.п.;
• Qik Push Engine – сервер немедленной доставки изменений информации о видео, созданных пользователями сервиса, в том числе push-нотификация о появившихся live-стримах, масштабирование, обработка больших объемов информации.

Дополнительная информация:

• Документация Twisted
• О Python, а также о Twisted
• Блог на Хабрахабре про Twisted
• Александр Бурцев о Twisted
• Deferred в Twisted и не только .

Презентация

• Скачать презентацию (PDF)

Qik Push Engine – это механизм, который позволяет получать мгновенные оповещения о новых/изменившихся Qik-видео. Например, можно посмотреть постоянно обновляющийся список live-видео, все видео из района Новопеределкино или все видео со словом «кошка». На основе Qik Push Engine API можно построить интересные приложения, интегрированные с Qik, или добавить функциональность в уже существующие. Можно написать собственную систему нотификации, desktop-widget или что-то еще.

Сегодня мы открываем API для работы c Qik Push Engine. Это первая ласточка в большом списке API, открывающих доступ к платформе стриминга Qik. Если вам интересно посмотреть Qik Push Engine в действии, заходите на одну из страниц примеров.

Основы работы с API

Qik Push Engine API доступно в виде набора удаленных процедур по протоколу JSON-RPC (over HTTP). В ближайшее время будет открыт REST-подобный интерфейс. Точкой входа для JSON-RPC является http://engine.qik.com/api/jsonrpc. Пока проект находится в закрытом бета-тестировании для доступа к API необходимо указать ключ разработчика, добавив параметр apikey: http://engine.qik.com/api/jsonrpc?apikey=xxxxxxx. Ключ разработчика можно получить, отправив письмо с запросом на api@qik.com.

Пример HTTP-сессии:

POST /api/jsonrpc
Host : engine.stage.qik.com
Content-Type:  application/json; charset=UTF-8
Content-Length: 46

{"method": "qik.session.create", "params": []}

Ответ:

Content-Type: text/json 

["a56c1603-1fbb-4140-8b35-8c36abbd8b27"]

Пример подписки на поток событий

Здесь и далее я буду использовать простую запись вызова команд, которая похожа на вызов обычных функций, опуская детали JSON-RPC взаимодействия. Итак, пусть мы хотим подписаться на список всех live-стримов, которые есть данный момент.

Первым делом создадим сессию:

qik.session.create() -> "a56c1603-1fbb-4140-8b35-8c36abbd8b27"

Подписываемся в рамках сессии на view всех публичных live-стримов, при этом указываем максимальное количество элементов во view (limit). Элементы view будут упорядочены в порядке убывания даты начала стрима (самые новые первыми):

qik.stream.subscribe_public_live("a56c1603-1fbb-4140-8b35-8c36abbd8b27", 10) -> 
 [ "174/('PublicLiveStreamView', 'Stream', [('stoptime', None)], 'alllive;limit=10')", [ ... ] ]

В ответ на запрос мы получаем массив из двух элементов: первым является ключ подписки (длинная строка, начинающаяся с «174/..»). Не ищите смысла в ключе подписки, его необходимо просто сохранить, он потребуется в дальнейшем.

Вторым элементом является начальное состояние view, то есть текущий список live-стримов в нашем случае. Мы получим не больше 10 элементов (так как указали limit 10 при вызове метода qik.stream.subscribe_public_live). Состояние view выглядит примерно следующим образом:

[
   {"url": "http://qik.com/video/2158468", 
    "live": true, 
    "user_id": 340699, 
    "small_thumbnail_url": "http://media.qik.com/media.thumbnails.128/c8ad8fe065ad4ad7ac8491874c043eac.jpg", 
    "title": "Untitled", "duration": 0,
    "created_at": "2009-07-11 15:56:03", 
    "views": 0, 
    "id": 2158468}, 
 
   {"url": "http://qik.com/video/2158466", 
    "live": true, 
    "user_id": 340119, 
    "small_thumbnail_url": "http://media.qik.com/media.thumbnails.128/984c33e1ead441038f315e1fff109fc5.jpg", 
     "title": "Testando!", 
     "duration": 0, "created_at": "2009-07-11 15:55:34", 
     "views": 0, 
     "id": 2158466}
]

Смысл большинства полей очевиден, приведу лишь некоторые комментарии:

• все даты приведены в UTC;
• поле duration хранит длительность видео в секундах.

Так как мы подписались на live-стримы, у всех видео live == true.

Теперь нам необходимо получать новые события для тех view, на которые мы подписались. Для этого используются HTTP long polling-запросы. Клиент отправляет запрос серверу, а сервер отправляет ответ, когда появляются события или когда истечет таймаут, если событий не появилось.

Для реализации long polling в цикле вызываем метод qik.session.get_events, указывая желаемый таймаут (не рекомендуется использовать таймаут более 90 секунд).

qik.session.get_events("a56c1603-1fbb-4140-8b35-8c36abbd8b27", 60) -> 
  [ {...} ,{...} ]

В ответ мы можем получить пустой массив событий, если истек таймаут, или некоторый набор событий следующего вида:

[
   {
     "action": "update", 
     "old": {"id": 104252, "title": "Untitled", "views": 0, ...}, 
     "obj": {"id": 104252, "title": "driving to key largo", "views": 5, ...}, 
     "key": "175/('PublicRecentStreamView', 'Stream', [], 'allrecent;limit=50')"
    },
]

В каждом событии обязательно передается следующая инормация:

• key – ключ подписки, это то же самое значение, которое мы получили при подписке на view, ключ позволяет отличать события для разных view в рамках одной сессии;
• action – действие (изменение), произошедшее с view:
  • ping – ничего не произошло, просто view сообщает, что все хорошо
  • update – элемент view изменился (как в примере выше), передается старое и новое состояние объекта в полях old и obj
  • insert – во view добавился новый элемент, его состояние будет записано в поле obj
  • delete – элемент исчез из view (может быть, видео было удалено, или просто перестало удовлетворять критериям view, или ушло за границу «limit»), последнее состояние объекта будет записано в поле obj.

В ответ на события мы можем обновить информацию на экране для пользователя, выполнить какие-либо еще действия. Но обязательно надо отправить новый запрос qik.session.get_events, чтобы получить новые события.

В конце работы не забываем «убраться» за собой, убиваем сессию:

qik.session.destroy("a56c1603-1fbb-4140-8b35-8c36abbd8b27") 

Замечания:

• В рамках одной сессии можно подписаться на произвольное количество view.
• Если это необходимо, можно авторизовать сессию от имени пользователя с помощью qik.session.authorize.
• Существует большое количество вспомогательных запросов, которым сессия вообще не требуется, например qik.user.public_profile.
• Можно отписаться от view при помощи конмадыqik.session.unsubscribe.

Reference JS-клиент

Для демонстрации возможностей Qik Push Engine и проверки его работы был реализован легкий JavaScript-клиент. Его можно увидеть в работе на примерах, полный список которых приведен ниже.

Если вы запустите пример в Firefox с включенным Firebug, в консоли Firebug будет появляться подробная информация о выполняемых запросах к Qik Push Engine API, полученных ответах и т.п.

Исходный код клиента доступен в необфусцированном виде, со всеми комментариями. Код предоставляет по принципам public domain, то есть можете делать с ним все, что захотите – использовать в своих приложениях, модифицировать, переписывать на другие языкаи программирования и т.п.

Пробежимся быстро по компонентам JS-клиента.

prototype.js

Совершенно стандартный Prototype, ничего интересного.

deferred.js

Deferred – это одна из основных концепций Twisted Framework (http://twistedmatrix.com). Deferred не является обязательным для взаимодействия с Qik Push Engine API, но позволяет сильно упростить сложные взаимодействия в асинхронном коде.

В качестве дополнительного материала о Deferred можно почитать про основы работы с Deferred, более сложные случаи использования Deferred, данную реализацию Deferred для Prototype, а также взглянуть на Deferred в других JS-фреймворках: MochiKit, Dojo.

DeferredManager – простая конструкция на основе Deferred, позволяет запускать не более N асинхронных действий в один момент времени.

core.js

Ядро клиента, объявляется namespace QikEngine, отладочные функции, определение конфигурации, создания объекта для доступа к API и т.п.

api.js

QikEngine.API – простая обертка JSON-RPC API Qik Push Engine, возвращающая Deferred в качестве результата любого обращения к API. Через Deferred же отправляются ошибки и результаты выполнения методов.

QikEngine.Session – класс, оборачивающий понятие сессии, создание, уничтожение, авторизация в рамках сессии.

events.js

QikEngine.Events – получение новых событий с помощью HTTP long polling, технология, похожая на BOSH/Comet. Распределение событий подписчикам (конкретным view).

view.js

QikEngine.View – абстрактный класс, представляющий view на стороне клиента. Обслуживание обновлений, отображение в элементах HTML, обработка событий и т.п. Списки элементов хранятся прямо в DOM-контейнере в виде HTML-узлов.

Потомки QikEngine.View для реализации конкретных view: QikEngine.PublicUserStreamView, QikEngine.PublicRecentStreamsView и т.д.

updater.js

Очень простой интерфейс между данными, полученными из Qik Push Engine (например, информацией о стримах) и HTML-элементами. Адаптация данных, например, перевод дат из UTC в локальный формат, форматирование значений и т.п.

usercache.js

QikEngine.UserCache – механизм загрузки информации о пользователях (по их ID). Использует DeferredManager для ограничения количества параллельных запросов.

Что делать дальше?

• смотрите описание API;
• пишите письмо на api@qik.com, расскажите о своем проекте и получайте ключ для доступа к API.

Полный список примеров

• все последние видео на Qik/live-видео
• открытые стримы пользователя
• профайл пользователя с точки зрения другого авторизованного пользователя
• домашняя страница пользователя: собственные стримы, followerы, стримы от following

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

Основная идея состоит в том, что отдельные подсистемы (или независимые приложения) могут обмениваться произвольным образом сообщениями через AMQP-брокер, который осуществляет маршрутизацию, возможно гарантирует доставку, распределение потоков данных, подписку на нужные типы сообщений. В качестве классических примеров обычно приводятся финансовые приложения, связанные, например, с доставкой потребителям информации о курсах ценных бумаг в режиме реального времени, также возможно RPC-взаимодействие двух подсистем, которые не имеют связи друг с другом (взаимодействие через общий протокол AMQP) и так далее и тому подобное.

Сегодня тема доставки информации в реальном времени является крайне актуальной (достаточно вспомнить хотя бы Twitter, Google Wave). И здесь системы передачи сообщений могут служить внутренним механизмом обмена данными, который обеспечивает доставку данных (изменений данных) клиентам.

Я не ставлю своей целью сегодня рассказать о том, как писать приложения для AMQP. Хочу лишь немного рассказать о том, что это совсем не страшно, не очень сложно, и действительно работает, хотя стандарт находится еще в развитии, выходят новые версии протокола, брокеров и т.п. Но это уже вполне production-quality. Расскажу лишь базовые советы, чтобы помочь «въехать» в протокол.

Для начала, маленькая коллекция ссылок (в основном, на английском): что такое вообще обмен сообщениями и почему AMQP такой (Messaging in general and AMQP design); сравнение различных реализаций обмена сообщениями, в частности основанных на AMQP (Message Queue Comparison); клиентская библиотека AMQP для Twisted Framework (Python) с поддержкой Thrift (Thrift, AMQP in Twisted); руководство от Red Hat о том, что такое messaging и как работать с AMQP, описывает их «коробочный» продукт на основе AMQP, но подходит и для любых AMQP-брокеров (AMQP Programming Tutorial for C++, Java, and Python); достаточно много документации, описаний архитектурных решений на сайте ZeroMQ, который не совсем AMQP-брокер, но общая архитектура, детали реализации представляют отдельный интерес; обзорная статья от Duncan McGregor о txAMQP и AMQP в общем (A Simfonia on Messaging with txAMQP, II, III)

Далее необходимо выбрать AMQP-брокер, который вы будете использовать. При выборе необходимо рассматривать как собственно характеристики сервера: скорость работы, надежность, легкость установки и поддержки, но также внимательно смотреть на версию AMQP-протокола, которая поддерживается брокером, – она должна совпадать с версией клиентской AMQP-библиотеки. Из брокеров я бы посоветовал RabbitMQ, написанный на Erlang, и Qpid, версии на C++ (AMQP 0-10) и Java (0-8, 0-9).

Сам протокол AMQP устроен достаточно интересно: на самом нижнем уровне определяется формат кодирования данных в бинарный вид для передачи по TCP-соединению, выше лежит формат передачи RPC-запросов между сервером и клиентом. Сама семантика работы с сообщениями, создания очередей и т.п. описывается в XML-спецификации, которая по сути задает RPC-интерфейс сервера и клиента (примеры таких XML-файлов для версий 0-8 и 0-10). Этот XML является последней и конечной спецификацией протокола. Более того, версии протокола 0-8 и 0-10 отличаются настолько сильно, что поддерживать их одновременно вряд ли возможно в одной программе. Что еще более интересно, иногда такие spec-файлы для разных брокеров AMQP, формально поддерживающих одну и ту же версию протокола, отличаются настолько, что не являются взаимозаменяемыми. Но это скорее небольшие технические проблемы.

AMQP основан на трех понятиях:

1. Сообщение (message) – единица передаваемых данных, основная его часть (содержание) никак не интерпретируется сервером, к сообщению могут быть прицеплены структурированные заголовки.
2. Точка обмена (exchange) – в нее отправляются сообщения. Точка обмена распределяет сообщения в одну или несколько очередей. При этом в точке обмена сообщения не хранятся. Точки обмена бывают трех типов: fanout – сообщение передается во все прицепленные к ней очереди; direct – сообщение передается в очередь с именем, совпадающим с ключом маршрутизации (routing key) (ключ маршрутизации указывается при отправке сообщения); topic – нечто среднее между fanout и exchange, сообщение передается в очереди, для которых совпадает маска на ключ маршрутизации, например, app.notification.sms.* – в очередь будут доставлены все сообщения, отправленные с ключами, начинающимися на app.notification.sms.
3. Очередь (queue) – здесь хранятся сообщения до тех пор, пока не будет забраны клиентом. Клиент всегда забирает сообщения из одной или нескольких очередей.

Меня в AMQP привлек эффективный бинарный протокол, ориентированность протокола на минимальные задержки и гибкость настройки. Я его использовал для рассылки сообщений всем серверам кластера (fanout exchange) и организации аналогов «почтовых ящиков», в которые доставляются сообщения, адресованные определенным клиентам (direct exchange). Для получения сообщений нет необходимости опрашивать сервер, достаточно подписаться на сообщения из очереди, и сервер передаст их в тот момент, когда они появятся.

В качестве клиентской библиотеки я выбрал библиотеку txAMQP для Twisted Framework (Python). В общем и целом все работает, но где-то требуются небольшие «доделки» и «подкрутки», которые я планирую опубликовать на launchpad. В AMQP и вокруг AMQP есть много интересного и перспективного. К примеру, брокер RabbitMQ умеет масштабироваться и работать в едином кластере. Мне кажется, это очень полезная и перспективная технология.

Итак, что есть на сегодняшний день:

• Реализация RTMP-протокола: кодирование/декодирование пакетов, разрезание и склеивание из chunks и т.п.
• Поддержка базового RPC (Invoke) клиент-сервер и сервер-клиент. То есть из Flash-приложения можно вызывать с помощью класса NetConnection методы приложения на стороне сервера, и наоборот со стороны сервера вызывать методы приложения.
• Инфраструктура для написания приложений (в качестве плагинов к FMSPy) со своим API на Python.

В ближайших релизах:

• Стриминг (вещание) с вебкамеры, стриминг видео/аудио с сервера (FLV, MP4, MP3).
• Поддержка серверных Shared Object.
• Анализ загрузки, полуавтоматическая кластеризация для распределения нагрузки.

FMSPy написан на Python с использованием Twisted Framework, приложения на FMSPy реализуются также на Python и им доступны все возможности, которые есть в Twisted: асинхронная сетевая модель, соединения с БД, memcached, различные сервисы и т.п.

Запуск и установка

Если у Вас уже установлен Python и setuptools (чаще всего на Unix/Linux это так), достаточно выполнить от имени root:

easy_install fmspy

Easy_install автоматически установит все необходимые зависимости (если они еще не установлены). Более подробно об установке можно почитать в документации.

После установки запуск в отладочном режиме (на консоли) осуществляется следующим образом:

twistd -n fmspy

Для окончания работы сервера достаточно нажать Ctrl+C.

Примеры

Вместе с FMSPy устанавливается два примера: эхотест и простенький чат. После запуска откройте страницу http://localhost:3000/examples/ и выберите интересующий вас.

Вместо заключения

Пробуйте, тестируйте, присоединяйтесь к разработке. Любая помощь приветствуется: написание документации, патчи, идеи новых фич, графические материалы! Все это лучше всего отправить в трекер.

Впереди новые релизы, также в ближайшее время статья о написании приложений для FMSPy.

Ссылки:

• Сайт проекта, трекер
• Документация

Продолжая тему Deferred для JavaScript предлагаю еще одно переписывание Deferred, теперь в терминах Prototype. Подробнее о самом Deferred можно почитать в двух моих прошлых заметках: Асинхронное программирование: концепция Deferred и Deferred: все подробности. Если кратко, самое распространенное и полезное применение Deferred в JavaScript – это работа с AJAX или другими RPC-over-HTTP вызовами, когда необходимо совершить цепочку логически связанных вызовов, корректно обрабатывать возникающие ошибки и т.п. С моей точки зрения, Deferred крайне необходим в таких ситуациях.

Перейдем к примерам: обращение к некоторому JSON-RPC API на основе Prototype’овского Ajax.Request можеть быть обернуто в Deferred следующим образом:

var Api = Class.create({
    initialize : function(url)
    {
        this.url = url;
    },
 
    call : function(method, params)
    {
        var requestBody = $H({ 'method' : method, 'params' : params }).toJSON();
        var d = new Deferred();
 
        var onSuccess = function(transport)
        {
            result = transport.responseText.evalJSON();
            if ('faultCode' in result && 'faultString' in result)
            {
                var err = new Error(result.faultString);
                err.faultCode = result.faultCode;
                err.faultString = result.faultString;
                d.errback(err);
            }
            else
            {
                result = result[0];
                console.log("Got result: ", result);
                d.callback(result);
            }
        };
 
        var onFailure = function(transport)
        {
            d.errback(new Error("API transport error: " + transport.status))
        };
 
        var onException = function(error)
        {
            d.errback(error);
        }
 
        new Ajax.Request(this.url, {
                method : 'post',
                postBody : requestBody,
                requestHeaders : { 'Content-Type' : 'application/json' },
                onSuccess : onSuccess,
                onFailure : onFailure,
                onException : onException,
            });
 
        return d;
    },
});

Здесь любое обращение к Api.call будет возвращать новый Deferred, который будет содержать результат удаленного вызова либо исключение (транспортное или от сервера, к которому мы обращаемся). Пусть есть RPC-вызовы sum и mult, которые, соответственно, складывают и перемножают свои аргументы. Тогда вычисление выражения (2+3)*7 с использованием нашего класса Api будет выглядеть так:

  var api = new Api;
  api.call('sum', [2, 3])
     .addCallback(
               function (sum_of_2_and_3) 
               { 
                     return api.call('mult', [sum_of_2_and_3, 7]); 
               })
     .addCallback(
               function(result)
               { 
                     alert('(2+3)*7 = ' + result); 
               })
     .addErrback(
              function (error) 
              { 
                     alert('Mmm.. something wrong happened: ' + error); 
              });

Ну и самое главное:

• исходный код Deferred.js;
• лицензия MIT, как и у самого первого варианта Deferred для JavaScript.

В качестве сообщений могут рассматриваться, например, следующие виды общения, которые сегодня есть в социальных сетях (и веб-сайтах, имеющих элементы социальной сети):

• личные сообщения;
• чаты;
• комментарии к произвольным объектам;
• девизы, сообщения «о себе» и т.п. на страницах профиля пользователя;
• письма в службу поддержки.

Фильтрация и классификация сообщений основывается на нескольких независимых алгоритмах; результатом классификации может являться классификация как самого сообщения (причём, возможно, по нескольким категориям: спам, флуд, проституция и т.п.), так и классификация отправителей сообщений (как авторизованных, так и неавторизованных, по тем же самым категориям: спамер, флудер и т.п.). Применение классификации к отправителям сообщений позволяет на раннем этапе пресекать попытки спам-рассылок и тому подобных массовых действий на сайте.

Данный релиз является первым публичным релизом проекта СпамоБорец. Качество и полнота функционала соответствует на сегодняшний день альфа-версии.

На сегодня доступен следующий функционал:

• веб-сервис с JSON-RPC и XML-RPC API (описание API);
• создание и запуск из отдельного окружения;
• firewall из правил анализа сообщений;
• гибкая настройка содержимого сообщений;
• анализ текста сообщений на флуд;
• анализ частоты сообщений по тексту и атрибутам автора: логин, IP и т.п.;
• простая Байесовская модель анализа текста (тестовая);
• валидация сообщений по длине, наличию атрибутов, регулярному выражению;
• логирование сообщений, проходящих через сервер;
• система администрирования и настройки (qooxdoo, см. скриншоты);
• реализация клиентов API на PHP и тестовый модуль для WordPress.

Как установить

Нужен python и setuptools:

easy_install spamfighter

После этого выбираем каталог для окружения (например, ~/spamfighter) и запускаем:

spamfighter-create ~/spamfighter

Далее следуем инструкциям на экране. Более подробную информация об установке можно найти в документации по СпамоБорцу.

Что дальше?

Этот пост – уведомление о выходе новой версии, за ним последует более подробный рассказ «для чего это нужно» и «как это использовать». Надеемся на позитивный feedback и участие в жизни проекта.

Итак, Deferred – это отложенный результат, результат выполнения, который станет известен через некоторое время. Результатом, хранящимся в Deferred, может быть произвольное значение (успешное выполнение) или ошибка (исключение), которое произошло в процессе выполнения асинхронной операции. Раз нас интересует результат операции и мы получили от некоторой асинхронной функции Deferred, мы хотим выполнить действия в тот момент, когда результат выполнения будет известен. Поэтому Deferred кроме результата хранит еще цепочку обработчиков: обработчиков результатов (callback) и обработчиков ошибок (errback).

Рассмотрим поподробнее цепочку обработчиков:

Обработчики располагаются по «слоям» или уровням, выполнение происходит четко по уровням сверху вниз. При этом на каждом уровне расположены обработчики callback и errback, один из элементов может отсутствовать. На каждом уровне может быть выполнен либо callback, либо errback, но не оба. Выполнение обработчиков происходит только один раз, повторного входа быть не может.

Функции-обработчики callback являются функциями с одним аргументом – результатом выполнения:

def callback(result):
    ...

Функции-обработчики errback принимают в качестве параметра исключение, «завернутое» в класс Failure:

def errback(failure):
    ...

Выполнение Deferred начинается с того, что в Deferred появляется результат: успешное выполнение или исключение. В зависимости от результата выбирается соответствующая ветвь обработчиков: callback или errback. После этого происходит поиск ближайшего уровня обработчиков, в котором существует соответствующий обработчик. В нашем примере на рисунке был получен успешный результат выполнения и результат был передан обработчику callback1.

Дальнейшее выполнение приводит к вызову обработчиков на нижележащих уровнях. Если callback или errback завершается возвратом значения, которое не является Failure, выполнение считается успешным и полученный результат отправляется на вход callback-обработчику на следующем уровне. Если же в процессе выполнения обработчика было выкинуто исключение или возвращено значение типа Failure, управление будет передано errback на следующем уровне, который получит исключение в качестве параметра.

В нашем примере обработчик callback1 выполнился успешно, его результат был передан обработчику callback2, в котором было выкинуто исключение, которое привело к переходу к цепочке errback-обработчиков, на третьем уровне обработчик errback отсутствовал и исключение было передано в errback4, который обработал исключение, вернул успешный результат выполнения, который теперь является результатом Deferred, однако больше обработчиков нет. Если к Deferred будет добавлен еще один уровень обработчиков, они смогут получить доступ к этому результату.

Как и все другие объекты Python, объект Deferred живет до тех пор, пока на него есть ссылки из других объектов. Обычно объект, вернувший Deferred, сохраняет его, т.к. ему надо по завершении асинхронной операции передать в Deferred полученный результат. Чаще всего другие участники (добавляющие обработчики событий) не сохраняют ссылки на Deferred, таким образом объект Deferred будет уничтожен по окончании цепочки обработчиков. Если происходит уничтожение Deferred, в котором осталось необработанное исключение (выполнение завершилось исключением и больше обработчиков нет), на экран печатается отладочное сообщение с traceback исключения. Эта ситуация аналогична «выскакиванию» необработанного исключения на верхний уровень в обычной синхронной программе.

Deferred в квадрате

Возвращаемым значением callback и errback может быть также другой Deferred, тогда выполнение цепочки обработчиков текущего Deferred приостанавливается до окончания цепочки обработчиков вложенного Deferred.

В приведенном на рисунке примере обработчик callback2 возвращает не обычный результат, а другой Deferred – Deferred2. При этом выполнение текущего Deferred приостанавливается до получения результата выполнения Deferred2. Результат Deferred2 – успешный или исключение – становится результатом, передаваемым на следующий уровень обработчиков первого Deferred. В нашем примере Deferred2 завершился с исключением, которое будет передано на вход обработчику errback2 первого Deferred.

Обработка исключений в errback

Каждый обработчик исключений errback является аналогом блока try..except, а блок except обычно реагирует на некоторый тип исключений, такое поведение очень просто воспроизвести с помощью Failure:

def errback(failure):
    """
    @param failure: ошибка (исключение), завернутое в failure
    @type failure: C{Failure}
    """
    failure.trap(KeyError)
 
    print "Got key error: %r" % failure.value
 
    return 0

Метод trap класса Failure проверяет, является ли завернутое в него исключение наследником или непосредственно классом KeyError. Если это не так, оригинальное исключение снова выбрасывается, прерывая выполнение текущего errback, что приведет к передаче управления следующему errback в цепочке обработчиков, что имитирует поведение блока except при несоответствии типа исключения (управление передается следующему блоку). В свойстве value хранится оригинальное исключение, которое можно использовать для получения дополнительной информации об ошибке.

Необходимо обратить внимание, что обработчик errback должен завершиться одним из двух способов:

1. Вернуть некоторое значение, которое станет входным значением следующего callback, что по смыслу означает, что исключение было обработано.
2. Выкинуть оригинальное или новое исключение – исключение не было обработано или было перевыброшено новое исключение, цепочка обработчиков errback продолжается.

Существует и третий вариант – вернуть Deferred, тогда дальнейшее выполнение обработчиков будет зависеть от результата Deferred.

В нашем примере мы исключение обработали и передали в качестве результата 0 (например, отсутствие некоторого ключа эквивалентно его нулевому значению).

Готовимся к асинхронности заранее

Как только появляется асинхронность, то есть некоторая функция вместо непосредственного значения возвращает Deferred, асинхронность начинает распространяться по дереву функций выше, заставляя возвращать Deferred из функций, которые раньше были синхронными (возвращали результат непосредственно). Рассмотрим условный пример такого превращения:

def f():
    return 33
 
def g():
    return f()*2

Если по каким-то причинам функция f не сможет вернуть результат сразу, она начнет возвращать Deferred:

def f():
    return Deferred().callback(33)

Но теперь и функция g вынуждена возращать Deferred, зацепляясь за цепочку обработчиков:

def g():
    return f().addCallback(lambda result: result*2)

Аналогичная схема «превращения» происходит и с реальными функциями: мы получаем результаты в виде Deferred от нижележащих в дереве вызовов функции, навешиваем на их Deferred свои обработчики callback, которые соответствуют старому, синхронному коду нашей функции, если у нас были обработчики исключений, добавляются и обработчики errback.

На практике лучше сначала выявить те места кода, которые будут асинхронными и будут использовать Deferred, чем переделывать синхронный код в асинхронный. Асинхронный код начинается с тех вызовов, которые не могут построить результат непосредственно:

• сетевой ввод-вывод;
• обращение к сетевым сервисам СУБД, memcached;
• удаленные вызовы RPC;
• операции, выполнение которых будет выделено в нить в модели Worker и т.п.

В процессе написания приложения часто ясно, что в данной точке будет асинхронное обращение, но его еще нет (не реализован интерфейс с СУБД, например). В такой ситуации можно использовать функции defer.success или defer.fail для создания Deferred, в котором уже содержится результат. Вот как можно короче переписать функцию f:

from twisted.internet import defer
 
def f():
    return defer.success(33)

Если мы не знаем, будет ли вызываемая функция возвращать результат синхронно или вернет Deferred, и не хотим зависеть от её поведения, мы можем завернуть обращение к ней в defer.maybeDeferred, которое любой вариант сделает эквивалентным вызову Deferred:

from twisted.internet import defer
 
def g():
    return defer.maybeDeferred(f).addCallback(lambda result: result*2)

Такой вариант функции g будет работать как с синхронной, так и с асинхронной f.

Вместо заключения

Рассказывать о Deferred можно еще очень долго, в качестве дополнительного чтения могу опять порекомендовать список материалов в конце предыдущей статьи.

Первый пример – сетевой сервер, веб-приложение. Чаще всего как таковых вычислений на процессоре такие приложения не выполняют. Большая часть времени (реального, не процессорного) тратится на ввод-вывод: чтение запроса от клиента, обращение к диску за данными, сетевые обращение к другим подсистемам (БД, кэширующие сервера, RPC и т.п.), запись ответа клиенту. Во время этих операций ввода-вывода процессор простаивает, его можно загрузить обработкой запросов других клиентов. Возможны различные способы решить эту задачу: отдельный процесс на каждое соединение (Apache mpm_prefork, PostgreSQL, PHP FastCGI), отдельный поток (нить) на каждое соединение или комбинированный вариант процесс/нить (Apache mpm_worker, MySQL). Подход с использованием процессов или нитей перекладывает мультиплексирование процессора между обрабатываемыми соединениями на ОС, при этом расходуется относительно много ресурсов (память, переключения контекста и т.п.), такой вариант не подходит для обработки большого количества одновременных соединений, но идеален для ситуации, когда объем вычислений достаточно высок (например, в СУБД). К плюсам модели нитей и процессов можно добавить потенциальное использование всех доступных процессоров в многопроцессорной архитектуре.

Альтернативой является использование однопоточной модели с использованием примитивов асинхронного ввода-вывода, предоставляемых ОС (select, poll, и т.п.). При этом объем ресурсов на каждое новое обслуживаемое соединение не такой большой (новый сокет, какие-то структуры в памяти приложения). Однако программирование существенно усложняется, т.к. данные из сетевых сокетов поступают некоторыми «отрывками», причем за один цикл обработки данные поступают от разных соединений, находящихся в разных состояниях, часть соединений могут быть входящими от клиентов, часть – исходящими к внешним ресурсам (БД, другой сервер и т.п.). Для упрощения разработки используются различные концепции: callback, конечные автоматы и другие. Примеры сетевых серверов, использующих асинхронный ввод-вывод: nginx, lighttpd, HAProxy, pgBouncer, и т.д. Именно при такой однопоточной модели возникает необходимость в асинхронном программировании. Например, мы хотим выполнить запрос в БД. С точки зрения программы выполнение запроса – это сетевой ввод-вывод: соединение с сервером, отправка запроса, ожидание ответа, чтение ответа сервера БД. Поэтому если мы вызываем функцию «выполнить запрос БД», то она сразу вернуть результат не сможет (иначе она должна была бы заблокироваться), а вернет лишь нечто, что позволит впоследствие получить результат запроса или, возможно, ошибку (нет соединения с сервером, некорректный запрос и т.п.) Этим возвращаемым значением удобно сделать именно Deferred.

Второй пример связан с разработкой обычных десктопных приложений. Предположим, мы решили сделать аналог Miranda (QIP, MDC, …), то есть свой мессенджер. В интерфейсе программы есть контакт-лист, где можно удалить контакт. Когда пользователь выбирает это действие, он ожидает что контакт исчезнет на экране и что он действительно удалится из контакт-листа. На самом деле операция удаления из серверного контакт-листа опирается на сетевое взаимодействие с сервером, при этом пользовательский интерфейс не должен быть заблокирован на время выполнения этой операции, поэтому в любом случае после выполнения операции потребуется некоторое асинхронное взаимодействие с результатом операции. Можно использовать механизм сигналов-слотов, callback’ов или что-то еще, но лучше всего подойдет Deferred: операция удаления из контакт-листа возвращает Deferred, в котором обратно придет либо положительный результат (всё хорошо), либо исключение (точная ошибка, которую надо сообщить пользователю): в случае ошибки контакт надо восстановить контакт в контакт-листе.

Примеры можно приводить долго и много, теперь о том, что же такое Deferred. Deferred – это сердце framework’а асинхронного сетевого программирования Twisted в Python. Это простая и стройная концепция, которая позволяет перевести синхронное программирование в асинхронный код, не изобретая велосипед для каждой ситуации и обеспечивая высокое качества кода. Deferred – это просто возвращаемый результат функции, когда этот результат неизвестен (не был получен, будет получен в другой нити и т.п.) Что мы можем сделать с Deferred? Мы можем «подвеситься» в цепочку обработчиков, которые будут вызваны, когда результат будет получен. При этом Deferred может нести не только положительный результат выполнения, но и исключения, сгенерированные функцией или обработчиками, есть возможность исключения обработать, перевыкинуть и т.д. Фактически, для синхронного кода есть более-менее однозначная параллель в терминах Deferred. Для эффективной разработки с Deferred оказываются полезными такие возможности языка программирования, как замыкания, лямбда-функци.

Приведем пример синхронного кода и его альтернативу в терминах Deferred:

try:
    # Скачать по HTTP некоторую страницу
    page = downloadPage(url)
    # Распечатать содержимое
    print page
except HTTPError, e:
    # Произошла ошибка
    print "An error occured: %s", e

В асинхронном варианте с Deferred он был бы записан следующим образом:

def printContents(contents):
    """
    Callback, при успешном получении текста страницы,
    распечатываем её содержимое.
    """
    print contents
 
def handleError(failure):
    """
    Errback (обработчик ошибок), просто распечатываем текст ошибки.
    """
 
    # Мы готовы обработать только HTTPError, остальные исключения
    # "проваливаются" ниже.
    failure.trap(HTTPError)
    # Распечатываем само исключение
    print "An error occured: %s", failure
 
# Теперь функция выполняется асинхронно и вместо непосредственного
# результата мы получаем Deferred
deferred = downloadPage(url)
# Навешиваем на Deferred-объект обработчики успешных результатов
# и ошибок (callback, errback).
deferred.addCallback(printContents)
deferred.addErrback(handleError)

На практике обычно мы возвращаем Deferred из функций, которые получают Deferred в процессе своей работы, навешиваем большое количество обработчиков, обрабатываем исключения, некоторые исключения возвращаем через Deferred (выбрасываем наверх). В качестве более сложного примера приведем код в асинхронном варианте для примера атомарного счетчика из статьи про структуры данных в memcached, здесь мы предполагаем, что доступ к memcached как сетевому сервису идет через Deferred, т.е. методы класса Memcache возвращают Deferred (который вернет либо результат операции, либо ошибку):

class MCCounter(MemcacheObject):
    def __init__(self, mc, name):
        """
        Конструктор.
 
        @param name: имя счетчика
        @type name: C{str}
        """
        super(MCCounter, self).__init__(mc)
        self.key = 'counter' + name
 
    def increment(self, value=1):
        """
        Увеличить значение счетчика на указанное значение.
 
        @param value: инкремент
        @type value: C{int}
        @return: Deferred, результат операции
        """
        def tryAdd(failure):
            # Обрабатываем только KeyError, всё остальное "вывалится"
            # ниже
            failure.trap(KeyError)
 
            # Пытаемся создать ключ, если раз его еще нет
            d = self.mc.add(self.key, value, 0)
            # Если вдруг кто-то еще создаст ключ раньше нас,
            # мы это обработаем
            d.addErrback(tryIncr)
            # Возвращаем Deferred, он "вклеивается" в цепочку
            # Deferred, в контексте которого мы выполняемся
            return d
 
        def tryIncr(failure):
            # Всё аналогично функции tryAdd
            failure.trap(KeyError)
 
            d = self.mc.incr(self.key, value)
            d.addErrback(tryAdd)
            return d
 
        # Пытаемся выполнить инкремент, получаем Deferred
        d = self.mc.incr(self.key, value)
        # Обрабатываем ошибку
        d.addErrback(tryAdd)
        # Возвращаем Deferred вызывающему коду, он может тем самым:
        #  а) узнать, когда операция действительно завершится
        #  б) обработать необработанные нами ошибки (например, разрыв соединения)
        return d
 
    def value(self):
        """
        Получить значение счетчика.
 
        @return: текущее значение счетчика
        @rtype: C{int}
        @return: Deferred, значение счетчика
        """
        def handleKeyError(failure):
            # Обрабатываем только KeyError
            failure.trap(KeyError)
 
            # Ключа нет - возвращаем 0, он станет результатом
            # вышележащего Deferred
            return 0
 
        # Пытаемся получить значение ключа
        d = self.mc.get(self.key)
        # Будем обрабатывать ошибку отсутствия ключа
        d.addErrback(handleKeyError)
        # Возвращаем Deferred, наверх там можно будет повеситься
        # на его callback и получить искомое значение счетчика
        return d

На практике приведенный выше код можно написать «короче», объединяя часто используемые операции, например:

    return self.mc.get(self.key).addErrback(handleKeyError)

Практически для каждой конструкции синхронного кода можно найти аналог в асинхронной концепции с Deferred:

• последовательности синхронных операторов соответствует цепочка callback с асинхронными вызовами;
• вызову одной подпрграммы с вводом-выводом из другой соответствует возврат Deferred из Deferred (ветвление Deferred);
• глубокой цепочки вложенности, распространению исключений по стеку соответствует цепочка функций, возвращающие друг другу Deferred;
• блокам try..except соответствуют обработчики ошибок (errback), которые могут «пробрасывать» исключения дальше, любое исключение в callback переводит выполнение в errback;
• для «параллельного» выполнения асинхронных операций есть DeferredList.

Нити часто применяются в асинхронных программах для осуществления вычислительных процедур, осуществления блокирующегося ввода-вывода (когда не существует асинхронного аналога). Всё это легко моделируется в простой модели ‘worker’, тогда нет необходимости при грамотной архитектуре в явной синхронизации, при этом всё элегантно включается в общий поток вычислений с помощью Deferred:

def doCalculation(a, b):
    """
    В этой функции осуществляются вычисления, синхронные операции ввода-вывода,
    не затрагивающие основной поток.
    """
 
    return a/b
 
def printResult(result):
    print result
 
def handleDivisionByZero(failure):
    failure.trap(ZeroDivisionError)
 
    print "Ooops! Division by zero!"
 
deferToThread(doCalculation, 3, 2).addCallback(printResult).addCallback(
    lambda _: deferToThread(doCalculation, 3, 0).addErrback(handleDivisionByZero))

В приведенном выше примере функция deferToThread переносит выполнение указанной функции в отдельную нить и возвращает Deferred, через который будет асинхронно получен результат выполнения функции или исключение, если они будет выброшено. Первое деление (3/2) выполняется в отдельной нити, затем распечатывается его результат на экран, а затем запускается еще одно вычисление (3/0), которое генерирует исключение, обрабатываемое функцией handleDivisionByZero.

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

Дополнительные материалы

• Документация Twisted Framework:
  • Основы асинхронного программирования
  • Использование Deferred, Откуда берутся Deferred?, Детальное описание Deferred
• Deferred в других языках программирования:
  • JavaScript: Использование Deferred в JavaScript, Deferred в qooxdoo, Deferred в Dojo, Deferred в MochiKit
  • C++: 1, 2, 3
  • …
• Александр Бурцев о Twisted

Итак, у меня был блок кода, похожий на пример ниже:

1
2
3
4
5
6
7
8
9
10

from twisted.python import log
 
def catcher(f):
  try:
    return f()
  except GoodException:
    return 'ERROR'
  except:
    log.err()
    raise UnknownException

По смыслу он должен был логировать все неожиданные исключения и заменять их на более разумные. Я написал юнит-тест на такую функцию примерно следующего вида:

1
2
3
4

def testCatcher():
  def raiseBadException():
    assert False 
  self.assertEquals('ERROR', catcher, raiseBadException)

При запуске юнит-тест говорил, что он завершился с ошибкой, т.к. было выброшено исключение exceptions.AssertionError, т.е. то исключение, которое генерирует строка 3 в тесте. Но ведь оно было поймано catcher? Я долго бился с этой ситуацией (на самом деле код был сложнее, но суть его от этого не менялась), пока не понял, что если из-под trial (запускальщика юнит-тестов) сделать twisted.python.log.err, то вместо того, чтобы вывести в лог исключение, он помечает тест как ошибочный, при этом в качестве причины ошибки выводит текущее исключение! То есть тест отрабатывал штатно, но log.err() мой помечал его как ошибочный.

Вот такое вот не совсем очевидное взаимодействие…

Update: на самом деле «правильный» способ это исправить – использовать TestCase.flushLoggedErrors. Спасибо @paaleksey за наводку.