Благодаря сайту Insight IT, компания RDM-Soft нашла ОТЛИЧНОГО тимлида! Теперь, тимлидер ищет в свою команду единомышленников и просто IT-звезд.

О компании

История компании началась в 2003 году. С этого момента выпущено много проектов. Некоторыми из них Вы, возможно, так или иначе пользовались. Сейчас запускается еще один проект: SEO-биржа (родственником будет sape.ru). У Вас есть прекрасная возможность оказаться у истоков будущего хита!

Кто нужен?

• Mr. Backend. Он же программист.
• Мастер-ломастер. Он же инженер по контролю качества, проще говоря тестер.
• Dr. Frontend. Он же фронтендщик.

Mr. Backend

Требования

• Отличные знания: PHP, ООП, SQL, MVC, ZendFramework (либо альтернатив), Linux.
• Опыт работы по специальности: от 3 лет.
• Опыт работы в команде.
• Желание развиваться и изучать новое.
• Отсутствие желания искать работу в ближайшие 3 года.

Задачи

• Разработка серверной части проекта. Включает в себя :
  • бухгалтерия;
  • бизнес-логика;
  • статистика;
  • различные парсеры.

Мастер-Ломастер (SQA)

Требования

• Хорошие знания: PHP, SQL, Linux.
• Отличные знания принципов whitebox и blackbox тестирования.
• Опыт работы по специальности: от 2 лет.
• Опыт работы в команде.
• Желание развиваться и изучать новое.
• Отсутствие желания искать работу в ближайшие 3 года.

Задачи

• Написание юнит-тестов, автотестов.
• Тестирование:
• бекенда;
• фронтенда;
• бизнес-логики;
• производительности;
• безопасности.
• В общем, тоже очень много интересной работы.

Dr. Frontend

Условия

Чтобы заявить свои права на одну из вакансий, заполните форму

Instagram — всего лишь iOS, а теперь и Android, приложение для обмена фотографиями с друзьями. Последнее время находится на слуху благодаря новости о покупке проекта Facebook'ом за кругленькую сумму. Недавно один из основателей проекта, Mike Krieger, выступил на конференции с докладом о техническом аспекте проекта, который я и хотел бы вкратце пересказать.

Статистика

• Начало:
• 1 сервер слабее Macbook Pro
• 25к регистраций в первый день
• 2 разработчика
• Сегодня:
• 40+ миллионов пользователей
• 100+ виртуальных серверов в EC2, в том числе:
• Проект куплен Facebook за 1 млрд. долл
• 1 миллион регистраций за 12 часов после запуска Android-версии
• 5 разработчиков

Технологии

• Ubuntu Linux 11.04 — основная операционная система
• Python — основной язык программирования серверной части
• Django — фреймворк
• Amazon:
• EC2 - хостинг
• ELB - балансировка входящих HTTP-запросов
• Route53 — DNS
• S3 — хранение фотографий
• CloudFront — CDN
• nginx — второй уровень балансировки входящих HTTP-запросов
• gunicorn — WSGI-сервер
• HAProxy - балансировка нагрузки внутри системы
• PostgreSQL — основное хранилище данных
• postgis — поддержка гео-запросов
• pgfouine — отчеты на основе логов
• pgbouncer — создание пула соединений
• Redis — дополнительное хранилище данных
• Memcached — кэширование
• Gearman — очередь задач
• Solr — гео-поиск
• munin, statsd, pingdom — мониторинг
• Fabric — управление кластером
• xfs — файловая система

Философия

История

• Забыли сделать favicon.ico до запуска — в первый же день логи пестрили ошибками 404
• Для хранения данных использовали просто Django ORM и PostgreSQL (из-за postgis)
• Начали с одного слабого сервера, после успешного запуска решили переехать на EC2
• Довольно быстро пришлось вынести СУБД на отдельный сервер (виртуальный, естественно)
• Количество фотографий продолжало расти и расти, даже самый большой инстанс EC2 не справлялся
• Решили вертикально разделить данные на несколько баз, с использованием механизма routers из ORM, параллельно избавившись от внешних ключей
• Через несколько месяцев суммарный размер базы данных перевалил за 60Гб и перестало справляться и это решение
• Следующим шагом стало горизонтальное разбиение данных (sharding):
• Создали несколько тысяч логических баз данных.
• Распределили их по существенно меньшему количеству физических серверов (читай: виртуальных машин).
• Написали свой механизм определения где искать какую базу данных, с поддержкой миграции (вероятно тоже на основе routers).
• По последним данным под PostgreSQL используется 12+12 виртуальных машин с максимальной оперативной памятью (68.4Гб), а также сетевые диски EBS, объединенные в программный RAID посредством mdadm. Это необходимо, чтобы весь массив данных помещался в памяти, EBS не в состоянии обеспечить достаточную производительность.
• С некоторыми задачами лучше справляется Redis:
• Для каждого пользователя в Redis есть список идентификаторов новых фотографий от других пользователей, на которых он подписан.
• При отображении потока новых для пользователя фотографий делается выборка части такого списка, после чего посредством multiget достается подробная о них информация из memcached.
• Пробовали возложить на него задачу хранения списков подписчиков, но в итоге вернулись к решению на PostgreSQL с небольшим кэшированием.
• В Redis также хранится информация о сессиях.
• Несколько фактов о Redis:
• Так как все находится в памяти — очень быстрые операции записи и работы с множествами.
• Является не заменой, а дополнением к основному хранилищу данных.
• Redis хорош для структур данных, которые относительно ограничены.
• Отлично подходит для кэширования комплексных структур данных, где нужно большее, чем просто получить значение по ключу (например — счетчики, подмножества, проверка вхождения в множества).
• Механизм репликации (посредством slaveof) позволяет легко масштабировать операции чтения.
• Пользователи синхронно загружают фотографии на медиа-сервер с (опциональными) заголовком и месте на карте, все остальное происходит асинхронно посредством очередей, например:
• Сохраняются гео-метки, обновляется Solr (который впоследствии заменил postgis).
• Идентификатор нового фото добавляется в обсуждавшиеся выше списки для всех подписчиков автора.
• Поначалу использовали Apache + mod_wsgi для запуска Django, впоследствии перешли к gunicorn из-за меньшего потребления ресурсов и простоты настройки.
• С недавних пор начали использовать Amazon ELB вместо DNS round-robin для первичной балансировки входяших HTTP-запросов, что позволило:
• избежать необходимости дешифровки SSL посредством nginx;
• ускорить исключение из балансировки проблемных серверов.
• Благодаря использованию xfs есть возможность «замораживать» и «размораживать» дисковые массивы при резервном копировании.

Подводим итоги

• Многие проблемы с масштабируемостью — результат банальных человеческих ошибок.
• Масштабирование = замена всех деталей в машине на скорости 150км/ч.
• Заранее сложно узнать как в основном будут обращаться к данным, без реального использования.
• В первую очередь попытайтесь адаптировать известные Вам технологии и инструменты для создания простого и понятного решения, прежде чем бросаться на поиски чего-то нетривиального.
• Дополните свое основное хранилище более гибким компонентом, вроде Redis.
• Постарайтесь не использовать два инструмента для решения одной и той же задачи.
• Оставайтесь гибкими и ловкими = напоминайте себе о том, что на самом деле имеет значение.
• Разрабатывайте решения, к которым не придется постоянно возвращаться из-за их сбоев.
• Активное юнит- и функциональное тестирование стоят потраченного на них времени.
• DRY: не делайте одну и ту же работу несколько раз.
• Слабая связанность посредством уведомлений или сигналов позволяет легко менять структуру проекта.
• Дисковый ввод-вывод часто оказывается узким местом, особенно на EC2.
• Спускаться до C нужно только при необходимости, большую часть работы лучше делать в Python.
• Короткий цикл разработки — залог быстрого развития.
• Частые совместные рассмотрения кода нужны, чтобы все были в курсе происходящего.
• Не изобретайте велосипед.
• Окружите себя с толковыми консультантами.
• Культура открытости вокруг разработки.
• Делитесь с opensource сообществом.
• Фокусируйтесь на том, что вы делаете лучше всего.
• Вашим пользователям абсолютно без разницы, написали ли Вы собственную СУБД или нет.
• Не переоптимизируйте и не предполагайте заранее как сайт будет расти.
• Не рассчитывайте, что «кто-то еще присоединится к команде и разберется с этим».
• Для социальных стартапов очень мало, или даже совсем нет, нерешимых вопросов, связанных с масштабируемостью.

Источник информации

Упоминавшаяся во вступлении неприлично длинная презентация из 185 слайдов:

На видео, к сожалению, это выступление не записывалось.

Часть информации взята из технического блога Instagram.

Лень — двигатель прогресса

Сегодня мы рассмотрим способ, позволяющий немного упростить себе жизнь при создании интерактивного сайта путем повторного использования шаблонов. Визуально результат будет примерно таким же, как при дублировании бизнес-логики в браузере, но ценой существенно меньших трудозатрат на разработку JavaScript-клиента, да и на серверной части тоже. Хотите узнать как это провернуть?

Общий принцип

Чтобы сразу в голове сложилась нужная картина, начнем с дополненной схемы из статьи про архитектуру интерактивных сайтов:

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

HTML интерфейс просто разбирает HTTP-запросы, отправляет на его основе сообщение(ия) внутренним сервисам, получает в ответ имя шаблона и данные для его заполнения, с помощью шаблонизатора рендерит итоговый HTML и отдает браузеру или роботу.

Интерфейс сериализованных данных (если он, как и обсуждалось ранее, работает через постоянное соединение с браузером) каждому подключившемуся клиенту первым делом отправляет JSON-объект с шаблонами, по крайней мере если их не особо много, иначе лучше «по запросу». При действии пользователя JavaScript-клиент отправляет сообщение с информацией, на его основе интерфейс сериализованных данных передает то же самое (а может и как-то модифицированное) сообщение внутреннему сервису, также получает в ответ имя шаблона и данные и перенаправляет их клиенту (возможно сконвертировав в другой формат). Клиенту остается передать их своему шаблонизатору и заменить результатом его работы какую-то часть уже имеющегося в окне браузера HTML-документа.

Рендеринг

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

• Отсутствие внешних вызовов при рендеринге, то есть на входе только данные, если используются какие-то фильтры или что-то такое — они должны быть частью шаблонизатора.
• Шаблонизатор должен иметь реализацию на JavaScript, так как будет исполняться в том числе и в браузере.

Да, многофункциональные шаблонизаторы вроде Jinja2 — это очень удобно, но конкретно в данном случае богатый ассортимент возможностей не уместен. Наиболее известный кроссплатформенный шаблонизатор, не обремененный ничем лишним, называется mustache. С его использованием иногда получаются довольно замысловатые конструкции, но зато он отлично подходит под этот сценарий использования и прост как три копейки, изучить можно за 5 минут, рекомендую.

В этой схеме напрашивается использование node.js для реализации HTML-интерфейса, что откроет доступ к многочисленным шаблонизаторам, реализованным исключительно на JavaScript. Тем более кроме рендеринга шаблонов эта часть проекта практически ничего и не делает. В качестве бонуса требование про отсутствие внешних вызовов станет не таким строгим, да и в целом, если минималистичное решение вроде mustache по каким-то идеологическим соображениям не устраивает — любой написанный для node.js шаблонизатор наверняка станет отличным выходом.

Структура шаблонов

При рендеринге на клиентской стороне обычно нужно заменять лишь содержимое определенного блока, где располагается основной контент сайта. Изменения в в других частях сайта нужны существенно реже, соответственно стоит вынести их в отдельные шаблоны.

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

• Блока <head> документа
• Видимой «шапки» сайта
• Сайдбара(ов), если они не сильно зависят от основного контентом страниц
• Видимого «подвала» сайта плюс тегов для подключения JavaScript

HTML-интерфейс при чтении их из файловой системы «склеивает» их в полные шаблоны для каждой страницы, просто конкатенацией или с использованием механизмов шаблонизатора. Интерфейс сериализованных данных «заворачивает» шаблоны страниц в JSON (или другой используемый формат) прямо в исходном виде для вставки в блок с основным контентом. Из «общесайтовых» шаблонов браузерному клиенту вероятно могут понадобиться только сайдбар(ы), и то не всегда.

Изменения в остальных частях сайта лучше все же отдать на совесть представлений на основе клиентского фреймворка. В первую очередь это касается изменения <title> и других мета-тегов.

Примечания

• При использовании минималистичного шаблонизатора без внешних вызовов будьте морально готовы передавать ему «многоуровневые» объекты для вставки в шаблон. Например, если говорить о постраничной навигации, там, где в продвинутом шаблонизаторе было бы что-то вроде {% pagination (current_page, total_pages) %}, может понадобится не тольно написать саму верстку (что, в целом, хорошая практика), а еще и передать информацию о точном списке страниц, какая именно из них активная, где пропуски и пр.
• Стоит обращать внимание на производительность используемого шаблонизатора. Например, под одну из платформ «официальная» реализация mustache, как оказалось, проигрывает сторонней с отрывом в 2 порядка.
• Хоть при таком подходе добиться одинакового внешнего вида страниц при рендеринге серверной и клиентской частью достаточно легко, следить за их соответствием все же стоит — какие-то детали можно и упустить.

Заключение

Как я уже намекал в конце предыдущего материала, обсуждавшийся в этой статье подход не совсем «идеологически правильный», по крайней мере с точки зрения используемого клиентского фреймворка. Модели, вероятно, будут использоваться для хранения библиотеки шаблонов и данных для их рендеринга, а не для объектов предметной области проекта. Представления будут отвечать лишь за рендеринг шаблонов и синхронизацию второстепенных элементов интерфейса. Если Вы все же пойдете по этому пути, хочется, чтобы Вы сделали это осознанно. Альтернативный сценарий создания полноценного JavaScript-приложения для работы в браузере для некоторых проектов по-прежнему может оказаться более предпочтительным.

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

О компании

История компании началась в 2003 году. С этого момента выпущено много проектов. Некоторыми из них Вы, возможно, так или иначе пользовались. Сейчас запускается еще один проект: SEO-биржа (родственником будет sape.ru). У Вас есть прекрасная возможность оказаться у истоков будущего хита в роли лидера команды разработчиков!

Обязанности

• Руководство группой разработчиков.
• Ставить задачи команде и проверять их выполнение.
• Бить по рукам за некачественный код, показывать как правильно писать.
• Хвалить, раздавать пряники.
• Иногда писать самому.

Требования

• Опыт руководства командой разработчиков.
• Понимание аспектов мотивации и демотивации программистов.
• Опыт программирования от 3-х лет.
• Отличное знание PHP5 && MVC && SQL.
• Базовые знания JavaScript && HTML.
• Базовые знания unix shell.
• Опыт работы с svn || git || mercurial.
• Опыт работы с redmine || mantis || jira.

Плюсом будет

• Навыки работы с NoSQL: MongoDB || Redis || Memcached.
• Опыт разработки в области HA и HL.
• Опыт применения lean- и agile- методологий в разработке.
• Знания таких слов как: ДеМарко, КанБан, Таичи Оно, SCRUM.
• Понимание цикла Деминга и SDLС в принципе.

Условия

• Удаленная работа.
• Гибкий график работы.
• Работа в слаженной профессиональной команде.
• Зарплата от $2500 до $3000 в месяц.

Вакансия закрыта

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

Сегодня мы рассмотрим основные варианты реализации этого принципа и как он сочетается с обсуждавшимися в предыдущих статьях серии темами.

Транспорт

Так как одной из сторон постоянного соединения является браузер, вопрос кроссбраузерности при его реализации стоит не менее остро, чем, например, при верстке. В 2001 году, когда появился на свет самый часто вспоминаемый недобрым словом браузер в мире, о подобных технологиях постоянного соединения между браузером и сервером практически никто не задумывался даже отдаленно.

Существуют несколько протоколов и связанных с ними технологий, которые позволяют реализовать постоянное с точки зрения приложения соединение между браузером и сервером, обычно их называют транспортами. Каждый из них обладает разной производительностью, особенностями реализации и нагрузкой на серверную часть. Возможно не полный их список c краткими пояснениями:

• WebSocket: пожалуй, самый эффективный с точки зрения производительности и нагрузки на сервер транспорт. Протокол относительно новый, появился в рамках работы над HTML5. Доступен только в очень свежих браузерах, имеет несколько более-менее стандартных версий. Используется одно соединение для обоих направлений обмена сообщениями.
• EventSource: появился примерно в то же время, что и WebSocket, но по задумке должен использоваться для получения односторонних уведомлений от сервера. В совокупности с простыми AJAX запросами для отправки событий из браузера может использоваться для двустороннего общения. Но так как он доступен примерно в тех же версиях браузеров, что и WebSocket, со сценариями, когда он оказывался бы более предпочтительным, я не сталкивался. Технически очень похож на следующий транспорт.
• AJAX Multipart aka HTTP Streaming: после получения HTTP-запроса от клиента сервер не «отпускает» его и по мере поступления отправляет в него свои сообщения. Для отправки сообщений из браузера при необходимости создается второе соединение.
• AJAX/HTTP Polling: в отличии от предыдущего транспорта, браузер закрывает HTTP-соединение после каждого отправленного в него сообщения или по прошествии определенного таймаута (обычно порядка 20-40 секунд). А браузер сразу же после получения сообщения открывает новое соединение, таким образом у сервера по-прежнему практически всегда есть соединение, куда можно отправить сообщения. Хоть по нагрузке на сервер этот вариант самый тяжелый, поддерживают его практически все браузеры.
• Adobe Flash: эта платформа может эмулировать поддержку WebSocket при определенном стечении обстоятельств (удачная комбинация Flash-плеера и браузера). Немного нетривиальна в настройке из-за своих особенностей.

По поводу поддержки каждого из них различными браузерами было бы неплохо составить табличку, но на самом деле нюансов там много и многое зависит не только от версии браузера, но и от других обстоятельств, вроде наличия и типа прокси, использования трюков с iframe, наличия Flash-плеера и т.п.

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

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

Абстракция

По сути такие библиотеки состоят из двух частей: клиентской на JavaScript и серверной для одной или нескольких платформ. Клиент определяет какой из доступных в текущем браузере транспортов является наиболее эффективным и с его помощью устанавливает соединение с сервером, который поддерживает несколько протоколов. С точки зрения разработчика интерфейс, ими предоставляемый, не зависит от транспорта и примерно одинаков:

• Метод для отправки сообщения противоположной стороне.
• Регистрация обработчика события, который будет вызван при получении сообщения от противоположной стороны, с содержанием сообщения в аргументе.
• Метод, который будет вызван при установке и разрывании соединения.
• Инициатором соединения по очевидным причинам всегда является клиент, так что у него есть дополнительный механизм для этого, с возможностью указать какие-то настройки.

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

• Node.js на JavaScript
• На Erlang есть несколько очень эффективных HTTP-серверов:
• cowboy
• misultin
• mochiweb
• yaws
• Tornado на Python
• netty на Java

Так как самих библиотек этой категории существует примерно пару десятков, расскажу вкратце о наиболее заслуживающих внимания на мой взгляд:

• socket.io: поддерживает практически все возможные транспорты, включая Flash. Основная серверная платформа — node.js, силами сторонних разработчиков есть реализации протокола на других платформах. Имеет спорную репутацию, проект довольно громоздкий, в некоторых ситуациях ведет себя непредсказуемо.
• SockJS: очень молодой проект, поддерживает необходимый минимум транспортов, прост в эксплуатации. Относительно стабилен и предсказуем. Серверная часть доступна на node.js, Tornado и cowboy/misultin, активно работают над другими платформами.

Существуют коммерческие решения, абсолютно идентичные по принципу работы и функционалу. Аналогичная обсуждавшимся opensource решениям библиотека дополняется брокером сообщений для организации паттерна «публикация-подписка» и в совокупности с хостингом «в облаках» продается с оплатой за количество переданных сообщений (или по подписке с каким-то лимитом), естественно с нехилой наценкой. Плюсы и минусы очевидны: отсутствие необходимости обо всем этом заботиться против относительно высокой стоимости, потере контроля при сбоях или необходимости изменений, привязке к стороннему поставщику услуг и т.п. Рекламировать их не буду, при желании легко гуглятся, ровно как и оставшиеся альтернативные opensource проекты.

Вернемся к интерактивным сайтам

Надеюсь, только что закончившегося лирического отступления на ¾ статьи Вам будет достаточно, чтобы составить общее представление о построении постоянного соединения между браузером и сервером, а желательно и определиться с каким-то решением для автоматического выбора наиболее эффективного транспорта в контексте именно Вашего проекта.

Получив примитивный интерфейс в виде «отправить сообщение / отреагировать на сообщение» необходимо определиться с тем, что же мы будем передавать в этих сообщениях и как будем на них реагировать.

С форматом сериализации сообщений все довольно просто: выбор между XML и JSON очевиден в пользу последнего, а заморачиваться с чем-то более экзотическим смысла мало (хотя давно хочу попробовать в этой роли Protocol Buffers или BSON, но никак руки не доходят).

Намного интереснее вопрос о том, что, собственно, будет в этих сообщениях содержаться. В предыдущей статье мы остановились на использовании фреймворка для организации кода JavaScript-клиента. Предлагаемая ими концепция модели обычно по-умолчанию предоставляет возможность синхронизации с сервером посредством AJAX запросов и механизм изменения этого поведения. Для использовавшегося в качестве примера Backbone.js для этого необходимо переопределить функцию Backbone.sync. При сохранении модели клиент будет отправлять объект с идентификатором модели и списком её изменений. Запрос изменений с сервера будет происходить асинхронно, то есть после отправки сообщения о том, что нужны данные для такой-то модели, посредством метода fetch он сам не получит ответа. Собственно изменения в модели произведет обработчик получения сообщений, в котором должна быть реализована соответствующая логика. Далее подписанные на события изменений в моделях объекты-представления будут соответствующим образом обновлять DOM-дерево страницы, отображая пользователю нужную информацию. Это, пожалуй, наиболее правильный способ интегрировать постоянное соединение и клиентский фреймфорк.

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

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

Клиентская часть сайта играет ключевую роль в обеспечении его интерактивности. Именно на нее возлагается переопределение стандартного поведения для создания впечатления живого организма вместо кучки бездушных страниц. В статье про архитектуру интерактивных сайтов я подробно изложил основные функции и требования, которые перед ним стоят. Сегодня же я представлю свое видение того, как его грамотно реализовать. На статус единственно-правильного-решения не претендую, статью можно воспринимать просто как набор практических советов и рекомендаций.

Итак, сегодня мы будем обсуждать создание JavaScript-клиента для интерактивного сайта. Начнем, пожалуй, с организации кода проекта с целью облегчения его сопровождения при росте кодовой базы, перейдем к переопределению ключевых обработчиков событий, затем к сохранению стандартного поведения браузера и закончим синхронизацией состояния между клиентом и сервером.

Организация кода

Сборка

Первое, чем стоит обзавестись перед разработкой сложного JavaScript-приложения, это системой его сборки. С точки зрения клиентской оптимизации весь JavaScript-код по возможности должен быть минифицирован и собран в один файл, подключенный в конце HTML, желательно асинхронно. Работать с ним в таком виде невозможно, соответственно надо иметь возможность легко собирать его из набора красиво отформатированных файлов, используемых при разработке.

На вопрос «Какую систему сборки использовать?» в большинстве случаев правильный ответ: ту же, что и для сборки серверной части. Make, rake, maven, ant, rebar… — любому из них без труда можно поручить эту задачу. Для конкатенации можно использовать хоть консольную команду >>, для минимизации есть много альтернативных библиотек, в порядке моих симпатий:

• Google Closure
• YUI Compressor
• UglifyJS

Если хочется чего-то более гибкого, могу порекомендовать воспользоваться Webassets, который я уже упоминал в статье про Jinja2. В консольном режиме прекрасно подключается к любой системе сборки и языку программирования. Описать процесс сборки JavaScript и CSS можно очень подробно и именно так, как считаете нужным, естественно на Python. Сопоставимый по возможностям проект из мира Ruby — Asset Packager, наверняка есть много других.

Читабельный код

Не знаю как Вы, а я тихо ненавижу JavaScript все ~10 лет, которые я с ним знаком. Так как он по сути является монополией на рынке браузерных приложений (Flash, Java апплеты и ActiveX за альтернативы можно даже не считать), использовать его так или иначе приходится в любом сколько-либо серьезном интернет-проекте. Даже Google Dart вряд ли всерьез приживется.

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

Если Вас тоже не раз посещали подобные мысли, то Вы вероятно как и я при первой же возможности пересядете (или уже пересели) на CoffeeScript, компилируемый в JavaScript язык программирования. Немного рекламы этого проекта:

• Золотое правило CoffeeScript: «It's just Javascript» (это просто JavaScript)
• Прямое преобразование кода в JavaScript
• Доступны абсолютно все JavaScript-библиотеки
• Никаких точек с запятой в конце каждой строки
• Структурирование кода на основе отступов, как в Python
• Объявление функций просто стрелочкой ->
• При вызове методов даже скобки писать не обязательно
• Человеческое наследование: простое class MyClass extends MyParent превращается в довольно хитрую конструкцию с использованием прототипов и замыканий:

MyClass = (function() {
__extends(MyClass, MyParent);
function MyClass() {
MyClass.__super__.constructor.apply(this, arguments);}
MyClass.prototype.initialize = function() {};
return MyClass;
})();

• Много укороченных команд ветвления кода (if, switch, циклы и т.п.)
• В целом код выходит раза в полтора-два короче и намного приятнее для глаз
• Консольный компилятор с функцией наблюдения за директориями
• Легко подключается как фильтр в Webassets
• Подробнее с примерами на официальном сайте
• В общем рекомендую

Логическое разделение кода

Если Вы сталкивались со сколько-либо сложным пользовательским интерфейсом «на jQuery», то скорее всего не по наслышке понимаете откуда взялось выражение «спагетти-код». В связи с событийной парадигмой разработки браузерных приложений, очень часто JavaScript-код с использованием jQuery или альтернатив превращается в так называемый «коллбек на коллбеке, коллбеком погоняет» (коллбек — транслит от английского callback — обработчик события). При отсутствии четкой структуры такой код становится очень сложно поддерживать при его увеличении в объемах. Но это не повод отказываться от jQuery — от событий никуда не деться, и эта библиотека отлично справляется с абстракций от особенностей их реализации в различных браузерах.

На мой взгляд, одним из наиболее резонных способов решения (или заблаговременного предотвращения) этой проблемы является использование в разумных пределах объектно-ориентированные возможности JavaScript (благо CoffeeScript это дело сильно упрощает). Соответственно, используемые классы можно разумно располагать в какой-то иерархии с точки зрения наследования (для обеспечения DRY, don't repeat yourself — «не повторяйся») и с точки зрения расположения в файловой системе (с разложенными по папкам файлами работать намного проще, чем с здоровенной вереницей обработчиков событий в одном файле).

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

• Модель (Model) — как и в традиционном MVC представляет собой класс, объект которого содержит локальную копию каких-то данных и предоставляет механизмы для её синхронизации с внешним хранилищем. Основное отличие от серверных моделей — хранилищем выступает не СУБД, а либо локальное хранилище браузера через HTML5, либо удаленный сервис через REST или другой интерфейс. Плюс так как они находятся вне «зоны доверия», то полученные от них данные нужно обязательно валидировать, фильтровать и проверять на серверной стороне, прежде чем что-либо с ними делать.
• Представление (View) или контроллер (Controller) — тут, по моим впечатлениям, образовалась путаница и за обоими названиями в нашем контексте имеют ввиду примерно одно и то же. Объект такого класса следит за изменениями и событиями в связанных с ним моделях и элементах DOM, каким-либо образом на них реагируя. Таким образом большая часть кода, которая раньше была «вереницей обработчиков событий», оказывается методами этого класса. При этом базовый класс из библиотеки берет на себя нормальное поведение this и следит за тем, чтобы обработчики автоматически добавлялись на динамические созданные элементы DOM.
• Маршрутизатор (Router) - следит за состоянием адресной строки и позволяет обрабатывать изменения, понадобится для восстановления поведения браузера.
• Коллекция (Collection) — отсортированный набор однотипных моделей, с которым можно работать как с единым целым.

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

• Backbone.js - самая широко распространенная из трех, используется во многих серьезных проектах. Основана на библиотеке Underscore.js, которая с одной стороны предоставляет массу удобных функций и шаблонизатор, но с другой стороны — не особо-то и часто они оказываются нужны.
• Spine.js - библиотека по-моложе, которая очень похожа на Backbone.js, но написана на CoffeeScript и из-за отсутствия внешних зависимостей вышла компактнее. Отличия в основном в терминологии и деталях реализации.
• Knockout.js — эта библиотека пропагандирует использование data-* атрибутов из HTML5 для хранения метаданных, которые как-то управляют изменениями тегов-владельцев при определенных событиях, практически забирая на себя роль представления. Концепция кажется мне мутноватой, так что лично для себя я её использование всерьез и не рассматривал никогда.

Когда в этой статье дело будет доходить до примеров кода, я буду приводить их на основе Backbone.js, так как в свое время я остановился именно на ней. Почему? В основном из-за того, что она используется в очень многих проектах и стоит за ней целая компания, а не просто один разработчик, которому однажды может надоесть поддерживать проект (как в случае с Spine.js). Но в глубине души я, конечно, надеюсь, что однажды они уберут эту жесткую зависимость от Underscore.js, а то и может быть тоже перепишут все на CoffeeScript.

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

Обработчики событий

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

Напомню, то, что раньше было просто независимым обработчиком событий становится методом представления (по терминологии Backbone.js). У каждого представления создается «оглавление» методов-обработчиков в атрибуте events. Наверное многим хотелось бы увидеть какой-то пример кода, но так как статьями с примерами примитивных приложений на Backbone.js пестрит весь Интернет, тратить на это время желания совершенно никакого, сошлюсь на самый популярный: список задач TODO, для сравнения то же самое на Spine.js. К слову, при использовании CoffeeScript использовать стандартный механизм Backbone.****.extend ({ … }) не обязательно, class MyClass extends Backbone.**** прекрасно делает то же самое.

По мне, так намного интереснее не какие именно события обрабатываются (все равно 90% уникальны для проекта), а как их распределить по разным представлениям. Обычно получается что-то в этом духе:

• Пользовательское представление будет модифицировать страницу в тех местах, где оно как-то связано с текущим пользователем: форма авторизации, надпись «Привет, ****!», кнопка выхода и пр. Вероятно, оно будет использовать модель текущего пользователя или в тривиальных случаях просто самостоятельно работать с cookie сессии.
• Классы модели и представления, а вероятно и коллекции, понадобятся каждой логической сущности, которая каким-либо образом отражается в пользовательском интерфейсе. Это может быть что угодно, например задача в TODO-списке, статья, комментарий — все зависит от тематики проекта.
• Если навигация по сайту каким-то образом динамически видоизменяется, то представление понадобится и для нее. Например, часто подсвечивают пункты в глобальной навигации на основе изменений в текущем адресе страницы.
• И, последний пункт, который собственно и относится к сегодняшней теме — одно представление будет общим для всего сайта и будет отвечать за его интерактивность. Давайте его рассмотрим подробнее.

Для отсутствия перезагрузок браузера внутри сайта, нам нужно переопределить:

• События клика на ссылки: по содержимому атрибута href нужно определить, что ссылка внутренняя и вызвать «цепную реакцию» в других представлениях, чтобы в итоге пользователь увидел то, что должен.
• При отправке формы есть два сценария:
• Обновляется связанная модель и синхронизируется с сервером. В таком сценарии при необходимости можно вообще скрыть кнопку отправки и «автосохранять» изменения в модели.
• Связанной модели по каким-то причинам нет и нужно просто на основе данных формы что-то сделать, например выполнить поиск по указанной в форме фразе или отправить запрос на авторизацию.

Для отмены стандартной реакции браузера на события у jQuery есть два основных механизма: event.preventDefault () и return false. В данной ситуации (да и большинстве других), целесообразнее пользоваться последним, так как если вдруг в коде обработчика окажется какая-то ошибка, то пользователь просто увидит стандартную реакцию браузера, а не окажется в ситуации «некликающихся ссылок» и «неотправляющихся форм».

Восстановление поведения браузера

В предыдущем разделе я даже не стал подробно останавливаться на том, как сделать так «чтобы пользователь увидел то, что должен». Наверняка можно придумать массу способов решения этой задачи, но единственный реально применимый на практике — воспроизвести визуально то же самое, что происходит при обычной перезагрузке страницы.

И первое, с чего стоит начать — с адресной строки, именно там должен появиться тот адрес, который был в href ссылки и action формы. Но на самом деле проще сказать, чем сделать:

• Возможность просто полностью поменять текущий адрес в адресной строке из JavaScript без инициализации открытия страницы есть только в совсем свежих браузерах посредством HTML5 History API (pushState).
• В старых браузерах переходы между внутренними страницами сайта можно эмулировать через изменения якоря ссылки, который в URL идет после # и обычно используется для «перелистывания» на середину HTML-документа. Для отслеживания таких изменений используется событие onhashchange.
• В еще более старых браузерах это событие эмулируют разными трюками с iframe и setInterval.

Backbone.history.start () берет на себя абстракцию изменений в адресной строке, правда поддержку pushState нужно явно включить в аргументах. Заодно восстанавливается нормальное поведение кнопок «Назад» и «Вперед» в браузере.

Для обработки и создания событий, отражающихся в адресной строке, нужно сделать подкласс Backbone.Router. C ситуациями когда их имеет смысл создать несколько, я не сталкивался. По аналогии с серверными фреймворками в атрибуте routes задается соответствие паттернов адресов к методам-обработчикам, которые будут выполниться при переходе. В них вызываются необходимые изменения в коллекциях, моделях и представлениях, чтобы привести в нужное состояние текущий документ.

Для инициации «виртуального» перехода на новую внутреннюю страницу нужно вызвать метод navigate у нашего объекта-маршрутизатора, первым аргументом передав её адрес без первого /, а вторым — настройки:

• trigger — вызывать ли обработчик из маршрутизатора?
• replace — добавлять ли страницу, с которой мы уходим в историю браузера, чтобы можно было на нее вернуться при нажатии кнопки «назад»?

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

• Клик по ссылке с зажатым Shift должен открывать её в новом окне, а с зажатым Ctrl или при клике средней кнопкой мыши — в новой вкладке. Довольно не хитро делается на основе атрибутов объекта-события, который передает обработчику jQuery (button, shiftkey, metakey), для открытия окна или вкладки — window.open.
• Если пользователь сделал какое-то действие, а прореагировать на него мгновенно не получается (так как что-то грузится, вероятно) — нужно включить курсор ожидания, установив в CSS cursor: wait, и, желательно, анимированный favicon.ico. И, соответственно, вернуть все как было, когда страница примет нужный вид. Для смены favicon до сих пор пользуюсь каким-то довольно старым плагином к jQuery, который не особо шикарно, но все же работает. Его сайт, видимо, накрылся, так что продублировал: https://gist.github.com/2320740, если кто знает более адекватные альтернативы — дайте знать в комментариях, пожалуйста, руки поискать все никак не доходят.

Синхронизация состояния

По-умолчанию Backbone.js предлагает хранить все состояние клиента в моделях и синхронизировать его с серверным посредством реализации простенького REST API на сервере (подробнее), к которому запросы отправляются посредством обычного $.ajax. Чтобы инициировать процесс нужно вручную вызвать у экземпляра модели метод fetch, чтобы обновить клиентское состояние данными с сервера, или метод save, для обратного процесса.

Для многих приложений этого, в целом, достаточно. Но ограничение очевидно — нет возможности мгновенно узнать, что на сервере что-то изменилось. Чего-то близкого можно достичь вызовом fetch раз в N секунд для каждой модели, но если пользователей предполагается хоть сколько-либо много, нагрузка на серверную часть будет неоправданно велика.

Резонным дополнением этой схемы является использование постоянного соединения между клиентом и сервером для синхронизации их состояний. Именно это мы и обсудим в следующей статье серии.

В анонсе серии статей «Интерактивные сайты» я постарался максимально доходчиво изложить свою мотивацию к ей созданию, да и актуальность самой темы, так что сразу к делу!

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

Сразу хочу предупредить, что далеко не всем сайтам такая глобальная интерактивность пойдет на пользу. Если пользователи сайта редко что-либо делают и большую часть времени читают длинные тексты, то, вероятно, этот проект как раз из этой категории: быстрота реакции на клик не так радует, когда большую часть времени приходится работать скроллом. Если Ваш интернет-проект является сайтом с длинным контентом в формате блога, новостей или вики — подумайте лишний раз, прежде чем переделывать весь сайт, вероятно будет достаточно интерактивных комментариев и голосований на AJAX. Для социальных сетей, сайтов знакомств, интернет-магазинов, поисковых систем, корпоративных сайтов и многих других визуально заметная интерактивность определенно станет одним из ключевых конкурентных преимуществ.

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

Общие замечания

• Здесь и далее я буду описывать «среднестатистический» интернет-проект, в зависимости от специфики могут появляться дополнительные компоненты или убираться за ненадобностью упомянутые. Например, если известно, что пользоваться сайтом будут только сотрудники какой-то компании, то помимо замены Интернета на Интранет, можно запросто избавиться и от HTML-интерфейса и всего, что с ним связано — никаким роботам доступ к нему не нужен.
• Наверное стоит прямым текстом сказать, что:
• Голубые элементы — компоненты проекта, а серые — внешние.
• Связи в виде прямых линий означают двусторонний обмен данными, транспорт и формат пока особо не важны.
• Схема логическая, так что вопросы балансировки нагрузки, отказоустойчивости, репликации и т.п. остались в стороне; за каждым блоком может стоять произвольное количество серверов.
• Я решил не загромождать схему мониторингом, резервным копированием, почтой, сервисом доменов и прочими хоть и важными, но не связанными напрямую с темой компонентами системы.
• В этом посте не будет никаких конкретных примеров реализации и технологий, оставим это на следующие статьи.

Клиентская часть

• Начнем наше путешествие. Пользователь вводит в адресной строке браузера адрес нашего сайта и жмет Enter, инициируя тем самым сначала определение IP-адреса через DNS, а затем и HTTP-запрос к нашему HTML-интерфейсу.
• Получив в ответ страницу в формате HTML браузер начинает загружать указанные в нем внешние ресурсы, в том числе и Javascript-клиент, которому и передается слово. Сама страница параллельно отрисовывается как и в статичном сайте.
• Как уже упоминалось выше, некоторые проекты решают не тратить силы на поддержку двух интерфейсов к сайту, жертвуя тем самым доступом большинства роботов и браузеров без поддержки JavaScript. Стартовый HTML-документ в этом случае превращается просто в практически пустой статичный файл, который служит лишь для загрузки клиента.
• Так как наша цель стоит в интерактивном взаимодействии пользователем, повторять эти действия при каждом переходе на другую страницу — непозволительная роскошь. Кстати, можно начинать думать и общаться не в терминах страниц, а в терминах экранов, которые видит пользователь.
• Для обеспечения этого JavaScript-клиент должен переопределить стандартные обработчики событий перехода по внутренним ссылкам сайта и отправки форм. Ему нужно отменить стандартный механизм перехода на другую страницу и вместо него отправить запрос через интерфейс сериализованных данных. На основе полученного в ответ сообщения он меняет какую-то часть загруженного ранее HTML-документа, чтобы он соответствовал тому экрану, который ожидал увидеть пользователь. В итоге пользователь видит в браузере ровно ту же картинку, как если бы он ввел тот адрес, на который вела нажатая ссылка, или просто нажал на нее с отключенным JavaScript.
• Важно не сломать при этом поведение браузера: кнопка «назад» должна работать как обычно, а в адресной строке должны меняться ссылки (это актуально, например, когда пользователь отправляет содержимое адресной строки кому-то по почте или через мессенджер).
• При ожидании ответа от сервера стоит эмулировать курсор и иконку загрузки страницы, чтобы пользователь не паниковал в случае (пускай и редком) визуально заметных задержек.
• На резонный вопрос «Почему, собственно, этот трюк обеспечит интерактивность?», ответ хоть и не всегда однозначен, но он все же есть:
• Сериализованные изменения страницы занимают меньший объем, чем полный HTML со всеми связанными ресурсами, заголовками, версткой и прочим — значительно меньше данных нужно передавать по сети.
• Как правило, есть возможность держать постоянное соединение между браузером и интерфейсом сериализованных данных, что позволяет не делать лишние HTTP-запросы. Обратная сторона медали — это самое соединение постоянно же использует часть серверных ресурсов, но есть способы минимизировать эти издержки.
• Для некоторых действий изменения HTML не требуют ответа сервера и могут быть сделаны параллельно с отправкой запроса (например  различные вариации на тему +1 или написание комментария, текст которого можно взять из формы).
• Как правило, можно предсказать наиболее вероятные переходы по экранам и загрузить необходимые изменения заранее. Хотя этот вопрос скорее из области оптимизации.
• Таким образом, в большинстве случаев есть техническая возможность снизить время отклика  на действие пользователя с 500-2000 мс в случае неплохо сделанного статического сайта до 20-200 мс., что вполне сопоставимо с откликом десктопного приложения.
• Как все это сделать на практике — тема следующей статьи из серии.

Серверная часть

• С серверной точки зрения основным отличием является четкое разделение двух входных точек:
• HTML-интерфейс отдает готовые документы в ответ на HTTP-запросы.
• Интерфейс сериализованных данных использует какое-то постоянное соединение, хотя в некоторых случаях целесообразно ограничиться просто асинхронными HTTP-запросами.
• Если для статичных сайтов полное выделение бизнес-логики в отдельные сервисы — просто хорошее архитектурное решение, то для интерактивных сайтов — это практически необхохимо. Иначе придется реализовывать и поддерживать две копии кода для каждого интерфейса и надеяться, что они постоянно будут оставаться совместимыми и выдавать одинаковый результат.
• Хорошей практикой является использование какого-то одного протокола общения между компонентами системы, в частности пользовательских интерфейсов с сервисами бизнес-логики и последних друг с другом. Желательно использовать что-то бинарное и с поддержкой разных языков программирования, хотя если весь проект на одной платформе и не планирует это менять — можно использовать и стандартный для этой платформы протокол.
• Чтобы не включать элементы верстки при передаче через интерфейс сериализованных данных, рекомендую использовать кроссплатформенный формат HTML-шаблонов. Об этом будет отдельная статья.
• Интерфейс сериализованных данных при необходимости легко может быть адаптирован для использования в роли API для сторонних сервисов или собственных приложений для мобильных платформ или настольных компьютеров.
• В целом внутренние сервисы общаются с остальными располагающимися на серверной части компонентами системы вполне обычным образом.
• В статье про серверную часть подробно будет рассматриваться использование брокера сообщений для уведомлений пользователей в реальном времени.

Подводим итоги

• Глобальная интерактивность сайта требует использования достаточно сложного и комплексного JavaScript-клиента и создания дополнительного более легковесного внешнего инетрфейса на серверной части.
• По-настоящему мгновенной реакцией сайта смогут насладиться лишь пользователи с современным браузером и относительно широким интернет-каналом. Из-за возможных сетевых задержек или особенностей устаревших браузеров эффект мгновенного перехода все же может теряться, но при должном тестировании реально добиться нормального поведения сайта и в таких ситуациях. Хотя зачастую «проваливание» до обычного режима статичных страниц в подобных ситуациях — вполне резонное решение.
• Архитектура серверной части проекта в большинстве случаев не требует существенных изменений. Хотя если в ней все было хаотично и не продумано, то создание интерактивного клиента может послужить неплохим поводом пересмотреть и привести в порядок и её.
• Кроме очевидной потребности в использовании JavaScript для клиента, особых ограничений на используемые технологии и языки программирования, обсуждаемая схема не накладывает.

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

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

За последний год привнесение интерактивности в интернет-проекты — пожалуй, одна из самых популярных тем, с которой ко мне обращаются за консультацией.  В итоге я решил не жадничать и поделиться с общественностью своими знаниями в этой области, что в итоге должно вылиться в серию связанных статей «Интерактивные сайты». В ней я хочу отразить практически пошаговую инструкцию от А до Я для создания интерактивного интернет-приложения с нуля или основываясь на существующем статичном проекте. Соответственно, по ходу дела сделаю легко доступное оглавление по аналогии с архитектурой высоконагруженных интернет-проектов.

Ориентировочные темы статей

• Общая архитектура
• Организация клиентской части
• Постоянное соединение между браузером и сервером
• Повторное использование шаблонов
• Серверная часть и потоки сообщений
• Оптимизация

Основной упор будет сделан именно на общую концепцию и сведение всех компонентов воедино, как на серверной стороне, так и на клиентской. Количество изобретаемых велосипедов постараюсь свести к минимуму: где-то будут просто рекомендации по использованию публично доступных технологий, где-то — сравнительные обзоры. Специфики каких-либо определенных типов проектов постараюсь избегать.

Пожелания, предложения, советы и вопросы в комментариях к этому посту очень приветствуются

Storm является распределенной системой для выполнения вычислений в реальном времени. Она родилась в рамках проекта Backtype, который специализировался на аналитике твитов и который в июле 2011 был приобретен Twitter.  Так же как Apache Hadoop предоставляет набор базовых абстракций, инструментов и механизмов для пакетной обработки данных, Twitter Storm делает это для задачи обработки данных в режиме реального времени. Хотите узнать в чем их отличие?

Отличие

Не смотря на то, что Storm изначально появился на свет в процессе неудачных попыток приспособить Hadoop к задаче обработки данных в реальном времени, сравнивать их некорректно. Никакой хак или патч не сможет заставить Hadoop работать по-настоящему в режиме реального времени, так как в его основе лежит фундаментально другая концепция и набор принципов, которые актуальны лишь в контексте задачи пакетной обработки данных. Storm можно представить как «Hadoop для вычислений в реальном времени», но по факту между ними нет практически ничего общего, кроме изначально-распределенной природы, слегка похожей архитектуры, работы внутри JVM и публичной доступности. Для понимания задачи, которая стоит перед Storm, лучше взглянуть на то, как она обычно решается.

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

Особенности

Итак, основные особенности Storm, вытекающие из требований к подобным системам:

• Три основных варианта использования, но ими он не ограничивается:
• Обработка потоков сообщений (stream processing) в реальном времени, с возможностью внесения изменений во внешние базы данных;
• Постоянные вычисления (continuous computation) на основе источников данных с публикацией результатов произвольным клиентам в реальном времени;
• Распределенные удаленные вызовы (distributed RPC) с выполнением комплексных вычислений параллельно во время запроса.
• Масштабируемость: Storm может обрабатывать огромное количество сообщений в секунду. Для масштабирование необходимо лишь добавить сервера в кластер и увеличить параллельность в настройках топологии. В одном из первых приложений для Storm обрабатывался 1 миллион сообщений в секунду на кластере из 10 серверов, при этом выполнялось несколько сотен запросов в секунду к внешней базе данных.
• Гарантия отсутствия потерь данных: в отличии от других систем обработки сообщений в реальном времени (например S4 от Yahoo!) это свойство изначально является частью архитектуры Storm. Для этого используется механизм подтверждения (acknowledgement) успешной обработки каждого конкретного сообщения.
• Стабильность: в то время как Hadoop позволительны простои по несколько часов, так как он априори не является системой реального времени, одной из основных целей Storm является стабильная бесперебойная работа кластера, с максимально безболезненным его управлением.
• Защита от сбоев: если что-то пошло не так во время выполнения вычисления, Storm переназначит задачи и попробует снова. В его задачи входит обеспечение бесконечной работы вычислений (или до момента запланированной или ручной остановки).
• Независимость от языка программирования: в то время как большая часть системы написана на Clojure и работает в JVM, сами компоненты системы могут быть реализованы на любом языке, что удобно для проектов, использующих в основном другие технологии.

Концепция

Для начала пройдемся по основным абстракциям, которые используются в Storm:

• Поток (Stream): неограниченный поток сообщений, представленных в виде кортежей (произвольных именованный список значений). При этом все кортежи в одном потоке должны иметь одинаковую схему: элемент на каждой позиции должен иметь один и тот же тип данных и значение.
• Струя воды из крана (Spout): источник потоков, который берет их из какой-то внешней системы.
• Cтруя состояния (state spout): предоставляет распределенный доступ к некому общему состоянию, которое кэшируется в памяти на исполнителях и синхронно обновляется при внешних изменениях. Таким образом возможно избежать обращений к внешней базе данных при обработке каждого сообщения. В случае с Twitter этим общим состоянием является сам социальный граф.
• Молния (Bolt): обрабатывает входящие потоки и создает исходящие потоки, производя какую-либо обработку данных (по сути здесь реализуется основная бизнес-логика). Помимо этого никто не запрещает использовать при обработке какие угодно внешние сервисы вроде СУБД.
• Топология (Topology): произвольная связанная сеть из «молний» и «струй». При создании топологии можно указать:
• уровень параллелизма для каждого компонента, что создаст необходимое количество его потоков исполнения в кластере.
• группировку потоков, то есть как именно сообщения будут распределяться между созданными потоками исполнения каждого компонента, есть четыре основных варианта — случайно (shuffle), каждый получит по копии (all), хэш по определенным полям сообщения (fields), один  поток получает все сообщения  (global).

В остальном все достаточно просто:

• Мастер-сервер (Nimbus) отвечает за распространение кода, распределение задач и мониторинг сбоев.
• На каждом сервере в кластере запускается процесс-надсмотрщик (Supervisor), который запускает локально потоки исполнения, отвечающие за выполнение назначенных ему компонентов топологий.
• Передача сообщений между компонентами топологий осуществляется напрямую, посредством ZeroMQ.
• Топологии являются Thrift-структурами, а мастер-сервер — Thrift-сервисом, что позволяет осуществлять регистрацию топологий и другие операции программно из любого языка программирования.

Планы на будущее

• Использование Mesos для распределения и изоляции вычислительных ресурсов.
• Изменение кода «на лету», сейчас для этого нужно остановить старую топологию и запустить новую, что может означать простой в пару минут.
• Автоматическое определения необходимого уровня параллельности и адаптация под изменения в интенсивности входящего потока сообщений.
• Еще более высокоуровневые абстракции.

Подводим итоги

• На самом деле подход, лежащий в основе Storm, не является чем-то кардинально-новым. Помимо упоминавшегося выше S4 можно найти еще несколько альтернатив, пускай и менее близких по идеологии. Подробнее про эту тему можно узнать погуглив complex event processing или real-time stream processing.
• Storm выделяет из их числа простота, гибкость, масштабируемость и отказоустойчивость в одном флаконе. Обеспечивает это в первую очередь простая и понятная архитектура, основанная на (уже) проверенном временем и многими проектами распределенном координаторе в виде Zookeeper.
• Хоть за проектом и стоит крупный интернет-проект в лице Twitter, он достаточно молод и нужно быть морально готовым к возможным сбоям и неудачным моментам. Плюс не забывайте, что существенная часть написана на Clojure — для, пожалуй, большинства разработчиков изучение исходников проекта будет капитальным «выносом мозга». Мое первое знакомство с Lisp (Clojure — его диалект, работающий в JVM) надолго засело в памяти из-за обилия скобочек за каждым углом
• В любом случае из доступных opensource реализаций систем для распределенных вычислений в реальном времени Storm на мой взгляд является наиболее перспективным для применения в интернет-проектах.
• Если Вашему проекту нужна лишь одна-две топологии и особо большого кластера не планируется, то подобную схему достаточно не сложно реализовать и просто посредством Zookeeper + ZeroMQ или альтернативных технологий. Это избавит проект от возможных заморочек с Clojure и другими «особенностями» Storm, ценой вероятно существенно большей собственной кодовой базы, которую придется самостоятельно тестировать и поддерживать. Какой путь ближе — команда каждого проекта решает для себя сама.
• Помимо различных вариаций веб-аналитики заманчивыми применениями подобной системы в Интернете может стать:
• построение индекса для поисковых систем, на сколько я знаю от MapReduce здесь отказался только Google;
• поведенческий таргетинг для рекламы — собираем действия пользователей и делаем на их основе выводы в реальном времени;
• ведение рейтингов чего-либо в реальном времени — в зависимости от специфики проекта можно определять и показывать лучшие, самые просматриваемые или самые комментируемые статьи/фото/видео/музыку/товары/комментарии/что-нибудь-еще;
• предлагаем свои варианты в комментариях.
• Удачи в построении приложений для вычислений в реальном времени и до встречи на страницах Insight IT!

Источники информации

• Видео презентации проекта
• Слайды с презентации проекта
• Репозиторий проекта

Выбирайте самое простое решение с наиболее общими гарантиями, которые практически полезны.
— Дао YouTube

YouTube практически на протяжении всех 7 лет своего существования является мировым лидером в сфере интернет-видео. С точки зрения технической реализации проект оказался достаточно консервативным — команда придерживается того же курса и стека технологий, с которых все начиналось еще до приобретения проекта Google. Но с 2008 года, когда я написал первый обзор архитектуры YouTube, все же произошли интересные изменения, о которых я и хотел бы сегодня вкратце рассказать.

Статистика

• 4 млрд. просмотров страниц в день
• 60 часов видео загружается каждую минуту
• 350 миллионов устройств подключено к YouTube
• На февраль 2012 года в США по данным comScore:
• 147,4 млн. уникальных зрителей
• 16,7 млрд. просмотров видео (в октябре 2011 было больше 20 млрд.)
• Каждый зритель посмотрел в среднем 7 часов видео за месяц
• 1.1 млрд. просмотров видео рекламы, суммарной длительностью в 10.8 млн. часов

Технологии

• Linux — операционная система
• Apache — основной HTTP-сервер
• lighttpd — отдача видео из YouTube CDN
• Zookeeper — распределенные блокировки, хранение конфигураций
• Python:
• wiseguy — FastCGI-прослойка между Apache и Python
• pycurl — лучшая доступная реализация HTTP-клиента, но в итоге все равно заменили на самописное низкоуровневое решение, выиграв 8% в потреблении вычислительных ресурсов.
• spitfire — высокопроизводительный шаблонизатор на основе абстрактного синтаксического дерева с регулируемым уровнем оптимизации (как в gcc)
• bson в качестве формата сериализации
• BigTable — хранение изображений
• MySQL — используется просто как хранилище данных, версия 5.1.52 с InnoDB
• Vitess — система для масштабирования MySQL-кластера

Vitess

• Основная цель проекта — предоставление всех необходимых инструментов и серверов для горизонтального масштабирования баз данных на основе MySQL, с учетом потребностей современных интернет-проектов.
• Реализован на Go — все еще экзотическом языке программирования, также родившемся в стенах Google. Сравним по производительности с C++ и Java, но несколько более «выразителен».
• Опубликован в opensource 24 февраля 2012 года, совсем недавно, так что YouTube — по-прежнему единственный пример его использования на практике в крупном проекте.
• Готовые клиентские библиотеки пока только для Python и Go, что не удивительно, но есть и универсальные интерфейсы на основе HTTP и просто TCP-сокетов.
• Основной формат данных — bson, как и в MongoDB, но по словам разработчиков Vitess их реализация выполняет (де)сериализацию в 10-15 раз быстрее.
• Ядром проекта выступает Vtocc,  SQL-прокси с RPC интерфейсом, позволяющий перераспределять запросы от большого количества (более 10 тыс.) одновременно подключенных клиентов в сравнительно небольшое количество соединений с базами данных. Пропускная способность порядка 10 тыс. запросов в секунду.
• Встроенные возможности Vtocc:
• парсер и анализатор SQL-запросов для оптимизации их выполнения;
• заполнение типичных запросов переменными с поддержкой кэширования результатов;
• управление транзакциями и сроками их выполнения («убивает» затянувшиеся);
• для каждого пространства ключей (логической таблицы) можно указать фактор репликации, что создаст необходимое количество второстепенных баз данных в дополнение к мастеру;
• можно явно указать, что чтение необходимо произвести с мастера (важно когда пользователь только что выполнил какое-то действие и должен сразу же увидеть его результат);
• отдельные пулы соединений для выполнения операций чтения и записи;
• исключение «зависших» соединений из пулов;
• перезапуск без простоя системы;
• поддержка DML.
• Партиционирование:
• Во всех таблицах должна быть колонка с уникальным ключем, на основе которого данные будут распределяться по кластеру.
• Партиционирование основано на диапазонах ключей, что позволяет держать «карту» партиций в памяти и очень быстро определять где располагаются те или иные данные, но обратной стороной медали является вероятное возникновение «горячих» узлов в кластере, особенно при монотонно увеличивающихся значениях ключей (рекомендуется использовать случайные).
• Поддерживаются ключи в виде натуральных чисел или произвольных бинарных данных.
• При высокой нагрузке на одну партицию она может быть распределена на две путем фильтрованной репликации; в дальнейшем планируется реализовать и обратный процесс.
• Еще в планах:
• Поэтапное внесение изменений в схему данных без видимого простоя системы;
• Поддержка работы в нескольких датацентрах с концентрацией мастер-серверов в одном датацентре и использования остальных в режиме только для чтения.

Подводим итоги

• YouTube — еще один проект мирового масштаба, который с самого начала использовал MySQL и оказался не в силах от него отказаться, не смотря на трудности с горизонтальным масштабированием.
• По аналогичному пути пошли и другие проекты, схожие с Vitess надстройки над MySQL используются в Facebook и Twitter:
• В Facebook она дополнена сильной интеграцией с memcached и сильно ограниченным интерфейсом, не имеющим практически ничего общего с SQL. Планы о публикации в opensource, кажется, были, но я не слышал чтобы они воплотились в жизнь. // Уже почти дописав статью случайно заметил в коде, а потом и мелким шрифтом в документации, что в Vitess тоже используется memcached для кэширования из-за проблем со сборщиком мусора Go.
• Twitter по-прежнему использует свою связку FlockDB + Gizzard на Scala, которые уже пару лет публично доступны. В отличии от Vitess она заточена на хранение информации о социальных графах, по-этому сфера её применения как в Twitter, так и за его пределами ограничена.
• Vitess — пожалуй первая относительно успешная попытка построить распределенную горизонтально масштабируемую СУБД на основе реляционной базы данных, сохранив при этом SQL-интерфейс, пускай и с некоторыми ограничениями.
• Выбирайте подходящее хранилище для каждого типа данных в системе — если Vitess стал подходящим решением для структурированных данных вроде информации о пользователях, метаданных видео и комментариев, это не значит, что он хорошо (или плохо) справится, например, с медиа-файлами вроде изображений и видео (для них в YouTube по-прежнему используют стек технологий Google, подробности не публикуются).
• Python — вполне пригодный инструмент для реализации бизнес-логики интернет-проектов, свет клином на PHP не сошелся. Python предлагает широкий ассортимент инструментов для решения любых типичных для интернет-проектов задач, хотя субъективно выбор некоторых из них разработчиками YouTube мне кажется странным.

Источники информации

• Mike Solomon на PyCon '12 (один из первых разработчиков проекта)
• О проекте Vitess
• Статистика comScore на февраль '12

С моей точки зрения, Erlang — один из наиболее продуманных языков программирования. Его создатели выбирали каждую деталь и особенность реализации так, чтобы сделать его идеальным для решения вполне конкретных телекоммуникационных задач, с которыми они сталкивались в 80-90-х годах. Во многом из-за этого он так и не стал универсальным языком программирования как C++, Python и другие, а так и остался спустя многие годы специализированным инструментом. Сегодня спрос и предложение на специалистов по Erlang на рынке труда относительно малы, что для большинства проектов является основным аргументом против Erlang, хотя порой они и сталкиваются с задачами, где он запросто бы стал тем самым «идеальным инструментом». В этой статье я хотел бы обсудить, в каких именно ситуациях применительно к интернет-проектам использование Erlang оправдано и почему. Но начать придется издалека — с того, чем же он так уникален.

Что такое Erlang?

Под словом Erlang обычно подразумевают совокупность сразу нескольких компонентов:

• Сам одноименный язык программирования — по сути синтаксис и идеологию;
• ERTS (Erlang Run-Time System) — реализация всех низкоуровневых абстракций на C. Подробнее о них ниже.
• BEAM (Bogdans' Erlang Abstract Machine) — стандартная реализация виртуальной машины, с помощью которой обычно исполняются программы на Erlang после компиляции в байт-код (она очень эффективна; хотя компиляция Erlang в нативный код и возможна, оно того чаще всего не стоит). BEAM используется по-умолчанию в основных дистрибутивах Linux и других операционных системах. Когда говорят «виртуальная машина Erlang» обычно подразумевается совокупность ERTS и BEAM.
• OTP (Open Telecom Platform) — набор качественно реализованных высокоуровневых абстракций, использование которых стало почти стандартом де-факто в мире Erlang, так как оно позволяет не изобретать велосипеды и избегать типичных ошибок при реализации типичных же паттернов. Немного забегая вперед, приведу несколько примеров: gen_server (просто процесс, который принимает какие-то запросы и как-то на них реагирует), gen_fsm (конечный автомат), supervisor (мониторинг других процессов).

Ключевые особенности

• Параллельное программирование (concurrent programming) — программы на Erlang состоят из независимых задач, которые могут выполняться параллельно, что на практике дает свободу виртуальной машине планировать их выполнение наиболее эффективным образом с учетом доступных системных ресурсов.
• Процессная модель (process model) — единицей параллельного выполнения в Erlang является процесс, который технически представляет собой лишь часть потока исполнения (thread) операционной системы и обладает нижеизложенными свойствами, которые обеспечивает их реализация в ERTS:
• Параллельность (concurrency) — каждый процесс выполняет свою часть кода вне зависимости от других процессов, со своим темпом.
• Изоляция процессов (process isolation) - в отличии от потоков исполнения в операционных системах и других языках программирования, между процессами Erlang'а нет общей памяти. Помимо этого сбой в одном из процессов напрямую не влияет на другие процессы в системе. Именно по-этому они называются процессами, так как в этом ключе скорее похожи на полноценные процессы операционной системы.
• Низкое потребление ресурсов (low resource consumption) — так как процессы Erlang являются лишь абстракцией внутри потока исполнения операционной системы, используют зачастую меньше килобайта оперативной памяти и требует минимальных вычислительных ресурсов, то один сервер может при необходимости иметь сотни тысяч и даже миллионы запущенных процессов (теоретически возможный максимум — 268435456, хотя по-умолчанию стоит ограничение в 32768 процессов). Для сравнения: суммарное количество потоков выполнения на сервере обычно измеряется сотнями и редко превышает тысячу.
• Слабая связанность (loose coupling) — процессы общаются друг с другом посредством асинхронного обмена сообщениями (message passing), для чего часть памяти каждого процесса выделяется под «почтовый ящик». При отправке сообщения в списке входящих сообщений процесса-получателя создается копия сообщения, составленного в процессе-отправителе. При этом протокол отправки сообщений между процессами скрыт от разработчика и не зависит от того, находится ли получатель в той же виртуальной машине или в удаленной (на другом сервере), что позволяет легко и практически прозрачно распределять приложения по многим физическим серверам (горизонтальное масштабирование, scale out).
• Дерево ответственности (responsibility tree) — создаваемые внутри системы процессы образуют иерархию, где родители несут ответственность за потомков. В упомянутом чуть выше примере сбой одного из процессов вызывает его завершение и рассылку уведомлений связанным процессам-соседям по иерархии (с информацией о том, где и почему произошел сбой), на которые они могут как-то реагировать. Типичных сценария реагирования два: также завершить работу и разослать аналогичные уведомления, вызывая цепную реакцию (такие процессы называют исполнителями, worker), либо на основе уведомления принять какое-то действие, например попытаться заново запустить часть дерева процессов, аналогичную остановленной (такие называют надсмотрщиками, supervisor). Использование этого механизма позволяет приложению добиться отказоустойчивости.
• Ссылочная прозрачность (referential transparency) - как только переменная получила какое-то значение его уже нельзя изменить (single assignment), для нового значения нужно заводить новую переменную. На первый взгляд выглядит полным бредом, но именно эту цену нужно заплатить для гарантии того, что какая-то другая часть кода втихаря не «испортит» значение. Плюс отсутствие изменений в структурах данных в памяти дает большую свободу для применения различных оптимизаций компилятору, сборщику мусора и планировщику процессов.
• Планировщик процессов (scheduler) — виртуальная машина Erlang с точки зрения операционной системы выглядит как один процесс с несколькими потоками исполнения (threads), каждый из которых имеет собственный планировщик, управляющий группой Erlang-процессов. Процессы могут прозрачно перемещаться из одного потока в другой для балансировки нагрузки. Помимо этого планировщик берет на себя управление вводом-выводом, которые на низком уровне реализованы в неблокирующей, основанной на событиях, манере с использованием epoll или аналогов, но для конечного разработчика представляется в упрощенном виде.
• Сборщик мусора в памяти (garbage collector) — в отличии от других виртуальных машин (в частности JVM) сборка мусора в Erlang не влечет за собой значимых задержек в работе приложений, так как благодаря изоляции процессов для сборки мусора они останавливаются по очереди, пока все остальные продолжают работать. Обычно область памяти выделенная под один процесс очень невелика (для сравнения: под новый процесс в Erlang выделяется около 1 килобайта, под новый поток исполнения в Java — более 512 килобайт в зависимости от реализации), так что сборка мусора для каждого процесса не занимает много времени. Планировщик может определить какие процессы нужно пропустить при очередной сборке мусора, если они не исполнялись с момента предыдущей сборки. Если процесс создается для выполнения кратковременной задачи, то он может успеть сделать свое дело и завершиться без единой сборки мусора, полностью освободив свою память по окончании работы.
• Функциональное программирование (functional programming) - если рассмотреть один Erlang-процесс внутри, отбросив его связь с внешним миром (обмен сообщениями), то можно увидеть программу, полностью соответствующую функциональной парадигме: алгоритмы выражаются в виде вызовов функций, которые, в свою очередь, являются единицами данных наравне с числами и сложными структурами. На практике же это означает другой стиль программирования и используемые абстракции (рекурсия вместо циклов, поведения вместо интерфейсов и т.п.), по сравнению с более распространенными объектно-ориентированными языками; подробно это будет интересно лишь программистам, так что оставим это для другой статьи про Erlang.
• Доступно три механизма хранения данных вне памяти процессов:
• ETS (erlang term storage) — очень похожий на хранилище пар ключ-значение механизм, работающий в оперативной памяти самой виртуальной машины и доступный всем или части её процессов (есть ограничения доступа). Данные хранятся в пространствах имен (таблицы без жесткой структуры), а доступ осуществляется по ключу, который являются частью значения (обычно первым элементом в хранящейся структуре данных).
• DETS (disk erlang term storage) - предоставляется аналогичный ETS интерфейс и формат хранения данных, с той лишь разницей, что данные хранятся в файлах на диске, а не в памяти виртуальной машины. При использовании нетвердотельных дисков операции поиска данных значительно медленнее аналогов из модуля ETS.
• Mnesia — полноценная СУБД на основе ETS/DETS, с поддержкой атомарных транзакций (atomic transactions), репликации (replication) и партиционирования (sharding). Позволяет абстрагироваться от физического расположения данных, осуществлять поиск/выборки данных в реальном времени, а также вносить изменения в конфигурацию и схему данных без перезапуска.
• Горячее обновление кода (hot code loading) — виртуальная машина может держать в памяти и параллельно выполнять две версии одного и того же кода (единицей измерения здесь является модуль, то есть один скомпилированный файл исходного кода), процесс переключается со старого кода на новый при выполнении внешнего вызова к одной из его функций (что в целом полностью в руках разработчика). Эта возможность позволяет полностью избежать недоступности приложения при обновлениях, что очень важно для всех приложений, работающих в реальном времени, к которым также относятся все сайты и интернет-сервисы.

 Применение на практике

Телекоммуникации и Интернет на сегодняшний день хоть и являются совершенно разными областями информационных технологий, но все же глобальная цель у них общая: позволять людям легко общаться удаленно. Предлагаю вернуться к изначальной теме статьи: в каких конкретно ситуациях Erlang, вместе со своими изложенными выше особенностями и ограничениями, может оказаться уместным решением задач интернет-проекта? Примеры могут показаться субъективными, так что с удовольствием готов обсудить их и другие ситуации в комментариях.

Входящие пользовательские соединения

Еще в далеком 2002 году в сети часто мелькал сравнительный бенчмарк Apache © и Yaws (Erlang) по обработке HTTP-запросов, где Yaws представлялся «победителем» с огромным отрывом. С тех пор конечно же многое поменялось, появился стремительно набирающий обороты nginx и «популярные в узких кругах» решения вроде node.js или Tornado.

Но Erlang тоже не стоит на месте. Благодаря целенаправленной работе по оптимизации ERTS в целом и планировщика процессов в частности, современные реализации HTTP-серверов на Erlang по-прежнему легко дают фору более распространенным решениям.

В последние годы появляется все больше интернет-проектов, использующие постоянные соединения (websocket, long polling, etc.) между браузером и HTTP-сервером для обновления страниц сайта в реальном времени. Здесь также Erlang легко справляется с задачей, так как для поддержания постоянного соединения обычно используется лишь 1 Erlang-процесс (хотя иногда 2), которые, как уже упоминалось, потребляют минимум  оперативной памяти и вычислительных ресурсов. Как следствие, HTTP-сервер на Erlang способен поддерживать очень постоянное соединение с онлайн пользователями, даже если их количество измеряется десятками тысяч.

Хочется отметить, что в этом примере речь идет именно об обработке соединений с пользователями, то есть внутри HTTP-сервера минимум логики, он просто «разбирает» запрос и, вероятно, передает его дальше внутрь системы через брокер сообщений или напрямую внутренним сервисам. К вопросу с сколько-либо сложной бизнес-логикой вернемся чуть позже.

Отдача статики

Для отдачи статики в Erlang часто используют тот же системный вызов sendfile, что и в nginx. Но на практике ситуация здесь неоднозначна:

• прямой доступ к sendfile через встроенные вызовы (BIF, Built-In Functions) появился в Erlang только в самом последнем на сегодняшний день релизе — R15B;
• раньше использовалась обертка с использованием нативных функций (NIF, native implemented functions) или просто чтение файла, что работало не очень хорошо.

• 1.1Мб картинка в 10 потоков (нехитрая математика говорит о том, что все упираются в сеть):
• Cowboy без sendfile: 853мс. в среднем, 639 запросов в минуту, отклонение 428мс.
• Cowboy с sendfile: 853мс. в среднем, 639 запросов в минуту, отклонение 395мс.
• Nginx: 882мс. в среднем, 638 запросов в минуту, отклонение 515мс.
• 112б текстовый файл в 1000 потоков:
• Cowboy без sendfile: 37мс. в среднем (но медиана — 3мс., то есть небольшая часть запросов сильно тормозит, а с остальной все нормально), 259 тыс. запросов в минуту, отклонение 234мс.
• Cowboy с sendfile: 17 мс. в среднем, 267 тыс. запросов в минуту, отклонение 27мс.
• Nginx: 2мс. в среднем, 315 тыс. запросов в минуту, отклонение 3мс.

В любом случае, для отдачи статики в сколько-либо серьезных интернет-проектов рекомендую пользоваться услугами CDN.

Балансировка нагрузки

Откровенно говоря, я не слышал о каком-либо проекте на Erlang для балансировки HTTP и/или TCP запросов, хотя бы отдаленно сравнимом по возможностям, надежности и производительности с HAProxy и «железными» решениями.

Хотя по мне так сами свойства Erlang прекрасно подходят для решения этой задачи, но те проекты, на которые я натыкался (пример), выглядят просто как «поделки» по сравнению с проверенными временем решениями.

В любом случае HTTP/TCP балансировщик нагрузки на Erlang — отличная  тема для нового opensource проекта, если вдруг кому-то нечем заняться в свободное время

Брокер сообщений

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

В дополнение хочется сказать, что хоть изобретать велосипед и редко когда оказывается хорошей затеей, Erlang отлично подошел бы и для реализации собственной схемы обмена сообщениями внутри системы, например без использования централизованного брокера, как это в итоге получается с использованием RabbitMQ или аналогов.

Бизнес-логика

Этот аспект является практически уникальным от проекта к проекту, так что здесь придется ограничиться лишь какими-то общими рекомендациями.

Основной слабой стороной Erlang является обработка данных, в частности:

• Текстовые строки в Erlang реализованы как однонаправленный связанный список целых чисел, то есть на каждый символ выделяется восемь байт памяти: четыре на код символа, четыре — на указатель на следующий символ; плюс еще четыре байта для указателя на начало списка. Для 64-битных систем эти цифры нужно удвоить, так как машинное слово вдвое длиннее. Помимо неоправданных расходов памяти, эта схема усложняет различные операции со строками, например чтобы посчитать длину строки нужно «пройтись» по ней целиком. А чтобы приписать один символ в конец строки, нужно сделать её полную копию (для записи в начало это не так, как не трудно догадаться).
• Бинарные строки хранятся в памяти последовательно, так что объем не удваивается из-за указателей. Изменения в итоге также создают копии данных, что для больших строк накладно. В любом случае там где это возможно я бы рекомендовал использовать бинарные строки вместо текстовых.
• С математическими задачами все не так плачевно: хоть и реализация базовых операций в виртуальной машине несколько отстает по производительности от чистого С, при желании его можно практически догнать средствами нативной компиляции, грамотной реализации алгоритма и отсутствия «палок в колесах» у компилятора. Альтернативный сценарий: использование NIF.

Для не-англоязычных проектов трудностью может оказаться довольно сомнительная поддержка Unicode: особого типа данных нет, в тех же текстовых строках код символа может выходить за пределы таблицы ASCII (не зря же на него 32 или 64 бита выделили), а в бинарных строках можно хранить что угодно, в т.ч. и Unicode-текст. Как прореагирует на Unicode тот или иной встроенный модуль или используемая библиотека никто не гарантирует, но обычно все более-менее нормально.

Хоть на самом деле это и является роскошью, но при реализации бизнес-логики на Erlang порой недостает ORM-подобных механизмов в духе «вытащил объект из базы, поменял в нем что-нибудь, положил обратно». Не то чтобы таких библиотек нет, просто эта схема не очень хорошо «ложится» на функциональную парадигму и реализуется обычно через не особо предназначенные для этого механизмы словарей (dict) или именованных кортежей (record).

В качестве резюме хочется сказать, что на Erlang можно реализовать бизнес-логику практически любого интернет-проекта. Просто если она сложнее, чем просто передать какие-то данные от одного пользователя другому, то вероятно из-за искусственных ограничений и недостаточной выразительности языка для эффективной её разработки на Erlang может потребоваться существенно больше времени и усилий, чем на более приспособленных для этого языках вроде Ruby, PHP и Python.

Базы данных

Здесь все довольно просто: обычно Erlang используется как распределенная надстройка над встраиваемыми СУБД или особыми форматами файлов. Основные представители: Riak (Google LevelDB), CouchDB (свой формат), Mnesia (DETS), Couchbase (memcached и SQLite) — все совершенно разные, обсуждать и сравнивать можно до бесконечности, так что оставим это на другой раз.

Из общих особенностей вышеперечисленных решений можно выделить:

• Прозрачная горизонтальная масштабируемость;
• Настраиваемый уровень репликации данных;
• Обычно доступность и персистентность в ущерб строгой целостности (AP из CAP-теоремы);
• Поддержка сложных распределенных выборок (MapReduce, многокритериальная фильтрация, полнотекстный поиск и т.п., за исключением Couchbase)
• Способность легко справляться с большим потоком изменений данных (за исключением, пожалуй, CouchDB);
• Отсутствие строгой схемы данных и SQL-подобного интерфейса.

Подводим итоги

Erlang в умелых руках может послужить и правда удачным решением для реализации многих аспектов интернет-проектов, благодаря качественной, проверенной временем, основе в виде виртуальной машины и OTP, а также продуманной модели легковесных процессов. В результате получаются высокопроизводительные, горизонтально масштабируемые приложения, полностью приспособленные для стабильной бесперебойной работы в боевых условиях.

Высокий барьер обучения специалистов по-прежнему остается весомым аргументом «против», но если в проекте команда разработчиков уровня выше среднего - вряд ли это станет серьезным препятствием. Недостаток «готовых» квалифицированных специалистов по Erlang на трудовом рынке также не особо радует, но ситуация определенно постепенно улучшается.

В комментариях предлагаю обсудить по каким еще причинам на сегодняшний день Erlang столь редко можно увидеть в технологическом стеке интернет-проектов? Какие еще вопросы смущают руководство и разработчиков? В каких ситуациях преодоление сложностей и ограничений, связанных с Erlang, того стоит?

Эта статья определенно будет далеко не последней про Erlang, так что если эта тема Вам близка — рекомендую подписаться на RSS.

Когда веб-приложение перестает быть просто коллекцией скриптов, генерирующих HTML, встает вопрос о взаимодействии различных компонентов системы. Есть два основных подхода:

• обращение напрямую посредством протоколов вроде Thrift или Protocol Buffers;
• либо посредством брокера сообщений, посредника, берущего на себя вопросы их маршрутизации и доставки одному или нескольким получателям, даже в случае сбоев оборудования и недоступности сетевого соединения.

Сегодня я хотел бы рассказать об одной из лучших, на мой взгляд, реализаций брокера сообщений, RabbitMQ. Хотите узнать почему я так считаю? — Дочитайте до конца

Основные понятия

Слоганом RabbitMQ является «обмен сообщениями, который просто работает». Отчасти с этим утверждением можно согласиться, для того чтобы сервис обмена сообщениями «просто заработал» достаточно простой команды aptitude install rabbitmq-server или аналога для операционных систем, не основанных на Debian. Но кому этого будет достаточно? Как минимум нужно научить свой проект эти сообщения отправлять и принимать, а как максимум — обрабатывать десятки и сотни тысяч сообщений в секунду, но обо всем по порядку.

В основе RabbitMQ лежит протокол AMQP, который вводит три основных понятия:

• Сообщение (message) - единица информации, которая передается от отправителя к получателю(ям); состоит из набора заголовков и содержания, которое брокером никак не интерпретируются.
• Точка обмена (exchange) - распределяет отправленные сообщения между одной или несколькими очередями в соответствии с их заголовками.
• Очередь (queue) - место, где хранятся сообщения до тех пор, пока их не заберет получатель.

Базовые механизмы взаимодействия с брокером очень просты:

• Отправить сообщение (publish) — сообщение сериализуется в определенный формат, при необходимости снабжается маршрутной меткой (routing key) и передается в RabbitMQ;
• Получать сообщение (consume или subscribe) — приложение регистрируется в RabbitMQ с указанием какие именно сообщения оно готово получать и обрабатывать, после чего ожидает их доставки.

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

• Отправка всем (fanout) — как следует из названия, каждое сообщение получат все очереди, связанные с данной точкой обмена, типичная публикация-подписка (publish-subscribe).
• Прямая (direct) - сообщение получит только та очередь, которая имеет название, соответствующее маршрутной метке сообщения, типичная очередь сообщений (message queue).
• Тематическая (topic) — очереди при регистрации указывают паттерн маршрутных меток сообщений, которые они хотели бы получать. Этот механизм позволяет наиболее гибко управлять маршрутизацией сообщений и строить нетривиальные схемы доставки. Вместо регулярных выражений используется очень простая схема: метки в виде слов, разделенных точками; в паттерне * заменяет ровно одно слово, # — ноль или больше; при отсутствии этих символов работает как прямая точка обмена.

Типичные сценарии

Выполнение длительных операций

Представим себя интернет-проектом, который размещает у себя пользовательские видео или фото. Когда он получает по HTTP очередной файл, ему требуется сконвертировать его в стандартный формат для просмотра другими пользователями, а также, например, сделать несколько превью разного размера.

По-старинке эти операции делают последовательно в том же обработчике запроса, который и принял от пользователя файл. В схеме с брокером же после принятия файла он отправляет сообщение, в содержании которого будет, вероятно, ссылка на файла-оригинал, после чего он возвращает браузеру сообщение об успешной загрузке файла. Для отправки таких сообщений используют прямую точку обмена, с какой-то стандартной маршрутной меткой и соответствующим именем очереди, например process_video или create_thumbnails. Процессы, реализующие совершенно независимый сервис по выполнению этих длительных операций, будут по очереди забирать сообщения с «заданиями» из брокера, позволяя легко создавать любое количество исполнителей c балансировкой нагрузки, что обеспечит горизонтальное масштабирование этой подсистемы.

Еще один доступный механизм, который вписывается в эту задачу — подтверждение о получении сообщения (acknowledgement). Получатель должен отправить брокеру дополнительное сообщение о том, что такое-то сообщение было успешно получено, в противном случае оно останется в очереди ожидать следующего получателя. Если процессы-исполнители будут подтверждать получение только после успешного выполнения длительной операции, это будет гарантировать, что все задания будут успешно выполнены вне зависимости от сбоев на каждом конкретном исполнителе, что обеспечивает отказоустойчивость.

Удаленный вызов (RPC)

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

Для этого предусмотрено два заголовка сообщений:

• Обратный адрес (reply to) — исполнитель должен отправить результат в очередь с указанным именем; отравитель сразу же после передачи сообщения-запроса брокеру начинает получать сообщения из указанной в этом заголовке очереди.
• Идентификатор запроса (correlation id) — должен быть уникальным среди запросов, чтобы отправитель мог сопоставить результаты с запросами.

Сообщения пользователям

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

В этом примере очень важно использовать режим постоянных сообщений (persistant, путем установки заголовка delivery_mode=2), так как получатель сообщения может появиться очень не скоро и важно чтобы сообщения «переживали» даже полный перезапуск брокера сообщений. Для более короткоживущих сообщений это менее критично, но тоже порой актуально, особенно как еще одна мера для обеспечения отказоустойчивости.

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

Двустороннее соединение с браузером

Пожалуй, самый «вкусный» пример, хоть и лежащий на поверхности. На многих крупных интернет-проектах, особенно социальной направленности можно увидеть уведомления в реальном времени о событиях на сайте — кто-то что-то написал, поставил +1, проголосовал и т.п.

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

На серверной части эта задача делится на две части:

• Поддерживать  постоянное соединение со всеми пользователями, кто находится онлайн — здесь на помощь обычно приходит либо Erlang, либо неблокирующий сервер на epoll. Оба варианта очень неплохие, выбирайте сами.
• Дальше нужно как-то организовать доставку сообщений (информацию о событиях в системе) между пользователями, где и вступает в игру брокер. Обработчик соединения подписывается на сообщения о публичных событиях (точка обмена «отправить всем»), и туда же отправляет информацию о действиях пользователя-владельца.

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

Кластеризация

Многое из вышеизложенного справедливо и для других реализаций AMQP, но в вопросе кластеризации RabbitMQ предстает во всей красе. Залогом этого в первую очередь является использование Erlang, не знаю почему я до сих пор не написал статью про этот язык программирования, здесь достаточно было бы на нее сослаться и все стало бы ясно.

Если вкратце, то в Erlang реализована внутренняя система легковесных процессов, не имеющая общего состояния и взаимодействующая друг с другом исключительно посредством обменом сообщений. При этом с точки разработчика отправка сообщений другому процессу на том же физическом сервером и на удаленном выглядит одинаково, и даже является одним из операторов языка — «!», наравне с «=», «+» и.т.п. Этот факт позволяет приложениям или их частям взаимодействовать по сети так же легко, как и в рамках одного сервера.

Чтобы определить разрешено ли разным Erlang-сервера взаимодействовать друг с другом, они обмениваются хэшем пароля (который правда называют cookie, хотя с одноименным механизмом браузеров он ничего общего не имеет) и продолжают работу только если он совпал. Он должен быть одинаковым на всех узлах и хранится в файле ~/.erlang.cookie, для RabbitMQ это обычно  /var/lib/rabbitmq/.erlang.cookie — первым делом нужно решить этот вопрос, а также убедиться, что используется нестандартное значение.

Узлы в RabbitMQ кластере могут быть двух типов: работающие только в памяти и сохраняющие данные на диск. Так как состояние системы реплицируется между узлами кластера, в большинстве случаев достаточно иметь лишь 2-3 дисковых узла, а остальные избавить от необходимости работать с дисковой подсистемой для увеличения производительности.

Важно понимать, что под состоянием системы здесь имеются ввиду лишь привязки и настройки брокеров, каждая же очередь и хранящиеся в ней сообщения располагаются на одном конкретном узле, что приведет к потери части сообщений при сбое одного из серверов. Этот вопрос можно решить и средствами операционной системы, но чаще всего правильнее выделить критически-важные для системы очереди сообщений и включить их репликацию средствами RabbitMQ, этот механизм называется зеркальные очереди (mirrored queues).  Репликация происходит по принципу мастер-слуга (master-slave), как и в реляционных СУБД: все операции осуществляются на основном сервере (мастере), он транслирует их на один или несколько вторичных серверов (слуги), при каком-либо сбое на основном один из слуг «повышается» до статуса мастера и берет на себя его функции. Очереди могут быть объявлены зеркальными только при создании, но новые узлы в роли слуг могут добавляться и позже, в таком случае новый слуга начнет получать входящие сообщения и рано или поздно начнет полностью отражать его состояние, механизма синхронизации при подключении дополнительного слуги не предусмотрено. Последним шагом для гарантированной доставки сообщений, не упоминавшимся ранее, является механизм уведомления отправителя об успешной записи сообщения в очередь (на все сервера для зеркальных).

В кластерном окружении может понадобиться объединение точек обмена (exchange federation), что реализуется посредством пересылки сообщений по однонаправленным связям. При этом учитывается наличие на принимающей стороне очередей, готовых принять каждое конкретное сообщение. Практического применения в веб-проектах этому пока особо не вижу, разве что при кросс-датацентровой работе. Кстати, для этого поддерживается работа поверх SSL.

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

Подводим итоги

Используя брокер сообщений при технической реализации интернет-проекта, можно перевести его на совершенно новый уровень с точек зрения отказоустойчивости и горизонтальной масштабируемости. Во многих случаях он становится «сердцем» приложения, без которого его существование было бы немыслимо, но в то же время благодаря кластеризации не становится единственной точкой отказа (single point of failure).

Хоть многое из упомянутого в статье можно реализовать и с помощью других технологий, RabbitMQ является наиболее приспособленной к реалиям современного Интернета реализацией брокера сообщений и AMQP в частности, в первую очередь благодаря распределенной природе Erlang и качественно спроектированной архитектуре этого продукта.

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

Жду Вас среди постоянных читателей Insight IT, число которых недавно перевалило за 14 тысяч

Tornado - масштабируемый неблокирующий HTTP-сервер на основе epoll, написанный полностью на Python. Изначально он был разработан в рамках проекта FriendFeed, на сегодняшний же день его поддержкой занимается Facebook. Сегодня я хотел бы рассказать о том, как с его помощью можно быстро и легко создавать веб-проекты на Python, которые в дальнейшем будет относительно легко горизонтально масштабировать.

HTTP

Не смотря на приличное количество опциональных модулей, идущих в комплекте с Tornado, проект в первую очередь является именно HTTP-сервером. Используемый механизм epoll (по ссылке можно прочитать о том, в чем он заключается) практически полностью определяет основные принципы работы Tornado:

• он работает в рамках одного процесса;
• использование потоков внутри него нежелательно;
• для использования всех доступных ядер процессора обычно запускают несколько копий одинаковых процессов на разных портах (недавно добавили модуль tornado.process для упрощения реализации этого);
• обычно обрабатывает HTTP-запросы не напрямую, а через балансировщик нагрузки (nginx или HAProxy).

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

Стоит добавить, что вместе с проектом поставляется модуль tornado.wsgi, который позволяет запускать внутри себя другие веб-ориентированные проекты на Python (в частности небезызвестный Django), а также «притворяться» таковым для каких-то внешних серверов или сервисов, которые умеют общаться с Python-приложениями только по WSGI-протоколу, например таковым является Google App Engine. Пользоваться этим модулем крайне не рекомендую, только при постепенном мигрировании проекта с каких-то других технологий.

Обработка запросов

При использовании Tornado не приходится работать с HTTP напрямую — разбор заголовков и URL он берет на себя. От разработчика требуется лишь словарь, состоящий из регулярных выражений и соответствующих им классов-обработчиков запросов.

При создании этих классов настоятельно рекомендую по полной воспользоваться возможностями ООП, в частности наследования. Tornado предоставляет базовый класс RequestHandler, который берет на себя всю грязную работу, а разработчику предлагается реализовать лишь логику, переопределив метод(ы) get, post, delete или head. На практике же обычно удобнее иметь свой собственный базовый класс для обработчиков запросов, который унаследован от RequestHandler и реализовывает общую для текущего конкретного проекта логику (примеры ниже).

Доступ к базе данных

Модуль tornado.database предлагает довольно простой доступ к MySQL. С одной стороны благодаря нему можно сходу начинать разрабатывать приложение на Tornado без использования дополнительных библиотек, с другой — далеко не в каждом проекте используется именно эта СУБД.

В любом случае никто не запрещает использовать любую другую библиотеку для доступа к любой другой СУБД, но есть одно большое НО! Большинство из них являются блокирующими, то есть не возвращают управление до тех пор, пока СУБД не вернет ответ. Почуяли неладное? Правильно, в таком случае весь процесс Tornado, вместе со всеми попавшими в него запросами, будет простаивать пока управление не будет получено обратно, что очень не здорово.

Решается эта неприятная ситуация путем отправки асинхронных запросов к СУБД, то есть после отправки запроса управление сразу же возвращается, а для обработки запроса регистрируется callback, который получит управление, когда прийдет ответ от СУБД. За планирование очередности передачи управления отвечает IOLoop, который и является «сердцем» Tornado.

Ассортимент готовых библиотек, интегрированных с Tornado IOLoop, довольно широк и не ограничивается одним доступом к СУБД. Хотя готовое решение получается найти все же не всегда — приходится возиться с этим всем вручную или мириться с блокировками…

Взаимодействие с внешним миром

В комплекте с Tornado идет неблокирующий HTTP-клиент, так что внутренние сервисы проще всего реализовывать с интерфейсом на JSON over HTTP. Им же можно и обращаться к API внешних сервисов.

С Thrift и Protocol Buffers ситуация несколько более печальна — о прецедентах их интеграции в Tornado IOLoop я не слышал, если кто-то может поделиться информацией — буду благодарен, довольно актуальный вопрос.

Генерация HTML

Шаблонизатор также предлагается свой собственный (не очень удачный, но вполне можно использовать), но его особо никто не навязывает — необходимо лишь переопределить метод render у базового RequestHandler с использованием любого другого аналогичного продукта.

Например, Jinja2, о котором я недавно писал, подключается примерно вот так:

from connections import env
from tornado.web import RequestHandler
class BaseHandler(RequestHandler):
  def render(self, template, context = None):
    if not context: context = {}
    context['user'] = self.current_user
    self.write(env.get_template(template).render(context))
    self.flush()

Прочие бонусы

• tornado.gen — набор инструментов для упрощения написания асинхронного кода. Благодаря использованию механизма генераторов (yield), позволяет уместить в рамках одного метода и отправку асинхронного запроса и обработку его результата.
• tornado.websocket предлагает реализацию нескольких последних редакций одноименного протокола,  доступна пара более кроссбраузерных альтернатив с поддержкой нескольких протоколов: sockjs-tornado и TornadIO.
• С помощью tornado.platform.twisted можно запускать код, написанный под Twisted (несколько более громоздкий и пожилой конкурент), внутри Tornado IOLoop. Актуально для «мигрирующих» проектов и прикручивания библиотек, написанных под Twisted.
• Без tornado.autoreload разработка превратилась бы в настоящий кошмар.

 Заключение

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

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

В комментариях предлагаю подискутировать на тему пригодности Tornado и аналогичных продуктов для использования в различных интернет-проектах, как высоконагруженных, так и маленьких. Еще мне было бы интересно узнать насколько велик интерес аудитории к чуть более прикладным, чем обычно, статьям, вроде этой — с удовольствием выслушаю Ваше мнение. До новых встреч!

Tumblr — одна из самых популярных в мире платформ для блоггинга, которая делает ставку на привлекательный внешний вид, юзабилити и дружелюбное сообщество. Хоть проект и не особо на слуху в России, цифры говорят сами за себя: 24й по посещаемости сайт в США с 15 миллиардами просмотров страниц в месяц. Хотите познакомиться с историей этого проекта, выросшего из простого стартапа?

Введение

Как и всем успешным стартапам, Tumblr удалось преодалеть опасную пропать между начинающим проектом и широко известной компанией. Поиск правильных людей, эволюция инфраструктуры, поддержка старых решений, паника по поводу значительного роста посещаемости от месяца к месяцу, при этом в команде только 4 технических специалиста — все это заставляло руководство Tumblr принимать тяжелые решения о том над чем стоит работать, а над чем — нет. Сейчас же технический персонал расширился до 20 человек и у них достаточно энергии для преодоления всех текущих проблем и разработки новых интересных технических решений.

Поначалу Tumblr был вполне типичным большим LAMP приложением. Сейчас же они двигаются в направлении модели распределенных сервисов, построенных вокруг существенно менее распространенных технологий. Основные усилия сейчас вкладываются в постепенный уход от PHP в пользу более «правильных» и «современных» решений, оформленных в виде сервисов. Параллельно с переходом к новым технологиям идут изменения и в команде проекта: от небольшой группы энтузиастов к полноценной команде разработчиков, имеющей четкую стуктуру и сферы ответственности, но тем не менее жаждущей реализовывать новый функционал и обустраивать совершенно новую инфраструктуру проекта.

Платформа

• CentOS на серверах, Mac OS X для разработки
• Apache — основной веб-сервер
• PHP, Scala, Ruby — языки программирования
• Finagle - асинхронный RPC сервер и клиент
• MySQL, HBase - СУБД
• memcached, Redis - кэширование
• Varnish, nginx — отдача статики
• HAProxy — балансировка нагрузки
• kestrel, gearman — очередь задач
• Thrift — сериализация
• Kafka — распределенная шина сообщений
• Hadoop — обработка статистики
• ZooKeeper — хранение конфигурации и состояний системы
• git — система контроля версий
• Jenkins — непрерывное тестирование

Статистика

• Около 500 миллионов просмотров страниц в день
• Более 15 миллиардов просмотров страниц в месяц
• Посещаемость растет примерно на 30% в месяц
• Пиковые нагрузки порядка 40 тысяч запросов в секунду
• Около 20 технических специалистов в команде
• Каждый день создается около 50Гб новых постов и 2.7Тб обновлений списков последователей
• Более 1Тб статистики обрабатывается в Hadoop ежедневно
• Используется порядка 1000 серверов:
• 500 веб-серверов c Apache и PHP-приложением
• 200 серверов баз данных (существенная их часть — резервные)
• 47 пулов
• 30 партиций (шардов)
• 30 серверов memcached
• 25 серверов Redis
• 15 серверов Varnish
• 25 серверов HAProxy
• 8 серверов nginx
• 14 серверов для очередей задач

Типичное использование

• Tumblr используется несколько по-другому, чем другие социальные сети:
• При более чем 50 миллионах постов в день, каждый из них попадает в среднем к нескольким сотням читателей. Это и не несколько пользователей с миллионами читателей (например, популярные личности в Twitter) и не миллиарды личных сообщений.
• Ориентированность на длинные публичные сообщения, полные интересной информацией и картинками/видео, заставляет пользователей проводить долгие часы каждый день за чтением Tumblr.
• Большинство активных пользователей подписывается на сотни других блоггеров, что практически гарантирует много страниц нового контента при каждом заходе на сайт. В других социальных сетях поток новых сообщений переполнен ненужным контентом и толком не читается.
• Как следствие, при сложившемся количестве пользователей, средней аудиторией каждого и высокой активностью написания постов, системе приходится обрабатывать и доставлять огромное количество информации.
• Публичные блоги называют Tumblelog'ами, они не так динамичны и легко кэшируются.
• Сложнее всего масштабировать Dashboard, страницу, где пользователи в реальном времени читают что нового у блоггеров, на которых они подписаны.
• Кэширование практически бесполезно, так как для активных пользователей запросы редко повторяются.
• Информация должна отображаться в реальном времени, быть целостной и не «задерживаться».
• Около 70% просмотров страниц приходится именно на Dashboard, почти все пользователи им пользуются.

Старая архитектура

Новая архитектура

Разработка

• Поначалу философия была такова, что каждый мог использовать любые технологии, которые считал уместным. Но довольно скоро пришлось стандартизировать стек технологий, чтобы было легче нанимать и вводить в работу новых сотрудников, а также для более оперативного решения технических проблем.
• Каждый разработчик имеет одинаковую заранее настроенную рабочую станцию, которая обновляется посредством Puppet:
• Настроена публикация изменений, тестирование и развертывание новых версий.
• Разработчики используют vim и Textmate.
• Новый PHP код систематически инсптируется другими разработчиками.
• Внутренние сервисы подвергаются непрерывному тестированию посредством Jenkins.

Структура команд

Найм

• На интервью они обычно избегают математики и головоломок, основной упор идет в основном именно на те вещи, которым придется заниматься кандидату.
• Основной вопрос: будет ли он успешно решать поставленные задачи? Цель в том, чтобы найти отличных людей, а не в том, чтобы никого не брать.
• Разработчиков обязательно просят привести пример своего кода, даже во время телефонных интервью.
• Во время интервью кандидатов не ограничивают в наборе инструментов, можно даже гуглить.
• Поиск людей с опытом в крупных проектах достаточно сложен, так как всего нескольких компаниях по всему миру решают подобные проблемы.

Подводим итоги

• Автоматизация — ключ к успеху крупного проекта.
• При партиционировании MySQL может масштабироваться, но лишь при преобладании операций чтения.
• Redis с отключенной персистентностью легко может заменить memcached.
• Scala достойно себя проявляет в роли языка программирования для внутренних сервисов, во многом благодаря обширной Java-экосистеме.
• Внедряйте новые технологии постепенно, поначалу работать с HBase и Redis было очень болезненно, они были включены в основной стек технологий только после испытаний в некритичных сервисах и подпроектах, где цена ошибки не так велика.
• Проект должен строиться вокруг навыков его команды, а не наоборот.
• Нужно нанимать людей только если они вписываются в команду и в состоянии довести работу до результата.
• При выборе технологического стека одну из ключевых ролей играет доступность соответствующих специалистов на кадровом рынке.
• Читайте публикации и статьи в блогах. Ключевые аспекты архитектуры, включая «ячейки» и частичную материализацию были позаимствованы из внешних источников.
• Поспрашивайте своих коллег, кто-то из них мог общаться с специалистами из Facebook, Twitter, Google или LinkedIn — если нет прямого доступа, всегда можно получить нужную информацию через одно-два «рукопожатия».

Я уже много раз упоминал в комментариях и других постах, что когда мне приходится программировать, последние пару лет я чаще всего использую Python. При этом так забавно получилось, что в рубрике «Программирование» об этом языке практически ни слова, даже подрубрики не было. Сегодня я попробую потихоньку начать исправлять данную ситуацию, речь пойдет об одном из самых продвинутых шаблонизаторов под Python — Jinja2. Встречаем!

Введение

Я хочу рассказать о том, что можно интересного сделать с помощью Jinja2, по вопросам как именно — лучше обратиться к официальной документации. Хотя на конкретные вопросы по реализации в комментариях с удовольствием отвечу.

Прежде чем перейти к делу, хочу напомнить что имеется ввиду под словом шаблонизатор: механизм для создания HTML-страниц путем заполнения HTML-шаблонов динамическими данными, получаемыми из СУБД или внешних источников. Шаблонизатор предоставляет некую надстройку над синтаксисом HTML для создания шаблонов и API для их использования.

Базовый функционал

Многое из этого можно увидеть и в альтернативных реализациях шаблонизаторов, так что ничего особенного:

• {{ … }} позволяет распечатать значение переменной или какого-то выражения, синтаксис достаточно свободный — можно обращаться к элементам коллекций, методам/атрибутам объектов и.т.п.
• {% … %} позволяет вызвать дополнительные теги, среди которых условные выражения, различные варианты циклов и многое другое.
• Присутствиет концепция фильтров, сильно напоминающих UNIX pipes: начинается все с переменной или выражения, после чего можно через символ | указать как её обработать перед выводом в итоговый документ. Например, {{ foo|lower }} выведет содержимое строки foo в нижнем регистре. Как и в pipes, из фильтров можно делать цепочки.
• Механизм наследования позволяет избежать избыточности в коде. В коде шаблона выделяются именованные блоки тегом {% block … %}, после чего шаблон-потомок может переопределить содержимое блоков шаблона-родителя произвольным образом. Типичный пример использования:
• Создается базовый шаблон страницы, состоящий из основного каркаса страницы  и всех общих для всего сайта элементов (ссылки на файлы стилей, общие JavaScript файлы и библиотеки, какие-то мета теги, title по-умолчанию)
• В базовом шаблоне содержимое каждой части выделяется в именованный блок (как минимум шапка, место под контент, 1-2 сайдбара и подвал), иногда рядом со стилями и скриптами оставляют по пустому блоку на случай, если шаблонам-наследникам потребуется что-то специфичное.
• Если какой-то блок будет содержать одну и ту же информацию на большинстве страниц сайта, то её тоже обычно помещают в базовый шаблон.
• Создается по шаблону-потомку на каждый тип используемых на сайте страниц, в которых переопределяется как правило  (но далеко не всегда) только блок с конткентом и заголовок страницы. Из шаблонов-потомков также можно составить иерархию в случае, если у них есть много общей информации.
• Стоит упомянуть, что есть альтернативный механизм включения (include) шаблонов по-аналогии с PHP-файлами, но я достойных применений ему не нашел.
• Очень много внимания уделено экранированию символов, хотя особо на него надеяться не стоит — с точки зрения безопасности намного важнее фильтровать попадающие на сайт данные, а не выводимые в шаблонах. Хотя как дополнительная подстраховка не помешает.
• Простая интеграция с gettext придется кстати интернациональным проектам.
• Опциональное считывание шаблонов с диска при каждом запросе страницы незаменимо при разработке.

Производительность

Сравнительные тесты производительности шаблонизаторов под Python довольно условны, очень многое зависит от конкретных шаблонов и динамических данных. Тем не менее, во всех из них Jinja2 определенно не в аутсайдерах, в топ5 вполне стабильно.

Шаблоны компилируются в байткод для последующего использования, с этой особенностью связаны два момента, которые спользовать:

• Байткод можно хранить в memcached или любом другом внешним хранилище, достаточно лишь реализовать минимальный get/set интерфейс.
• Доступен опциональный модуль на C, который берет на себя часть работы по заполнению шаблонов, что делает этот процесс несколько быстрее.

Расширяемость

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

Webassets

Этот проект позволяет делать с подключаемыми внешними Javascript и CSS файлами практически все, что угодно. В типичном варианте использования используется тег {% assets %} для:

• Указания списка изначальных CSS/JS файлов, для конкатенации и последующей обработки.
• Указания окружения ссылки на итоговый файл, т.е. как именно должен выглядеть тег <script> или <style>.
• Списка фильтров, для минимизации или других преобразований кода.
• Возможно использование sass или less файлов вместо чистого CSS.
• Отключение конкатенации и минимизации при разработке доступно изменением одного флага.

Доступна интегрирация и с другими Python шаблонизаторами, в Jinja2 он подключается просто как расширение.

Минимизация HTML

Этот вопрос решается путем наследования от поставляемого вместе с шаблонизатором загрузчика шаблонов. API позволяет делать между чтением шаблона и генерацией байткода что угодно с текстом шаблона, например можно пропустить все через примитивную регулярку (вернее через несколько) и свернуть тем самым весь HTML в одну строку. Хочется обратить внимание, что осуществляется этот процесс очень редко (особенно при использовании кэша байт кода), так что можно делать на этом этапе даже сильно ресурсоемкие преобразования текста.

Другой формат данных

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

Да, наверняка многие скажут, что в этой ситуации надо было использовать универсальные шаблоны для JS и серверной части, но на Jinja2 такое тожно можно реализовать, с той лишь разницей, что пришлось гонять по сети не только сами данные, но и часть HTML-разметки (что, порой, тоже не плохо). Реализуется как и минимизация HTML посредством переопределения загрузчика страниц, который использовался вместо стандартного, если запрос пришел через AJAX.

Сэкономим еще пару байт

С подобного рода оптимизацией не заборачивается, наверное и 0.01% интернет-проектов, но я в свое время как-то увлекся и написал штуку для «выжимания» десятка-другого байт с большинства страниц и CSS/JS файлов. «Проблема» состоит в следующем: классы и идентификаторы, использующиеся в HTML, в «культурных» проектах имеют хотя бы отдаленно человекочитаемые названия, что почти всегда означает их длинность, что, учитывая их частую повторяемость в коде, в свою очередь негативно влияет на итоговый размер HTML/JS/CSS документов. Теоретическое решение лежит на поверхности: использовать «длинные» идентификаторы и классы в HTML при разработке, а при развертывании на публику переименовывать их в «короткие»: a, b, c, …, aa, ab, ac, …

На практике же все несколько сложнее: есть масса проблем с префиксностью и суффиксностью, в JS классы иногда неотличимы от других строк с точками (зависят от контекста), некоторые классы и идентификаторы генерируются динамически — на них прийдется либо забивать, либо обрабатывать индивидуально, и это далеко не все…

Если у кого-то возникнет желание тоже сделать что-то подобное средствами Jinja2, то советую «вмешиваться» в обработку JS/CSS посредством дополнительного фильтра в Webassets, а сами шаблоны редактировать как и в предыдущих разделах при считывании их с диска.

Спрайты и обработка изображений

Создание спрайтов как таковых не предусмотрено, так как по сути это не по части шаблонизатора. Но есть вариант подключить их к Webassets, например через интеграцию Ruby-проектом compass (у которого есть плагин-генератор спрайтов).

Если говорить просто о уменьшении размеров изображений, то это легко делается средствами самого Python и с шаблонизатором практически не взаимодействует: достаточно обрабатывать изображения при загрузке их пользователями и держать статические изображения «в форме».

Идеи для фильтров и глобальных функций

Список встроенных в Jinja2 фильтров, функций и проверок, хоть и обширен, но того, что нужно, там зачастую не оказывается. Вот несколько примеров, чего в нем нет:

• Форматирования даты/времени по шаблону
• Фильтрации HTML с белым списком тегов
• Получения атрибута объекта с неизвестным заранее именем (getattr)
• Вывода строки в режиме «первая — заглавная, остальные — прописные
• Генерации часто используемых HTML-тегов, например <a href=»…»></a>

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

Подводим итоги

Jinja2 — отличный инструмент для тех проектов, которым важно не просто донести какую-то информацию до пользователей, а сделать это приятно и быстро, как для себя, так и для пользователя. Гибкость и расширяемость этого движка шаблонов позволяет адаптировать его под нужды любого проекта, а также воспользоваться в полной мере всеми возможностями современной клиентской оптимизации.

С удовольствием бы опубликовал упоминавшиеся в статье куски кода в opensource, но для этого нужно взять себя в руки и состряпать из них что-то «отчуждаемое» от тех проектов, для которых оно писалось.

В комментариях предлагаю обсудить Jinja2 в сравнении с другими шаблонизаторами: кто какими альтернативами пользуется, в чем видит сильные и слабые стороны, какой фактор оказывается решающим при выборе движка для конкретного проекта?

Спасибо за внимание, подписавшись на Insight IT можно узнавать о новых материалах одним из первых

Слово epoll сейчас определенно на слуху, в первую очередь благодаря росту популярности неблокирующих HTTP-серверов. При этом мало кто пытается разобраться в том, что, собственно, за ним стоит и почему использующие этот механизм продукты, среди которых достойное место занимают, например, nginx, node.js и Tornado, так значительно выигрывают в производительности у ближайших альтернатив. Хотите копнуть глубже?

О чем пойдет речь?

• epoll является масштабируемой неблокирующей системой уведомления о собятиях ввода-вывода в Linux. В отличии от более старых механизмов, у epoll время срабатывания не зависит от количества открытых файловых дескрипторов.
• epoll используется для обработки событий неблокирующих TCP-сокетов, операционная система оповещает приложение когда один из сокетов «под наблюдением» готов получить или отправить сообщение. В традиционном же подходе на каждый сокет выделяется поток выполнения (thread), который блокируется до возвращения обращения к соответствующему сокету.

Что это дает?

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

Обратная сторона медали

• Потоки выполнения в блокирующей модели имеют относительно короткий жизненный цикл и рано или поздно освобождают выделенную им память, процесс обработки неблокирующих соединений живет существенно дольше и намного более уязвим для утечек памяти.
• Использование одного системного процесса без пула потоков выполнения ограничивает приложение использованием лишь одного процессорного ядра, что делает такой подход менее пригодным для приложений, в значительной мере использующих вычислительные ресурсы. В большинстве же случаев приемлемым решением является запуск нескольких одинаковых копий приложения на одном сервере по количеству процессорных ядер.
• Ошибки в коде могут негативно повлиять на работу всего процесса приложения, в то время как в блокирующей модели потоки выполнения обычно достаточно изолированы друг от друга.

На пальцах

Вернемся к изначальному вопросу статьи: Как работает epoll? Давайте попробуем разобрать на простом примере.

Представьте себе пиццерию (физический сервер). Вы (приложение или HTTP-сервер) получаете заказы (обращения на сокет, например HTTP-запрос) на выпечку пиццы (ответы на обращение, например HTML-документы). Есть два сценария, по которым можно их обрабатывать.

Блокирующий (традиционный)

Вы принимаете заказ, ставите пиццу в печь (системные ресурсы, в.т.ч. оперативная память, необходимые для обработки запроса) и непрерыано наблюдаете за тем как пицца печется. Как только пицца готова — вы берете её и отдаете в руки заказчику (источник заказа, например браузер), после чего принимаете следующий заказ. При необходимости можно нанять помощников (потоки выполнения, threads), чтобы следить за выпеканием пицц.

Вы ограничены как количеством печей, так и количеством помощников, которые могут поместиться в вашей пиццерии.

Неблокирующий (epoll и аналоги)

Вы принимаете заказ, ставит пиццу в печь и ставите таймер (операционная система посредством epoll), чтобы узнать когда пицца испечется. После чего Вы возвращаетесь к приему заказов. Как только прозвенел таймер — Вы идете к соответствующей печи, достаете пиццу и отдаете заказчику, после чего снова возвращаетесь к приему заказов.

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

Заключение

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

Буду рад услышать дополнения и поправки в комментариях, до новых встреч!

Эта заметка является небольшим «криком души», прошу совета у постоянных читателей. Только что вот получил письмо о том, что некий модератор Википедии под псевдонимом bezik решил удалить все упоминания Insight IT с этого небезизвестного интернет-ресурса, долгие годы находившиеся в топ3 источников новых читателей.

Чуть меньше года назад аналогичная история приключилась и с Хабром, где у меня при сильно положительной карме отправили «навечно в черновики» все посты и на несколько месяцев отправили в бан. На хабре модераторы анонимны, так что так и не выяснил кого за это все благодарить.

В итоге при довольно солидной базе подписчиков я теряю основные источники новых читателей… Казалось бы пишешь стоящий контент, люди интересуются, благодарят, а достаточно лишь одного человека, которому неоправданно выдали полномочия и которому не захотелось разбираться в значимости материала, и на ресурсе-источнике можно смело ставить крест. Как думаете, какие есть варианты решения или предотвращения подобных ситуаций?

Хочется верить, что не все так печально и в социальных сетях и поисковых системах меня не забанят в обозримом будущем, но все же ими едиными сыт не будешь. Буду благодарен за любую помощь в поиске новых источников аудитории или, возможно, в решении ситуаций с Хабром и Википедией. Спасибо!

UPDATE: В результате дискуссии в комментариях у Insight IT появилась своя страничка на Google+, добро пожаловать!

На сегодняшний день ассортимент решений для хранения данных очень широк: от встраиваемых СУБД до кластерных распределенных систем. SQL перестал быть стандартом де-факто для доступа к данным, а альтернативные решения давно переросли примитивные хранилища пар ключ-значение. Сегодня я хочу вкратце рассказать об одном из таких решений, продукте, который нашел свое место во многих моих проектах за последние годы, Redis.

 О чем пойдет речь?

Прежде чем вдаваться в детали, давайте разберемся чем по сути является главный герой этого поста?

• Redis предлагает пять фиксированных примитивных структур данных, но не дает возможности создавать свои (по принципу таблиц или букетов).
• Redis держит все данные в памяти, но имеет гибко настраиваемый механизм сохранения их копии на диск.
• Redis реализован в виде однопоточного демона на C, общающегося по собственному текстово-бинарному TCP-протоколу, но без намеков на многопоточность и кластеризацию.

Этих трех тезисов еще не достаточно, чтобы хорошо прочувствовать особенности и основные варианты использования Redis, но общая картинка уже начинает складываться. Интересно? Двигаемся дальше!

Модель данных

Модель данных у Redis основана на принципе пар ключ-значение, с той лишь разницей, что значение может быть сложной структурой с дополнительными операциями. Пройдемся по каждой:

• Строка: в самом случае значением может быть просто последовательность каких-то байт, о содержании которых Redis ничего не знает и знать не должен. По тому же принципу работает, скажем, memcached и набор основных операций тот же: get/set/del и их групповые аналоги mget/mset. Здесь же стоит упомянуть про возможность атомарного инкремента и получения списка имеющихся в системе ключей.
• Словарь/хэш: аналогичная структура данных есть во многих языках программирования, так что принцип наверняка знаком — за идентификатором (в языках программирования — переменной, а в Redis — ключом) стоит не одно значение, а подмножество пар ключ-значение с механизмом доступа, аналогичным основному множеству ключей в Redis. По сути команды, работающие со словарями отличаются от работающих со строками наличием первого параметра с идентификатором словаря и буквой h в начале, например hget, hset. Если воспринимать словарь как подмножество пар ключ-значений тяжело, то можно рассматривать их как строки с полями, то есть если в словарях использовать одинаковый набор внутренних ключей, то можно добиться абстракции на подобии таблиц в РСУБД.
• Набор: используется для хранения множества неотсортированных уникальных значений, предоставляя механизмы для работы с этими данными (команды на букву s), в частности стоит обратить внимание пересечение и объединение множеств. На практике же неотсортированные наборы удобно использовать для проверки уникальности каких-то данных, скажем e-mail'ов зарегистрированных пользователей, время операции проверки наличия значения в наборе не зависит от общего количества значений в наборе, аналогичным свойством обладает и операция подсчета количества значений в наборе…
• Отсортированный набор: сортировка в наборах осуществляется путем присваивания каждому значению условного ранга (score) в виде целого числа; значения в наборе будут автоматически храниться в порядке от минимального к максимального ранга. Доступные операции (на букву z) позволяют делать выборки значений с определеным диапазоном рангов или по индексу (если представить отсортированный набор в виде массива или списка), узнавать ранг и индекс по значению. Выглядит замысловато, но на практике довольно удобно. Их можно использовать в роли индекса в терминах РСУБД: например, в отсортированном наборе можно хранить идентификаторы пользователей, назначая в качестве ранга их возраст — в результате можно очень быстро делать выборки пользователей по возрасту, после чего по идентификаторам получать более подробную информацию о каждом, скажем командой mget или как-то еще.
• Список: в отличии от отсортированных наборов в списках значения хранятся просто по порядку. Операции (на букву l) позволяют эффективно добавлять и получать значения в начало, конец и по индексу (порядковому номеру), а также работать с последовательными участками списка. В результате на программном уровне можно реализовать любые абстракции работы с последовательностями, в том числе стек и любые очереди.

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

В кажом сервере Redis может содержаться до 16 независимых пространств ключей, которые принято называть базами данных.

Сохранность данных

В Redis доступны четыре основных стратегии для сохраненния полученных:

• Хранить только в памяти: по сути Redis из персистентной базы данных превращается в кэширующий сервер. Производительность в таком режиме максимальна и сравнима с часто используемым в этой роли memcached, в некоторых ситуациях его даже превосходит; плюс не забываем про более продвинутую структуру данных. Минус с высоким риском потери данных — очевиден, за производительность надо осознанно платить.
• Периодически сохранять на диск: (по-умолчанию) момент, когда Redis решает сделать очередную копию (snapshot) данных на диске, зависит от времени создания предыдущей и количества измененных ключей. При настройках по-умолчанию это случается раз в несколько минут (1-15).
• Лог транзакций: если потеря нескольких минут изменений данных неприемлема для приложения, есть опция синхронной записи каждого изменения в специальный append-only файл (лог).
• Репликация: в Redis поддержка репликации достаточно примитивна — каждому серверу можно указать мастера (командой slaveof или одноименной строкой в конфигурации), все изменения на мастере будут воспроизводиться и на подчиненном. Это можно использовать для построения более сложных схем сохранности данных, например: мастер работает в режиме «только в памяти», а подчиненный — в режиме «лог транзакций». У каждого сервера может быть только один мастер, но неограниченное количество подчиненных.

Масштабируемость

Как следует из третьего тезиса в начале этой статьи, ситуация печальна, как таковой поддержки масштабируемости в Redis нет, а клиенты умеют подключаться только к одному серверу. В сети давно ходят слухи о неком проекте Redis Cluster, который призван решить эту проблему, но пока еще не дорос до чего-то пригодного для использования в боевых условиях.

Но все не так плохо как кажется, этот проект предоставляет достаточно возможностей, чтобы масштабировать систему своими руками именно так, как представляется нужным конкретному проекту. Сразу хочется сказать, что не стоит бросаться воплощать все нижеизложенное в жизнь, если даже по самым оптимистичным прогнозам суммарный объем данных в Redis в вашем проекте не будет превышать 50-100 гигабайт. Какой-либо универсальной реализации нижеизложенного не существует, так как большая часть манипуляций осуществляется на стороне клиента, что потребовало бы реализации на всех возможных языках программирования.

Давайте пройдемся по основным приемам, которые можно реализовать на любом языке программирования с используем базового клиента Redis.

• Много процессов Redis на одном физическом сервере: процессы Redis однопоточны и если ваш проект работает на физическом не антикварном оборудовании, то для использования всех ресурсов процессора потребуется запускать несколько процессов Redis на разных портах. Еще одна особенность, подталкивающая в пользу такого подхода — существенно большее потребление оперативной памяти 64-битной сборкой Redis, так как удваивается длина указателей, которых используется очень большое количество. 32-битная же сборка позволяет держать в памяти лишь примерно 3  гигабайта данных. Альтернатива: много виртуальных машин с 1 ядром и 3 гигабайтами оперативной памяти.
• Распределение данных по ключам: так или иначе, у всех данных в Redis есть уникальный идентификатор, от которого можно взять хэш, а от него взять остаток от деления на константу — получим номер сервера в статичном списке ip:port, на котором нужную структуру данных можно найти. На клиенте держится по соединению на каждый используемый сервер Redis, выбирается нужный и отправляется запрос.
• Создание виртуальных баз данных (ВБД): у предыдущего подхода есть масса недостатков, связанных с перераспределением данных. Эту ситуацию можно решить введя понятие виртуальных БД, то есть брать в качестве константы для остатка не реальное число серверов, а достаточно большую степень двойки, скажем 65536 (будет удобно удваивать количество реальных серверов) — что далее будет считаться номером ВБД (который иногда удобно приписывать к ключу через разделитель). Виртуальные же базы необходимо по произвольному алгоритму распределить по запущенным процессам Redis и в простейшем случае указать это соотношение в конфигурационных файлах приложений-клиентов.
• Маршрутизатор по виртуальным базам данных: в предыдущем приеме подразумевалось, что распределение виртуальных БД по серверам фиксированное, но очень скоро захочется иметь механизм для перераспределения данных в кластере. Это может потребоваться при неравномерности нагрузки (к какой-то ВБД существенно больше запросов, чем к остальным) или, опять же, при расширении парка используемых серверов. Для реализации потребуется некое общее хранилище для информации о физическом расположении ВБД, это может быть как отдельный «особый» процесс Redis, так и какая-то встраиваемая СУБД, расположенная в общедоступном месте, есть и другие варианты. Добавление такой прослойки для определения расположения данных немного увеличит время отклика, но позволит более гибко перераспределять данные.
• Перераспределение данных: есть два подхода к переносу ВБД между двумя процессами Redis.
• В лоб: некий процесс последовательно читает данные с сервера-источника и записывает в сервер-назначение, после окончания процесса отмечает в маршрутизаторе ВБД что данные теперь на новом сервере, удаляет данные на  сервере-источнике. Просто в реализации, не особо быстро при больших объемах.
• Через репликацию: существенно более хитрый вариант, о котором я услышал на одной из конференций от представителей команды Skype. Заключается в создании процесса, реализующего протокол репликации Redis с обоих сторон. То есть для сервера-источника он представляется подчиненным, а для сервера-назначения — мастером, при этом пропуская через себя только те ключи, которые относятся к нужной ВБД (требуется, чтобы её номер содержался в ключе). По окончании первичной репликации также отмечает в маршрутизаторе, что ВБД в новом месте. В протоколе репликация есть опция передачи начальной части данных бинарным файлом — этот вариант будет максимально быстрым, но потребуется разобраться с его форматом. Ребята из Skype обещали опубликовать в opensource свою реализацию этой схемы, но я её пока не видел…
• Использование репликации: помимо увеличения максимального объема данных, стоит задумываться и о надежности системы, а также сохранности данных. Как работает репликация мы уже обсуждали, как добавить её к одной из вышеизложенных схем — дело техники. Самый простой вариант — хранить в маршрутизаторе или конфигурационном файле два физических адреса для каждой ВБД, основной и запасной. Запасной же настраивать как подчиненного с логом транзакций, а основной как мастера в режиме кэша или с очень редким созданием копии на диске. Сложные варианты репликации можно «позаимствовать» у изначально-распределенных СУБД вроде Cassandra или Riak, например можно хранить первую копию по указанному в маршрутизаторе адресу, вторую по адресе, который указан для следующей ВБД, а третью — для через-следующей, но в такой схеме нельзя будет использовать репликацию напрямую, потребуется «прослойка», аналогичная описывавшейся в перераспределении данных через репликацию.

Бонусы

В дополнение хотелось бы упомянуть три интересные особенности Redis, не совсем относящиеся к затрагивавшимся ранее вопросам, но определенно заслуживающих внимания:

• Транзакции: клиент может отправить команду multi, что означает начало транзакции. Все последующие команды не изменят данные, пока сервер не получит команду exec, либо можно отменить транзакцию командой discard.
• Публикация и подписка на сообщения: помимо стандартного использование в роли хранилища данных, Redis может использоваться и как очередь сообщений. Клиент может включить режим ожидания сообщений по определенному ключу/каналу (команды доступа к данным в этом режиме недоступны), а также отправлять произвольные сообщения всем, кто подписан на определенный канал.
• Мониторинг: к каждому процессу Redis можно подключиться для просмотра всех поступающих команд или только тех, которые выполнялись больше N микросекунд.

Заключение

Redis — определенно заслуживающий внимания opensource проект. Благодаря использованию нестандартных решений, он с одной стороны стал очень гибкой системой хранения данных, а с другой — ограничил круг проектов, где ему найдется место в стеке технологий.

Изложенные мной, Иваном Блинковым, варианты использования и особенности Redis являются лишь небольшой частью того, что может быть реализовано с его помощью. Идеи по использованию реализованных в Redis структур данных в конкретных проектах порой оказываются очень неожиданными и практически нереализуемыми средствами большинства более консервативных СУБД.

Успехов в освоении современных технологий!

Для разработки новостных разделов и новой социальной сети, требуется удаленный разработчик Django.
Основная цель — сделать качественный и интересный ресурс, с продвинутым интерфейсом.

Требования

• Опыт работы с Django, не менее 2-х лет
• Опыт кастомизации административного интерфейса Django
• Опыт написания автоматизированных тестов
• Опыт работы с библиотекой jQuery не менее года
• Опыт проектирования  и работы с СУБД MySql
• Желание разбираться в чужом коде
• Опыт использования SVN
• Опыт использования Ajax

Задачи

• Реализация серверной части
• Разработка GUI на jQuery на основе готовых компонент
• Разработка jQuery компонент
• Расширение  и кастомизация Django Admin

Условия

• Удаленная работа не менее 20 часов в неделю
• Оплата от 400 рублей в час, зависит от уровня программиста
• Оформления в штат нет, но проект долгосрочный

Резюме отправлять на vadim@vestlite.com

P.S.: В связи с возросшим спросом на размещение вакансий на Insight IT, стоимость услуги существенно возрасла, теперь подобые посты будут появляться реже.

Напомню, что Plenty of Fish — один из самых популярных в мире сайтов знакомств, созданный одним человеком и работающий на всего нескольких серверах и коммерческих технологиях. На Insight IT два года назад уже была подробная статья о технической реализации проекта, сегодня же я хочу  поделиться свежей информацией о том, как проект развивается.

О проекте

• Долгое время, около 7 лет, проект полностью разрабатывался и поддерживался исключительно Маркусом, его создателем
• Первый архитектор баз данных был нанят в июле 2011 года
• На сегодняшний день команда составляет около 5 сотрудников
• Используется стек технологий от Microsoft, а также Akamai в роли CDN
• Расходы на техническое обеспечение проекта составляют порядка 70 тысяч долларов в месяц
• Ежегодные доходы от рекламы измеряются миллионами долларов

Статистика на ноябрь 2011

• 6 миллиардов просмотров страниц
• 32 миллиарда просмотров изображений, пики до 22 тыс. в секунду, по ночам около 7 тыс.
• 30 миллиардов обращений к серверам мгновенного обмена сообщениями
• Более 6 миллионов пользователей заходят на сайт каждое воскресенье
• Количество веб-серверов увеличилось с 2 до 11, что обеспечивает практически двухкратный запас по используемым ресурсам

Выводы

Чтобы проект был очень прибыльным для своих создателей, не всегда стоит торопиться стать большой компанией. Быть маленьким тоже выгодно:

• минимальные расходы на зарплаты, офис и техническое обеспечение,
• востребованный продукт благодаря способности быстро подстраиваться под потребности рынка,
• отсутствие необходимости делиться существенной частью прибыли с инвесторами,
• достаточно простая архитектура и техническая реализация,
• отсутствие потерь времени на бюрократию и совещания.