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

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

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

hotshot2cg myprog.hotshot > myprog.calltree

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

kcachegrind myprog.calltree

Однако MySQL не был бы MySQL, если бы не какие-нибудь приколы на пути. Читаем раздел 16.3.1.29 документации: триггеры на слейве выполняются только при использовании STATEMENT-based репликации, при использовании ROW-based репликации они выполняются на мастере. ROW-based репликация – одно из нововведений 5.1, при котором на слейв передаются не запросы (текст запроса), измененный в БД записи (подробнее см. раздел 16.1.2). Но это было бы еще полбеды – попробовал, увидел, что триггеры не выполняются, и пошел разбираться. Однако в MySQL придумали еще режим репликации MIXED: при этом сервер сам переключается между STATEMENT и ROW-based репликацией (я не нашел, по какому условию). Далее, в версиях MySQL от 5.1.12 до 5.1.29 режимом репликации по умолчанию выбирается как раз MIXED. Как вы уже догадываетесь, в MIXED-режиме триггеры на слейве то выполняются, то нет, при этом внешне это совершенно незаметно. Так прекрасно работавший слейв в один прекрасный день вдруг перестает поставлять обновления в очередь, хотя сам по себе слейв не отстал и содержит все данные.

Итого, несколько часов на поиск проблемы, работа по пересинхронизации данных во внешней системе… Спасибо, MySQL!

Кратко: чтобы триггеры на слейве всегда выполнялись, надо добавить в my.cnf (на мастере):

[mysqld]
binlog-format=STATEMENT

Введение

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

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

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

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

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

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

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

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

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

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

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

Презентация

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

• nginx (главный proxy), который раздает трафик в
• haproxy (ради возможности балансировать по нагрузке), который распределяет нагрузку по нескольким webapp-серверам
• с 16-ю mongrelами на каждом

Проблемы:

1. «Утекающая» память, периодический out of memory на серверах, лечится только перезапуском mongrelов.
2. Запросы, занимающие десятки секунд из-за неверной балансировки (в нагруженный mongrel все-таки попадает несколько «тяжелых» запросов).
3. Сложность управления кластером монгрелов – постоянные проблемы при перезапуске, «не стартующие» mongrelы и т.п.

Новая конфигурация:

• nginx (proxy) остался
• Phusion Passenger + Ruby Enterprise Edition на каждой машине.

Результат:

Комментарий: переход на Phusion Passenger на Week 39, объем занятой памяти – это белая область на графике, растущая сверху вниз. До перехода на Passenger объем свободной памяти стремительно уменьшался, иногда доходя до нуля, после перехода остается более-менее стабильным. Использование CPU осталось на прежнем уровне (как и ожидалось).

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

Так что если вы еще не переключились, мы идем к вам

P.S. Отдельное спасибо glebpom за подсказку.

На HighLoad++-2009 буду выступать с докладом Twisted Framework – фреймворк для написания сетевых приложений в Python. Конференция будет проходит 12-13 октября 2009 г. в Инфопространстве. Приглашаю всех желающих!

Тезисы доклада:

1. Архитектура сетевых сервисов, нити, процессы, асинхронный ввод-вывод.
2. Тенденции в изменении структуры нагрузки на сетевые сервисы: AJAX, Comet/BOSH, клиент-серверная архитектура, проблема 10k.
3. Асинхронный ввод-вывод и параллельное программирование: достоинства и недостатки. Поддержка локального контекста, deadlock, lock contention, starvation, масштабирование на многоядерную архитектуру и т.д.
4. Twisted Framework с высоты птичьего полета.
5. Аналоги Twisted в других языках программирования: Ruby — EventMachine, Perl — POE.
6. Центральная концепция Twisted: Deferred — как сохранить контекст выполнения в однопоточном коде с асинхронным вводом-выводом.
7. Аналогии между последовательным кодом и асинхронным кодом с использованием Deferred.
8. Twisted и использование нитей: модель worker, «оборачивание» legacy кода.
9. Реальные примеры Twisted-приложений, цифры, факты, архитектурные решения, преимущества и недостатки:
   • pyFMS — сервер RTMP-вещаний, нагрузка, оптимизация Python-кода;
   • MDC-сервер, масштабирование;
   • Qik Push Engine, обслуживание тысяч клиентов, тестирование клиентов.
10. Качество кода Twisted, модель разработки, перспективы развития проекта, экосистема Twisted. Что может Twisted дать моему проекту?

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

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

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

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

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

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

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

Ответ:

Content-Type: text/json 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замечания:

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

Reference JS-клиент

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

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

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

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

prototype.js

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

deferred.js

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

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

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

core.js

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

api.js

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

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

events.js

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

view.js

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

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

updater.js

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

usercache.js

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

easy_install fmspy

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

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

twistd -n fmspy

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

Примеры

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

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

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

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

Ссылки:

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

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

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

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

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

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

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

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

Через еще несколько минут возник вакуум информации, где горит? Что горит? По виду столба пламени можно было догадаться, что горит газ, но знать наверняка вряд ли было возможно. Есть ли угроза для нас, для нашего дома? По моим первым предположениям, что горит прямо за лесом, в случае, если огонь перекинется на лес, нам надо было будить нашу маленькую дочку и уезжать отсюда. По телевидению в новостных каналах тишина, никакой информации. Помогает поиск по блогам, уже через несколько минут первая информация – пожар где-то внутри МКАД, в районе Мичуринского проспекта. Становится чуточку легче. Спасибо вам, блоггеры!

Еще через несколько минут около часа ночи прекращает работать интернет (Стрим), с ним погибает и телевидение №1 (Стрим-ТВ). Тут же умирает и телевидение №2 (кабельное в доме). Интересно, как они связаны? По радио тишина. Остается последний источник информации, сотовый телефон, ленты новостных агентств. Через их сайты удается узнать какую-то информацию, действительно пожар около поста ДПС на пересечении Мичуринского и МКАД. Всё, можно спать.

FFmpeg, собранный с libmp3lame (для кодирования mp3) версии 3.98, сообщает следующее:

lame: output buffer too small (buffer index: 9404, free bytes: 388)

Он считает это фатальной ошибкой, завершается:

Audio encoding failed

Лечится downgrade libmp3lame до версии 3.97.

Проверено на ArchLinux.

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

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

Для желающих поехать в помощь трек пути от M7 к дому отдыха:

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

Суздаль

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

Сам Суздаль производит впечатление странное. Полуразрушенный, загаженный, живущий как будто бы производством медовухи и приемом туристов. Город замер и заморозился лет на сто. Но почему же столько мусора? Почему все разваливается, заборы заваливаются? Убрать мусор, всё подкрасить, помыть, положить новый асфальт. Было бы фантастическое для туристов место. А так – стыдно.

Село Воскресение, место гибели Гагарина, Киржач, Андреевское

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

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

Дорога Покров-Киржач неплохого качества, малозагруженная, петляет по лесам и холмам, сплошное удовольствие! Сам Киржач – небольшой городок. В нем есть действующий женский монастырь, несколько церквей. Хороший ресторан «Шерна». В нем чувствуется атмосфера маленького провинциального города, нет ощущения «мертвого» города, как в Суздале.

Последний пункт нашего путешествия – усадьба «Андреевское» Воронцовых и Воронцовых-Дашковых, XVIII век. Для этого возвращаемся на M7, едем до поворота на «детский санаторий», далее по дороге еще около 7 км, на дороге незаметные четыре лежачих полицейских, лучше ехать за местной машиной. В усадьбе сегодня располагается детский санаторий «Болдино». Сама усадьба сохранилась, видимо, практически полностью, церковь, приусадебный парк. Здание обветшало, требуется ремонт или реставрация, еще остался дух дворянской усадьбы, хотя и совсем немного его осталось.

Opel Astra 1.6 (105 л.с.) хэтчбек 5-дверный, цвет метро (темно-синий), 2006 г. выпуска (август), пробег 71 тыс. км.

Комлектация Cosmo, биксенон, парктроник, регулировка водительского сиденья в 6-и направлениях, подлокотник, 17″ колеса, система QuickHeat, задние электростеклоподъемники, салон кожа+ткань, магнитола MP3, сигнализация, европейская сборка. (Всё заводское, заказывалась комплектация).

Я – единственный владелец, все ТО у официального дилера (Genser), машина не кредитная.

Из дефектов: скол краски на капоте (ржи нет, требуется покраска летом), маленькая царапина на панели (в салоне), пара мелких дефектов на сиденьях (курил .

Старая фотка машины, лучше пока фоток нет, на фотке капот «задран», этого уже давно нет

SOLD! Продано… Прощай, Марта! Надеюсь, ты достанешься хорошему человеку…

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

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

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

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

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

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

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

Нужен python и setuptools:

easy_install spamfighter

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

spamfighter-create ~/spamfighter

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

Что дальше?

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

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

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

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

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

def callback(result):
    ...

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

def errback(failure):
    ...

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

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

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

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

Deferred в квадрате

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Memcached и MemcacheDB в данной статье рассматриваются вместе, потому что имеют общий интерфейс доступа и логика работы большей части структур данных будет одинаковой, далее будем называть их просто «memcached». Зачем нам нужно хранить структуры данных в memcached? Чаще всего для распределенного доступа к данным из разных процессов, с разных серверов и т.п. А иногда для решения задачи хранения данных достаточно интерфейса, предоставляемого MemcacheDB, и необходимость в использовании СУБД отпадает.

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

Примеры кода будут написаны на Python, в них будет использоваться следующий интерфейс доступа к memcached:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

class Memcache(object):
    def get(self, key):
        """
        Получить значение ключа.
 
        @param key: ключ
        @type key: C{str}
        @return: значение ключа
        @raises KeyError: ключ отсутствует
        """
 
    def add(self, key, value, expire=0):
        """
        Установить значение ключа, если он еще не существует.
 
        @param key: ключ
        @type key: C{str}
        @param value: значение ключа
        @param expire: "срок годности" ключа в секундах (0 - бесконечно)
        @type expire: C{int}
        @raises KeyError: ключ уже существует
        """
 
    def incr(self, key, value=1):
        """
        Увеличить на единицу значение ключа.
 
        @param key: ключ
        @type key: C{str}
        @param value: инкремент
        @type value: C{int}
        @return: новое значение ключа (после увеличения)
        @rtype: C{int}
        @raises KeyError: ключ не существует
        """
 
    def append(self, key, value):
        """
        Добавить суффикс к значению существующего ключа.
 
        @param key: ключ
        @type key: C{str}
        @param value: суффикс
        @raises KeyError: ключ не существует
        """
 
    def delete(self, key):
        """
        Удалить ключ.
 
        @param key: ключ
        @type key: C{str}
        """

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

1
2
3
4
5
6
7
8
9

class MemcacheObject(object):
    def __init__(self, mc):
        """"
        Конструктор.
 
        @param mc: драйвер memcached
        @type mc: L{Memcache}
        """
        self.mc = mc

Блокировка

Задача

Блокировка (mutex, или в данной ситуации скорее spinlock) – это не совсем структура данных, но она может быть использована как «кирпичик» при построении сложных структур данных в memcached. Блокировка используется для исключения одновременного доступа к некоторым ключам, возможности блокировки отсутствуют в API memcached, поэтому она эмулируется с помощью других операций.

Итак, блокировка определяется своим именем, работает распределённо (то есть из любого процесса, имеющего доступ к memcached), имеет автоматическое «умирание» (на случай, если процесс, поставивший блокировку, не сможет её снять, например, по причине аварийного завершения).

Операции над блокировкой:

• попробовать заблокироваться (try-lock);
• разблокировать (unlock).

Решение

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

class MCLock(MemcacheObject):
    def __init__(self, mc, name, timeout=5):
        """
        Конструктор.
 
        @param name: имя блокировки
        @type name: C{str}
        @param timeout: таймаут аварийного снятия блокировки (секунды)
        @type timeout: C{int}
        """
        super(MCLock, self).__init__(mc)
        self.key = 'lock_' + name
        self.locked = False
        self.timeout = timeout
 
    def try_lock(self):
        """
        Попробовать заблокироваться.
 
        @return: удалось ли заблокироваться?
        @rtype: C{bool}
        """
        assert not self.locked
        try:
            self.mc.add(self.key, 1, self.timeout)
        except KeyError:
            return False
 
        self.locked = True
        return True
 
    def unlock(self):
        """
        Снять блокировку.
        """
        assert self.locked
        self.mc.delete(self.key)
        self.locked = False

Обсуждение

Корректность работы блокировки основывается на операции add, которая гарантирует что ровно один процесс сможет «первым» установить значение ключа, все остальные процессы получат ошибку. Приведенный выше класс может быть обернут более удобно, например, для with-обработчика Python. Более подробно вопрос блокировок обсуждался в посте про одновременное перестроение кэшей.

Атомарный счетчик

Задача

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

Тип данных: целое число.

Начальное значение: ноль.

Операции:

• увеличить значение счетчика на указанное значение;
• получить текущее значение счетчика.

Решение

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

class MCCounter(MemcacheObject):
    def __init__(self, mc, name):
        """
        Конструктор.
 
        @param name: имя счетчика
        @type name: C{str}
        """
        super(MCCounter, self).__init__(mc)
        self.key = 'counter' + name
 
    def increment(self, value=1):
        """
        Увеличить значение счетчика на указанное значение.
 
        @param value: инкремент
        @type value: C{int}
        """
        while True:
            try:
                self.mc.incr(self.key, value)
                return
            except KeyError:
                pass
 
            try:
                self.mc.add(self.key, value, 0)
                return
            except KeyError:
                pass
 
    def value(self):
        """
        Получить значение счетчика.
 
        @return: текущее значение счетчика
        @rtype: C{int}
        """
        try:
            return self.mc.get(self.key)
        except KeyError:
            return 0

Обсуждение

Реализация счетчика достаточно очевидная, самый сложный момент – это «вечный» цикл в методе increment. Он необходим для корректной инициализации значения счетчика в условиях конкурентного доступа к нему. Если операция incr завершилась ошибкой отсутствия ключа, нам необходимо создать ключ счетчика, но этот код могут одновременно выполнять несколько процессов, тогда одному из них удастся add, а второй получит ошибку и инкрементирует уже созданный счетчик с помощью incr. Зацикливание невозможно, т.к. одна из операций incr или add должна быть успешной: после создания ключа в memcached операция incr будет успешной всё время существования ключа.

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

1. memcached не хватает памяти для размещения других ключей;
2. процесс memcached аварийно завершился (сервер «упал»).

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

Счетчик посетителей

Задача

Необходимо вычислить количество уникальных обращений к сайту в течение некоторого периода T. Например, T может быть равно 5 минутам. Пусть мы можем сказать, когда было последнее обращение данного посетителя к сайту – более T минут назад или менее (то есть является ли оно уникальным в течение периода T).

Операции над счетчиком:

• увеличить значение счетчика на единицу (обращение уникального в течение периода T посетителя);
• получить текущее число посетителей.

Решение

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

def time():
    """
    Текущее время в секундах с любого момента времени (например, UNIX Epoch).
 
    @return: текущее время в секундах
    @rtype: C{int}
    """
 
class MCVisitorCounter(MemcacheObject):
    def __init__(self, mc, name, T):
        """
        Конструктор.
 
        @param name: имя счетчика
        @type name: C{str}
        @param T: период счетчика, секунды
        @type T: C{int}
        """
        super(MCVisitorCounter, self).__init__(mc)
        self.keys = ('counter' + name + '_0', 'counter' + name + '_1')
 
    def _active(self):
        """
        Получить индекс текущего счетчика.
 
        @return: 0 или 1
        """
        return 0 if (time() % (2*T)) < T else 1
 
    def increment(self):
        """
        Увеличить значение счетчика.
        """
        active = self._active()
        while True:
            try:
                self.mc.incr(self.keys[1-active], 1)
                return
            except KeyError:
                pass
 
            try:
                self.mc.add(self.keys[1-active], 1, 2*T)
                return
            except KeyError:
                pass
 
    def value(self):
        """
        Получить значение счетчика.
 
        @return: текущее значение счетчика
        @rtype: C{int}
        """
        try:
            return self.mc.get(self.keys[self._active()])
        except KeyError:
            return 0

Обсуждение

Основная структура работы со счетчиком в memcached в данной задаче повторяет решение задачи атомарного счетчика. Базовая идея – использование теневого и текущего счетчика: теневой счетчик получает обновления (увеличивается), а текущий используется для получения значения числа посетителей (его значение было накоплено, когда она был теневым). Каждый период T текущий и теневой счетчик меняются местами. Ключ теневого счетчика создается со сроком годности 2*T секунд, то есть его время жизни – T секунд, пока он был теневым (и увеличивался), и Т секунд, пока его значение использовалось для чтения. К моменту того, как этот ключ снова станет теневым счетчиком, он должен быть уничтожен memcached, т.к. срок его годности истек. Идея теневого и текущего счетчика напоминает, например, двойную буферизацию при выводе на экран в играх.

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

Описанный подход будет работать корректно только при достаточно большом количестве посетителей, когда временной интервал между очередной сменой значения функции _active() и обращением к функции increment() будет как можно меньше. То есть когда increment() вызывается часто, то есть когда посетителей достаточно много, например, 1000 человек при периоде Т=3 минуты. Иначе создание и уничтожение ключей не будет синхронизировано с моментом смены значения _active() и начнут пропадать посетители, накопленные в теневом счетчике, который будет уничтожен в процессе накопления значений и создан заново. В этой ситуации его время жизни 2T будет «сдвинуто» относительно моментов 0, T функции time() % (2T). В силу того, что memcached рассматривает срок годности ключей дискретно относительно секунд (с точностью не более одной секунды), любой сдвиг времени жизни ключа может составлять 1,2,…,T-1 секунду (отсутствие сдвига – 0 секунд). Дискретность срока годности означает, что если ключ был создан в 25 секунд 31 миллисекунду со сроком годности 10 секунд, то он будет уничтожен на 35-й (или 36-й) секунде 0 миллисекунд (а не 31-й миллисекунде). Для компенсация сдвига в целое число секунд необходимо исправить строчку 43 примера следующим образом:

43

                self.mc.add(self.keys[1-active], 1, 2*T - time() % T)

Значение счетчика посетителей не изменяется в течение периода времени T, для более приятного отображения можно к значению счетчика при выводе добавить нормально распределенную величину с небольшой дисперсией и математическим ожиданием около 5% от значения счетчика.

Немного более сложный вариант такого счетчика (с интерполяцией во времени), но с точно такой же идеей был описан в посте про атомарность операции и счетчики в memcached.

Лог событий

Задача

Задача этой структуры данных – хранение событий, произошедших в распределенной системе за последние T секунд. Каждое событие имеет момент времени, когда оно произошло, остальное содержимое события определяется логикой приложения.

Операции над логом событий:

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

Решение

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116

def time():
    """
    Текущее время в секундах с любого момента времени (например, UNIX Epoch).
 
    @return: текущее время в секундах
    @rtype: C{int}
    """
 
class Event:
    """
    Событие, помещаемое в лог событий.
    """
 
    def when(self):
        """
        Момент времени, когда произошло событие (секунды).
        """
 
    def serialize(self):
        """
        Сериализовать событие.
 
        @return: сериализованное представление
        @rtype: C{str}
        """
 
    @static
    def deserialize(serialized):
        """
        Десериализовать набор событий.
 
        @param serialized: сериализованное представление одного 
                           или нескольких событий
        @type serialized: C{str}
        @return: массив десериализованных событий
        @rtype: C{list(Event)}
        """
 
class MCEventLog(MemcacheObject):
    def __init__(self, mc, name, timeChunk=10, numChunks=10):
        """
        Конструктор.
 
        @param name: имя лога событий
        @type name: C{str}
        @param timeChunk: емкость одного ключа лога в секундах
        @type timeChunk: C{int}
        @param numChunks: число выделяемых ключей под лог
        @type numChunks: C{int}
        """
        super(MCEventLog, self).__init__(mc)
        self.keyTemplate = 'messagelog' + name + '_%d';
        self.timeChunk = timeChunk
        self.numChunks = numChunks
 
    def put(self, event):
        """
        Поместить событие в лог.
 
        @param event: событие
        @type event: L{Event}
        """
        serialized = event.serialize()
        key = self.keyTemplate % (event.when() // self.timeChunk % self.numChunks)
 
        while True:
            try:
                self.mc.append(key, serialized)
                return
            except KeyError:
                pass
 
            try:
                self.mc.add(key, serialized, self.timeChunk * (self.numChunks-1))
                return
            except KeyError:
                pass
 
    def fetch(self, first=None, last=None):
        """
        Получить события из лога за указанный период (или все события).
 
        @param first: минимальное время возвращаемого сообщения
        @type first: C{int}
        @param last: максимальное время возвращаемого сообщения
        @type last: C{int}
        @return: массив событий
        @rtype: C{list(Event)}
        """
        if last is None or last > time():
            last = time()
 
        if first is None or last < first or 
           (last-first) > self.timeChunk * (self.numChunks-1):
            first = time() - self.timeChunk * (self.numChunks-1)
 
        firstKey = first / self.timeChunk % self.numChunks
        lastKey = last / self.timeChunk % self.numChunks
 
        if firstKey < lastKey:
            keyRange = range(firstKey, lastKey+1)
        else:
            keyRange = range(firstKey, self.numChunks) + range(0, lastKey+1)
 
        keys = [self.keyTemplate % n for n in keyRange]
        result = []
        for key in keys:
            try:
                events = Event.deserialize(self.mc.get(key))
            except KeyError:
                continue
 
            result.extend(filter(lambda e: e.when() >= first and 
                                                e.when() <= last, l))
 
        return result

Обсуждение

Основная идея лога событий – кольцевой буфер, состоящий из numChunks ключей в memcached. Каждый ключ активен (то есть дополняется значениями) в течение timeChunk секунд, после чего активным становится следующий ключ (если активным был последний ключ, эта роль переходит к первому ключу). Полный цикл буфера, т.е. период времени между двумя использованиями одного ключа составляет numChunks * timeChunk секунд, а время жизни каждого ключа – (numChunks - 1) * timeChunk секунд, таким образом при любом сдвиге времени создания ключа по модулю timeChunk к моменту времени следующего использования ключ гарантированно будет уничтожен. Таким образом, ёмкость лога событий (или период времени, за который сохраняются события) составляет (numChunks - 1) * timeChunk секунд. Такое разбиение лога на ключи позволяет при получении событий из лога вынимать лишь те ключи, которые соответствуют интересному нам временному отрезку.

Выбор параметров timeChunk и numChunks зависит от применения лога событий: сначала определяется желаемый срок хранения событий, затем по частоте событий выбирается такое значение timeChunk, чтобы размер каждого ключа лога событий был относительно небольшим (например, 10-20Кб). Из этих соображений можно найти значение и второго параметра, numChunks.

В примере используется некоторый класс Event, который обладает единственным интересным для нас свойством – временем, когда произошло событие. В методе put лога событий предполагается, что событие event, переданное в качестве параметра, произошло «недавно», то есть с момента event.when() прошло не более чем (numChunks - 1) * timeChunk секунд (емкость лога). При работе put вычисляется ключ, в который должна быть помещена информация о событии, в соответствие с его временной меткой. После этого с помощью уже знакомой по предыдущим примерам техники ключ либо создается, либо к значению уже существующего ключа дописывается сериализованное представление события.

Метод fetch вычисляет потенциальный набор ключей лога, в которых могут находиться события, произошедшие во временной интервал от first до last. Если временные рамки не заданы, last считается равным текущему моменту времени, а first – моменту времени, отстоящему от текущего на емкость лога. Набор ключей вычисляется с учетом кольцевой структуры метода, после чего выбираются соответствующие ключи, десериализуются последовательно записанные в них события и проводится дополнительная фильтрация на попадание в отрезок [first, last].

Приведенная выше сигнатура метода позволяет последовательными обращениями выводить новые события из лога:

1. Первый раз вызывается events = fetch(). Вычисляется lastSeen как max(events.when()).
2. Все последующие обращения выглядят следующим образом: events = fetch(first=lastSeen), при этом lastSeen каждый раз перевычисляется.

Массив

Задача 1

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

Операции над массивом:

• изменить массив (редкая операция);
• получить массив целиком (частая операция).

Решение 1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

def serializeArray(array):
    """
    Сериализовать массив в бинарное представление.
    """
 
def deserializeArray(str):
    """
    Десериализовать массив из бинарного представления.
    """
 
class MCArray1(MemcacheObject):
    def __init__(self, mc, name):
        """
        Конструктор.
 
        @param name: имя массива
        @type name: C{str}
        """
        super(MCArray1, self).__init__(mc)
        self.lock = MCLock(name)
        self.key = 'array' + name
 
    def fetch(self):
        """
        Получить текущее значение массива.
 
        @return: массив
        @rtype: C{list}
        """
        try:
            return deserializeArray(self.mc.get(self.key))
        except KeyError:
            return []
 
    def change(self, add_elems=[], delete_elems=[]):
        """
        Изменить значение массива, добавив или удалив из него
        элементы.
 
        @param add_elems: элементы, которые надо добавить
        @type add_elems: C{list}
        @param delete_elems: элементы, которые надо удалить
        @type delete_elems: C{list}
        """
        while not self.lock.try_lock():
            pass
 
        try:
            try:
                array = deserializeArray(self.mc.get(self.key))
            except KeyError:
                array = []
            array = filter(lambda e: e not in delete_elems, array) + add_elems
            self.mc.set(self.key, serializeArray(array), 0)
        finally:
            self.lock.unlock()

Обсуждение 1

Приведенный выше способ решения на самом деле не имеет никакого отношения к массивам, а может быть применен для любой структуры данных. Он основан на модели reader-writer, когда есть много читателей и относительно мало писателей. Читатели в любой момент с помощью метода fetch получают содержимое массива, при этом важно, что «писатель» сhange записывает содержимое одной командой memcached, то есть в силу внутренней атомарности операций get и set в memcached и несмотря на отсутствие синхронизации между методами fetch и сhange, результат fetch всегда будет консистентным: это будет значение до или после очередного изменения. Писатели блокируются от одновременного изменения массива с помощью блокировки MCLock, описанной выше.

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

Задача 2

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

Операции над массивом:

• добавить значение в массив (частая операция);
• получить массив целиком.

Решение 2

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

def serializeInt(int):
    """
    Сериализовать целое число в бинарное представление (str).
    """
 
def deserializeIntArray(str):
    """
    Десериализовать массив целых чисел из бинарного представления.
    """
 
class MCArray2(MemcacheObject):
    def __init__(self, mc, name):
        """
        Конструктор.
 
        @param name: имя массива
        @type name: C{str}
        """
        super(MCArray2, self).__init__(mc)
        self.key = 'array' + name
 
    def fetch(self):
        """
        Получить текущее значение массива.
 
        @return: массив
        @rtype: C{list}
        """
        try:
            return deserializeIntArray(self.mc.get(self.key))
        except KeyError:
            return []
 
    def add(self, element):
        """
        Добавить элемент в массив.
 
        @param element: элемент, который необходимо добавить в массив
        @type element: C{int}
        """
        element = serializeInt(element)
        while True:
            try:
                self.mc.append(self.key, element)
            except KeyError:
                return
 
            try:
                self.mc.add(self.key, element, 0)
            except KeyError:
                return

Обсуждение 2

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

Возможны следующие улучшения (или расширения) описанного примера:

• использование нескольких ключей для хранения массива вместо одного, распределение элементов по ключам с использованием хэширования; такой вариант позволит ограничить размер каждого ключа, при условии что массив большой (содержит много элементов);
• реализация в том же стиле операции удаления элемента из массива, тогда массив можно представить как последовательность операций «удалить» и «добавить», например сериализованное представление +1 +3 +4 -3 +5 будет после десериализации образовывать массив [1, 4, 5]; при этом как операция добавления элемента, так и удаления, будет приводить к дописыванию байт в конец сериализованного представления (атомарная операция append).

Таблица

Задача

Необходимо хранить множество строк. Операции над множеством:

• проверка принадлежности строки множеству (самая частая операция);
• получение множества целиком, добавление элемента, удаление элемента – редкие операции.

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

Решение

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

def serializeArray(array):
    """
    Сериализовать массив в бинарное представление.
    """
 
def deserializeArray(str):
    """
    Десериализовать массив из бинарного представления.
    """
 
class MCTable(MemcacheObject):
    def __init__(self, mc, name):
        """
        Конструктор.
 
        @param name: имя таблицы
        @type name: C{str}
        """
        super(MCTable, self).__init__(mc)
        self.lock = MCLock(name)
        self.key = 'table' + name
 
    def has(self, key):
        """
        Проверка наличия ключа в таблице.
 
        @param key: ключ
        @type key: C{str}
        @rtype: C{bool}
        """
        try:
            self.mc.get(self.key + '_v_' + key)
            return True
        except KeyError:
            return False
 
    def fetch(self):
        """
        Получить целиком значение элементов таблицы.
 
        @return: значение таблицы
        @rtype: C{list(str)}
        """
        try:
            return deserializeArray(self.mc.get(self.key + '_keys'))
        except KeyError:
            pass
 
    def add(self, key):
        """
        Добавить ключ в таблицу.
 
        @param key: ключ
        @type key: C{str}
        """
        while not self.lock.try_lock():
            pass
 
        try:
            try:
                array = deserializeArray(self.mc.get(self.key + '_keys'))
            except KeyError:
                array = []
            if key not in array:
                array.append(key)
            self.mc.set(self.key + '_v_' + key, 1, 0)
            self.mc.set(self.key + '_keys', serializeArray(array), 0)
        finally:
            self.lock.unlock()
 
    def delete(self, key):
        """
        Удалить ключ из таблицы.
 
        Реализация аналогична методу add().
        """

Обсуждение

Вообще говоря memcached представляет собой огромную хэш-таблицу, правда в ней отсутствует одна операция, которая необходима для нашей структуры данных: получение списка ключей. Поэтому реализация таблицы использует отдельные ключи для хранения каждого элемента таблицы, и отдельно еще один ключ для хранения списка всех её элементов. Реализация хранения списка всех элементов фактически совпадает с реализацией «массива 1″. Для сериализации доступа к списку всех элементов используется блокировка, при этом методы fetch и add не синхронизированы друг с другом, т.к. список всех элементов меняется атомарно и при чтении ключа мы всегда получим некоторое консистентное состояние.

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

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

Заключение

Итак, приведем список «приемов» или «трюков», описанных в данной статье:

• атомарность операций с помощью memcached (пара add/set и т.п.);
• блокировки;
• теневые ключи;
• кольцевой буфер с автоматическим «отмиранием» ключей;
• блокировки и модель reader-writer.

В статье не рассматривались вопросы оптимизации, специфичной для memcached, например, использование multi-get запросов. Это делалось сознательно, чтобы не перегружать исходный код и рассказ. Во многих ситуациях приведенные выше примеры следует рассматривать скорее как псевдокод, чем как пример идеальной реализации на Python.

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

Возвращаясь к теме «спора» с Горным (спора в кавычках, т.к. как такого спора не хотелось, да и не получилось): я не хочу никому сказать, что PostgreSQL – круче или что MySQL – полный отстой. Согласно опыту gornal, проект на PostgreSQL сделать нельзя и поэтому он ужасен, а аргументов вобщем-то других нет, я привел некоторые аргументы в чем PostgreSQL может быть лучше. Но не в этом дело. Совсем не в этом.

Господа, на PostgreSQL можно делать успешные проекты. Это классная, современная СУБД, она не «тормозит», не бойтесь её. Она действительно работает, легко администрируется, устанавливается и т.п. К ней есть куча интереснейших расширений. Если Вы изучали SQL по мануалу MySQL, она Вам ничего не даст, но если Вы читали, например, Дейта или слушали курс по реляционной алгебре и о реляционных СУБД – в PostgreSQL Вы сможете воплотить БД своей мечты и оптимизировать её столько, сколько Вам захочется. Не бойтесь! Попробуйте, может, Вам понравится. Не понравится – есть MySQL, Informix, Oracle, DB2, Firebird и т.п. Но бояться не надо, она не тормозит, честное слово

Всегда будут люди, которым нравятся какие-то продукты, например, ораклоид с пеной у рта будет доказывать, что кроме Oracle нет нормальных СУБД. Gornal скажет, что только на MySQL можно сделать успешный проект. Я люблю PostgreSQL и буду пользоваться им, покуда он будет подходить для тех задач, которые я решаю.

Не верьте тем, кто говорит, что PostgreSQL – отстой, попробуйте сами. Найдите для себя идеальную СУБД, попробуйте её возможности. Я использую PostgreSQL уже около четырех лет, но до сих пор открываю для себя что-то новое, есть специалисты по PostgreSQL, они знают огромное количество еще более интересного.

Напоследок: есть успешные проекты на PostgreSQL в мире веба и около него. Это Skype, Мой Круг и другие. И в сердце Smotri.Com как пламенный мотор трудится PostgreSQL, вся БД обслуживается по сути пятью серверами, один мастер и четыре слейва (Slony). Это самая простая на свете конструкция, её практически не оптимизировали с точки зрения специфики PostgreSQL. Я оцениваю возможности оптимизации в 2-3 раза без изменения логики приложения на сегодня. Дальнейшее возможно с изменением логики (например, шардинг или отгрузка части данных в MemcacheDB или что-то подобное).

Напоследок, российская специфика PostgreSQL:

• PostgresMen
• Фёдор Сигаев и Олег Бартунов – активные разработчики PostgreSQL
• Николай Самохвалов – один из тех, кто сделал Мой Круг, а сегодня активно продвигает PostgreSQL в России
• список можно было бы продолжить…

Обычным письмом приходит извещение от компании МТС, что на лицевом счету XXXXYYYY имеется непогашенная задолженность, что компания МТС скоро подаст в суд а данные мои передаст в бюро кредитных историй в качестве злостного неплательщика. Я удивился, пошел в Интернет-помощника, выяснил какой телефонный номер привязан к этому лицевому счету, на нем нет задолженности (судя по балансу), да и не было – регулярные платежи каждый месяц или иногда даже чаще.

Звонок в службу поддержки, переводят меня на «финансовый департамент», там милая девушка объясняет, что у каждого абонента имеется два баланса: один, который видит он, и, второй, «бухгалтерский», который он не видит. Так вот, данные балансы разошлись, и, как легко догадаться, на внутреннем балансе числится долг в 1000 рублей, а на внешнем что-то типа +100 рублей (т.е. разница больше чем 1000 рублей). Она сообщила, что такое «бывает», они будут разбираться и через неделю сообщат результаты.

Прошла неделя… Баланс счета (тот, который вижу я) стал -1000 рублей — надо думать, разобрались! Звоню, девушка думает и сообщает, что три года назад в 2005 году что-то не было засчитано правильно и с тех пор (sic!) за мной висит долг в 1000 рублей. Я спросил девушку, а как я могу это проверить или увидеть, потому что мне вобщем-то тяжело понять, как такое могло быть? Мне кажется, что она хотела сделать так, чтобы я больше не приставал с вопросами, и сказала, что я могу это увидеть в счетах, которые мне выставлялись за тот период (2005 год). Самым замечательным оказалось то, что как раз в то время я стал пользоваться Gmail, и одно из первых писем, сохраненных в моем ящике – это ежемесячные счета от МТС. Как раз в тот период на этом лицевом счете случился какой-то глюк биллинга МТС, который они исправляли около недели, разделяли счета, и т.п., и я даже был готов легко поверить, что именно тогда и могла образоваться такая задолженность. Я взглянул на счета за три месяца того периода, в них всё сходилось – баланс счета, платежи, расходы. Я снова позвонил в финансовую службу и спросил, как мне передать им эти счета, чтобы они мне показали, где же именно я оказался должен? Девушка мне предложила отправить письмо на адрес info@mts.ru, что я и сделал:

Две недели назад мне пришло письмо о имеющейся задолженности по
лицевому счету 2XXXXXXXXXX.
При этом баланс счета в интернет-помощнике, например, был положительным.
Я обратился в контактный центр компании МТС, в ситуации пообещали разобраться.

Сегодня я обратился вновь, т.к. не так и не получил ответа. Мне
сообщили, что с моим счетом разобрались и выявлена задолженность в
сумме около 40 у.е., которая возникла за период октября-ноября 2005
года (даты не помню точно, но у вас есть эта информация). И что
начиная с декабря 2005 года между балансом в автоинформаторе и
балансом в счетах существовал разрыв в 40 у.е., что я могу увидеть на
счетах, присланных мне за этот период. Я нашел счета за указанный
период, которые были мне присланы в то время.

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

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

Если информация о задолженности не подтвердится, прошу вернуть сумму
на мой лицевой счет.

Никакого ответа я не получил (даже ответа вида «ваше сообщение в службу поддержки принято, его номер «2222″, к которому я привык даже в службах поддержки небольших компаний). Здесь же письмо ухнуло как в черную дыру. Через день я снова позвонил в контактный центр МТС и спросил девушку, когда мне стоит ждать ответа на обращение, на что она мне сообщила, что если это просто вопрос, то две недели, а если претензия – 45 дней. Я спросил девушку, а как определить, у меня претензия или вопрос? Ответа не получил. Я спросил, а 45 дней – этот срок чем установлен? Она засомневалась, пошла советоваться со старшей. Вернулась, и сообщила, что «установлен законом». Я спросил: «Каким?» На что я получил ответ, потрясший меня до глубины души: «Конституцией». Я на всякий случай уточнил: «Конституцией РФ?» На что получил утвердительный ответ. Вот такие люди работают в службе поддержки В конце концов я получил совет отправить еще одно письмо на info@mts.ru, чтобы узнать срок рассмотрения, ок, я отправил.

Через два дня я получил ответ, что не позднее недели, а еще через два и ответ на моё первое письмо:

Благодарим Вас за пользование услугами компании МТС и в ответ на
Ваше обращение сообщаем, что на Вашем абонентском номере 916XXXXXXX
наблюдалось несовпадение реального баланса (ежемесячные счета на
услуги связи) и баланса, запрашиваемого  Вами по данному номеру.
Данная ситуация находилась под контролем у сотрудников технической
службы МТС и была устранена  05.11.2008г., после чего баланс Вашего
лицевого счета стал отрицательным и составил 1001,72 руб.
Мы сожалеем о возникшем недоразумении. Вследствие доставленных Вам
неудобств Компанией МТС принято решение о зачислении на Ваш лицевой
счет денежных средств в сумме 1200 руб., что соответствует размеру
уменьшения баланса. Указанная сумма зачислена на Ваш лицевой счет 10.11.2008г.
Заказав ежемесячные счета за период с 01.09.2008г. по 31.10.2008г.,
а в последующем и за ноябрь месяц, Вы сможете убедиться в том, что
на Вашем лицевом счете не совпадали реальный и запрашиваемый балансы.
В счетах, полученных Вами за 2005г., Вам представлена информация о
реальном балансе, но Вы, к сожалению, за давностью времени, не
можете ее сравнить с запрашиваемым Вами балансом на тот период
времени. Исходя из этого, Вы не можете увидеть несовпадение
реального баланса и баланса, запрашиваемого Вами.
Надеемся на Ваше понимание и дальнейшее сотрудничество. 

Результат – я ничего не понял, где баланс не сходился – в счетах он сходился, и в последних тоже, но не суть, может я правда чего-то не увидел, я не специалист. Деньги вернулись на счет, всё хорошо.

Дело не в деньгах, 1000 рублей – это еще не такая большая сумма, я готов заплатить, даже если я ничего не был должен. Обидно попасть в «бюро кредитных историй», на этот вопрос, кстати, я ответа не получил до сих пор. Я понимаю, что письма неплательщикам рассылаются шаблонные, но вряд ли меня можно в полной мере считать таковым. Что меня несколько пугает – это то, что по сути любой сотовый оператор (и не только) может в какой-то момент сообщить, что у «вас имеется задолженность в сумме YYYYY рублей». При этом количество нулей в этой сумме может быть практически произвольным. Расчеты с компанией у меня авансовые, то есть если образовалась задолженнность в 2005 году, то она не могла на самом деле тянуться два года (как не могла и в случае кредитных расчетов). А, самое главное, что если не эти копии счетов, сохранившиеся у меня почти случайно – ничего ведь доказать я не могу. Сумму поступлений на счет можно доказать чеками и т.п., но я никогда их не хранил, сумма расходов – только в биллинге оператора, и, по-хорошему, оператор в любой момент может увеличить сумму моих расходов за произвольный период или уменьшить сумму платежей – и доказать что-либо мне как клиенту будет очень сложно, а для суда они смогут сделать сколько угодно счетов с печатями, подтверждающими мой долг. А мне предоставить нечего, кроме электронных писем со счетами.

Вывод – хранить счета от оператора вечно. Иначе потом ничего никому не докажешь.

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

А кто в курсе, что D. J. Bernstein еще и математик? Что он является профессором и преподает в University of Illinois at Chicago, опубликовал большое количество статей, каждая из которых производит впечатление выверенной, педантичной, качественной работы, какой и должна быть математическая статья. В основном статьи так или иначе посвящены теме криптографии, и, особенно, вопросам «быстрой» криптографии, когда криптографический алгоритм может быть использован на маломощных устройствах или для обработки больших потоков данных.

DJB не является профессиональным юристом, однако он «засудил» правительство США (дело Bernstein v. United States) по поводу экспортных ограничений на системы безопасности (и, в частности, криптографии). Bernstein выступает против патентов на алгоритмы и идеи, пытаясь доказать несостоятельность существующих патентов (например, по причине того, что до подачи патентной заявки идеи были опубликованы). DJB и против попыток издательств получить экслюзивные права на научные публикации, чтобы потом по сути органичить доступ к ним, сделав его платным.

DJB дотошен, я бы сказал, что он «зануда». Он может потратить не один день на рассказ о том, как распределяются и крадутся деньги грантов в его университете UIC (ничего не напоминает?). При этом он пытается бороться с этой системой. Вряд ли его «любят», потому что он говорит многие вещи прямо. Он может свободно осуждать Paul Vixie, ISC, Nominum и других за реализацию BIND, по сути говоря о том, что они не могут написать хорошее программное обеспечение, «трясут» деньги за поддержку. При этом в BIND постоянно обнаруживаются проблемы безопасности, а его авторы предлагают заплатить деньги, чтобы узнать о них и получть патч, сознательно задерживая выход исправленной версии. DJB расскажет историю своей поездки на конференцию в Санкт-Петербург в стиле «и по улице у них бродят медведи». Он раскритикует IPv6 и планы его внедрения (с моей точки зрения, совершенно справедливо). DJB расскажет и о том, как надо и как не надо писать статьи.

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

Необходимость географической распределенности

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

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

Такой шаг необходимо сделать при желании выйти на международный рынок, а также при региональном развитии внутри РФ. Сегодня в регионах очень часто самыми популярными сайтами являются региональные порталы, которые предоставляют различные сервисы, в том числе и сервис видеохостинга, а их популярность обусловлена как стоимостью трафика, так и скоростью доступа/временем отклика. Можно представить, что пользователь готов подождать открытия страницы, загрузки плеера, но тяжело предположить, что пользователь согласится смотреть видео, которые прерывается из-за постоянной буферизации, или смотреть вещание, которое доходит до пользователя в виде слайдшоу (после пропуска пакетов остались только опорные кадры видео).

Таким образом, осознав необходимость географической распределенности для контента, мы покупаем/арендуем сервера в непосредственной близости от потребителя: в Европе, США, Украине, Екатеринбурге и т.д. Что же делать дальше?

Механизм работы

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

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

Выбор ближайшего к посетителю ресурса

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

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

Таким образом, мы получаем взвешенный ориентированный граф, на котором необходимо решить задачу поиска кратчайшего пути (минимизация суммы весов ребер графа, входящих в этот путь). Это классическая задача, которая может быть легко решена за полиномиальное время. Граф хоть и является слабосвязанным, но всё-таки его размеры достаточно велики, поэтому в реальном времени для каждого посетителя выполнять такой расчет не является самым эффективным решением. Но мы можем немного «схитрить»: мы знаем, что при всех поисках кратчайшего пути конечным пунктом пути будут места, где расположены сервера с ресурсами, таким образом, число различных конечный точек искомого пути фиксировано и относительно невелико. Теперь нам достаточно рассчитать и закэшировать, например, в memcached, длины кратчайших путей от всех вершин графа (где могут располагаться посетители нашего сайта) до мест расположения ресурсов.

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

Копирование ресурса

Схема выбора работает замечательно, когда мы имеем копии ресурса на серверах, разбросанных по всему миру. Однако как эти копии создаются? Было бы неразумно копировать все ресурсы на все сервера, лучше выбирать именно те ресурсы, которые будут востребованы конкретной аудиторией.

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

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

Географически распределенные видеофайлы и вещания

Теперь мы можем применить описанный выше подход к контенту видеохостинга: вещаниям и видео.

Видеофайлы. В этом случае ресурс – это сам файл видео (причём любого типа, как FLV, так, например, и оригинал видео). Копии ресурса – копии файла, находящиеся на зеркалирующих файловых серверов. Обращение к ресурсу – скачивание файла, проигрывание FLV-видео посетителем в Flash Player’е. Копирование ресурса – это просто копирование файла с основного файлового сервера на один из зеркалирующих файловых серверах, расположенных в различных точках.

Вещания. Для вещаний ситуация очень похожа, здесь ресурсом является, конечно же само вещание, расположенное на основном для него сервере вещания (том сервере, куда подключен автор вещания). Копии ресурса – это все ретрансляции данного вещания на других серверах вещания. Обращение к ресурсу – это «вход» в вещание нового посетителя. Копирование ресурса – открытие ретрансляции на сервере вещаний, расположенном в той или иной точке мира.

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

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

Данная статья, написанная по материалам доклада на конференции «РИТ: Высокие нагрузки»-2008, расскажет об одном из возможных подходов к решению поставленных задач. Рассказ будет основан на нашем опыте проектирования, разработки и поддержки видеохостинга Smotri.Сom, который является сегодня самым крупным видеохостингом Рунета. Описываемые подходы могут быть применимы в областях с похожими характеристиками контента: достаточно большой объем файлов, много файлов, различные виды вещаний и т.п.

Статья будет состоять из двух частей: в первой части речь пойдет об организации файлового хранилища для видеофайлов и об общих аспектах организации вещания. Во второй части будет представлен способ организации CDN (Content Delivery Network), то есть способ «приближения» контента к конечному потребителю, а также применение этого подхода к доставке статических файлов (файлов видео) и к потоковой трансляции (вещания).

Видео: организация файлового хранилища

Видеофайлы

Видеохостинг в процессе своего функционирования получает видео в различных форматах, которое загружается пользователями. Кроме хранения оригинального видеофайла, видеохостинг осуществляет конвертацию файла в ряд форматов: FLV, 3GP, MP4 и т.п. Все эти файлы необходимо хранить на файловых серверах, а также отдавать пользователям. Рассмотрим сначала вопрос хранения таких файлов.

Что представляют из себя эти файлы? Согласно нашим расчетам, в среднем для хранения одной секунды видео требуется 250 Кб дискового пространства (имеется в виду 250Кб/с на все форматы видео вместе взятые), при этом средняя длительность видео составляет примерно 4 минуты. Легко посчитать, что для хранения 1 млн. видеофайлов нам потребуется 60 Тб дискового пространства, что является уже достаточно внушительной цифрой. Этим объемом хранения надо эффективно управлять, а также обеспечивать раздачу такого объема контента пользователям. Кроме непосредственно видеофайлов нам придётся хранить и отдавать вырезанные из видео кадры, которых в нашем случае будет 15 штук: 5 кадров, вырезанные из разных участков видео, каждый из которых представлен в трех различных размерах (для показа информации о видео в блоках разного формата).

Доступ к файловому серверу через WebDAV

Непосредственно за хранение файла отвечает файловый сервер, в котором есть достаточно хорошо построенная дисковая подсистема в плане надежности и скорости доступа (RAID). Запросы на изменение файлов (создание новых файлов, удаление старых и т.п.) поступают с другой группы серверов: с «морд» (frontend) и с перекодировщиков. Морды – это обычные сервера, которые обслуживают подавляющее большинство запросов по HTTP как непосредственно к самому сайту, так и к его API. Перекодировщики принимают запросы от пользователей на загрузку исходных файлов видео и осуществляют их конвертацию. Итак, на морде или перекодировщике формируется заказ на операцию с файлами на файловом сервере, т.к. файловая система не является локальной, необходимо то или иное сетевое средство доступа к файловому серверу.

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

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

Внутри кластера серверов видеохостинга обращение к файловым серверам идёт по протоколу WebDAV. Скачивание файлов (в том числе проигрывание видео в Flash Player) идёт напрямую с файлового сервера, что позволяет более равномерно загрузить сетевые каналы, исключая «лишние» промежуточные звенья.

Выбор файлового сервера из кластера

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

• объем свободного места/объем сервера;
• нагрузка на сервер (как измерять?);
• случайный выбор.

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

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

Необходимое ПО

Описанный выше подход требует простого и распространенного программного обеспечения: для скачивания файлов подойдет любой «быстрый» HTTP-сервер, например, nginx, lighttpd и т.п. При этом для обеспечения подгрузки FLV в плеер с любой временнóй отметки (так называемого «стриминга»), нам необходимо очень простое расширение, которое сегодня присутствует как в nginx, так и в lighttpd (flv-streaming). В качестве WebDAV-сервера подойдет Apache httpd и т.п. Для доступа к файлам по WebDAV можно использовать любой WebDAV-клиент, который есть в том или ином виде практически во всех языках программирования. Так, например, в PHP он реализован в виде PEARовского класса (который приходится «допиливать», чтобы обеспечить разумную производительность). WebDAV не обеспечивает функциональности по получению объема свободного места на диске, но это легко обойти с помощью простейшего скрипта в cron, который вывод команды df перенаправляет в файл в корне файлового сервера, а этот файл уже можно скачать по HTTP с любой морды.

Кросс-бэкап

Каким образом обеспечить надежное сохранение 60 Тб данных? (При условии, что эта цифра будет расти?) Традиционные варианты с бэкапом на центральный сервер уже не подходят, т.к. такой объем хранения на одном сервере обеспечить трудно, да и надежность такой схемы невысока. Никакой уровень RAID в пределах одного сервера не может гарантировать надежность, т.к. возможен и аппаратный, и программный сбой, приводящий к потере данных. Простым и достаточно надежным способом является кросс-бэкап: каждый из файловых серверов заполняется наполовину, а затем содержимое первого сервера бэкапится на второй, и наоборот. Таким образом, если произойдет сбой на одном из серверов, на втором останется полное содержимое обоих серверов.

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

Вещания: ретрансляция

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

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

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

Итак:

1. Качаем отсюда словарь: http://ftp.services.openoffice.org/pub/OpenOffice.org/contrib/dictionaries/ru_RU.zip
2. Раскрываем архив в папку /tmp/dict.
3. mkdir -p ~/.vim/spell/

Запускаем Vim, делаем:

:mkspell! ~/.vim/spell/ru /tmp/dict/ru_RU

Вуаля! Словарь готов! (Всё описанное выше – подготовительный этап, это надо сделать всего один раз).

Включение проверки на русском и английском (для текущего буфера):

:setlocal spell spelllang=ru_ru,en_us

Дополнительно о проверке орфографии:

:help spell

Практически полностью код был взят из MochiKit.Async и адаптирован под qooxdoo. Полезные нововедения: если если в течение 1 секунды не будет обработана ошибка в Deferred (выполнение дойдет до конца цепочки callback, и останется ошибка), о ней будет сообщено на консоль, как о возможно необработанном исключении.

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

Итак, страничка qx.Deferred.

Пример кода:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

function callRPC(method, params)
{
    this.debug("API: call " + method + " with params: ");
    this.debug(params);
    var d = new netstream.lib.Deferred();
 
    var rpc = new qx.io.remote.Rpc();
    rpc.setTimeout(10000);
    rpc.setUrl(this.__api_url);
    rpc.callAsync(
        function (result, ex, id)
        {
            if (ex == null)
                d.callback(result);
            else
                d.errback(ex);
        },
        method, params);
 
    var that = this;
    d.addCallback(function (result) { that.debug("API: result:"); that.debug(result); return result; });
    d.addErrback(function (ex) { that.error(ex); return ex; });
    return d;
};
 
d = callRPC("somemethod", { 'someParams' });
d.addCallback(function (result) { alert("Got result: "+result); });

Сегодняшний пост завершает эту серию, в нём обзорно мы поговорим о технических «мелочах»:

• анализ статистики memcached;
• отладка memcached;
• «RPC» с помощью memcached.

Полный текст всех разделов в виде одной большой PDF-ки можно скачать и посмотреть здесь (в разделе «Материалы»).

Статистика работы memcached

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

Самая простая команда, stats, позволяет получить элементарную статистику: время работы сервера (uptime), объем используемой памяти, количество get запросов и количество хитов (hits), т.е. попаданий в кэш. Их соотношение позволяет нам судить об эффективности кэширования в целом, хотя необходимо учитывать, что в memcached ключами являются не только закэшированные выборки, но и счетчики, блокировки, тэги и т.п., так что для вычисления чистой эффективности кэширования это значение требует корректировки. Из общей статистики мы также можем узнать, сколько ключей было удалено раньше истечения срока жизни (evictions), данный параметр может сигнализировать о недостаточности объема памяти memcached.

Slab-аллокатор

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

Механизм его работы заключается в том, что вся доступная memcached память делится на slab’ы (блоки), каждый из которых будет хранить элементы определенного размера. Например, slab для хранения объектов размером 256 байт, при этом сам slab имеет размер 1 Мб, таким образом он может сохранить 4096 таких объектов. Память внутри такого slab’а выделяется только по 256 байт. Если у нас есть slab’ы для объектов размером 64, 128, 256, 1024 и 2048 байт, то максимальный размер объекта, который мы можем сохранить – 2048 байт (в последнем slabе). Если мы хотим сохранить объект размером 65 байт, под него будет выделена память в slab’е-128, 1 байт – в slab’е 64.

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

Здесь на горизонтальной оси отложены размеры slab’ов, а на вертикальной – объем памяти, используемый slab’ами данного размера. В данный момент вся память memcached занята ключами и их значениями, поэтому данный график представляет собой текущее распределение значений в памяти сервера. Легко видеть, что больше всего slab’ов выделено под ключи с относительно небольшими значениями – до 20 Кб, для больших по размеру ключей slab’ов гораздо меньше. Такое распределение адекватно нашей задаче: у нас больше всего именно маленьких ключей (счетчики, блокировки, небольшие кэши). При этом эти же ключи занимают и бóльшую часть памяти, с локальными пиками выделения под ключи размером 300 байт, 8 Кб. Если график отличается от того, который ожидается по логике задачи, это повод для беспокойства.

Отладка проектов, использующих memcached

Мы написали большую подсистему для работы с memcached, реализовали различные механизмы решения проблем, связанных с высокой нагрузкой. Как проверить, что всё действительно работает так, как нам бы этого хотелось? Высокую нагрузку, сетевые задержки и т.п. практически невозможно воспроизвести в локальном окружении, непросто это сделать и в тестовом окружении. На серверах в production нам доступны лишь те механизмы отладки, которые не затрагивают нормальное функционирование самого приложения. Способ отладки не должен вносить ощутимых временных задержек, иначе он изменит поведение приложения, и отладка станет бессмысленной.

Можно предложить следующий «трюк», который может помочь в данной ситуации: для каждого кэша (ключа в memcached) или для группы кэшей (ключей) мы заводим отдельный файл в локальной файловой системе. В этот файл в режиме append мы дописываем по одному символу в ответ на каждое логическое действие, которое произошло с кэшом. Для просмотра в реальном времени поведения кэширующей подсистемы достаточно сделать tail –f на этот файл:

MLWUHHHHHHHHHHHHHHHMLLHHHHHHHHHH

Пусть буквы имеют следующий смысл:

• M – кэш устарел (или не найден);
• L – попытка заблокироваться;
• W – запись (и построение) нового кэша;
• U – удаление блокировки;
• H – успешный запрос кэша.

Тогда по приведенной последовательности можно рассказать то, что происходило с данным кэшом: вначале он отсутствовал, мы кэш не обнаружили (M), попытались заблокироваться (L) для его построения, заблокировались, построили кэш (W), сняли блокировку (U), затем какое-то время кэш успешно работал, отдавая закэшированные данные (H). Потом в какой-то момент кэш устарел или был сброшен (M), мы попытались заблокироваться, не получилось (L), попытались еще раз (L), блокировка оказалась снята, кто-то другой построил новый кэш, мы его прочитали (H) и дальше им пользовались.

Межпроцессное взаимодействие с помощью memcached

Сложный проект состоит из отдельных компонент, сервисов, которые должны взаимодействовать друг с другом, используя механизмы RPC, вызовы API, обмениваясь информацией через БД или каким-то еще способом. Иногда для такого обмена информацией можно использовать и memcached.

В качестве примера рассмотрим сервис пользовательских вещаний: существует какое-то количество вещаний, в каждом из которых в данный момент времени находится некоторое количество зрителей. Популярность вещания определяется количеством зрителей. Актуальной информацией о количестве зрителей обладает только сервер вещаний, а список вещаний на странице вещаний формирует frontend. Конечно, можно было бы сделать так, чтобы сервер вещаний периодически сбрасывал в БД или через API в frontend информацию о количестве зрителей, или frontend мог бы через API сервера вещаний получать актуальную информацию. Однако количество зрителей – очень быстро меняющаяся характеристика, и в данной ситуации можно просто из сервера вещаний периодически (раз в несколько секунд) сохранять в memcached информацию о количестве зрителей в каждом из вещаний, а frontend, обращаясь к memcached, может получить информацию в любой удобный момент. Таким может быть межпроцессное взаимодействие, реализованное с помощью memcached.

Сегодня мы поговорим о тэгировании кэшей и о возможности сброса сразу группы кэшей в memcached.

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

Сброс группы кэшей

Если мы закэшировали какие-то данные от backend’а, например, выборку из БД, рано или поздно исходные данные изменяются, и кэш перестает быть валидным. Причем очень желательно, чтобы кэш сбрасывался сразу же за изменением, иначе пользователь после редактирования может увидеть старую версию объекта, что его, несомненно, смутит. Есть простой вариант ситуации: мы меняем информацию об объекте с ID 35, и сбрасываем кэш выборки этого объекта по параметру ID=35. На практике же чаще всего один и тот же объект явно или неявно входит в большое количество выборок, а значит и кэшей.

Рассмотрим такой пример: мы написали блогохостинг, в нем большое количество блогов. Когда один из авторов создает новый пост, меняется большое количество выборок: посты на главной странице и всех вторых страницах списка постов (т.к. все посты «сдвинулись» на один), изменилось количество записей в календаре постов, изменилась RSS-ка, и т.п. Конечно, мы могли бы поставить кэшам этих выборок небольшое время жизни, тогда через какое-то время они сбросятся и будут отображать правильную информацию, но слишком короткое время кэширования (5 секунд, например), будет давать низкое соотношение хитов в кэш, увеличивая нагрузку на БД, а более длительное будет создавать у пользователя ощущение, что информация после создания поста не обновилась, а, значит, пост не добавился. В то же время можно заметить, что в рамках блогохостинга если даже мы сбросим все кэши, связанные с данным блогом, это совсем небольшой процент от общей массы кэширования (т.к. блогов очень много). Остался вопрос: как найти и проидентифицировать все кэши данного блога? Какие-то из них мы можем легко построить, для некоторых это становится уже неудобно: например, количество кэшей постраничного списка постов зависит от количества страниц, которое еще необходимо вычислить. Что же делать?

Одно из возможных решений – тэгирование кэшей. Описанный ниже способ тэгирования по своей сути совпадает с описанным Дмитрием Котеровым в его наблах, но был нами разработан независимо. Существуют и другие варианты тэгирования, например, патч memcached-tag на memcached.

Тэг кэша

Итак, мы вводим новое понятие – тэг кэша. Один кэш может нести с собой список тэгов, с которыми он связан. Сам по себе тэг – это некоторое имя и связанная с ним версия (число). Версия тэга может только монотонно увеличиваться. Группой кэшей мы будем называть кэши, имеющие один общий тэг. Для того чтобы сбросить группу кэшей, достаточно увеличить версию соответствующего тэга.

На программном уровне мы знаем, что данная выборка должна быть закэширована и что её кэш будет связан с тэгами tag1 и tag2 (данный факт определяется логикой работы нашего приложения). При создании кэша мы записываем в него кроме данных закэшированной выборки еще текущие (на момент создания кэша) версии тэгов tag1 и tag2. При получении кэша мы считаем его валидным если не истекло время его жизни, и при этом текущии версии тэгов tag1 и tag2 равны версиям, записанным в кэше. Таким образом, если мы изменяем (увеличиваем) версию тэга tag1, все кэши, связанные с этим тэгом, которые были построены ранее, перестанут быть валидными (т.к. в них записана меньшая версия тэга tag1).

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

Версии тэгов:
  tag1 -> 25
  tag2 -> 63
Кэш выборки:
  [
    срок годности: 2008-11-07 21:00
    данные кэша: [
                     …
                  ]
    тэги: [
         tag1: 25
         tag2: 63
          ]
   ]

Затем произошло некоторое событие, и мы решили сбросить все кэши, ассоциированные с тэгом tag2, т.е. мы увеличили версию тэга: tag2++. Изменились версии тэгов:

Версии тэгов:
  tag1 -> 25
  tag2 -> 64

Теперь наш кэш перестал быть валидным, не смотря на то, что его «срок годности» еще не истёк: версия тэга tag2, сохраненная в нем (63) не совпадает с текущей версией (64).

Версии тэгов

Тэги (то есть их версии) имеет смысл хранить там же, где мы и храним наши кэши, то есть в memcached. Для каждого тэга мы создадим ключ с именем, совпадающим с именем тэга, его значением будет версия тэга. Осталось решить, что использовать в качестве версии тэга? Можно было бы использовать просто числа, инкрементируя их при изменении версии тэга, но это может привести к некорректному поведению при условии возможной потери ключей. Пусть версия тэга равнялась единице, мы закэшировали выборку с этим тэгом, записали в кэш значение тэга – единицу. Затем ключ с версией тэга был удален из memcached, а в следующий момент времени мы захотели сбросить выборки, связанные с тэгом, то есть необходимо увеличить версию тэга. Так как мы потеряли значение версии тэга, мы снова поставим единицу, и теперь наш кэш будет считаться валидным, хотя он сбросился (не важно, какое значение выбирать при увеличении версии тэга, если она была потеряна – всегда возможна ситуация, что это же значение использовалось и ранее).

В качестве версии удобнее использовать текущее время (с достаточной точностью, например, до миллисекунд). Тогда увеличение версии тэга будет всегда давать новую, бóльшую версию, даже в случае потери предыдущей версии. Версия тэга формируется на frontend’ах, их системные часы должны быть синхронизованы (без этого не будет работать и другая функциональность, например, корректное вычисление срока годности кэшей с коротким временем жизни), так что проблем с таким выбором способа вычисления версии не должно быть.

Использование текущего времени в качестве версии тэга даёт еще одно преимущество в ситуации, когда БД проекта устроена по схеме мастер-слейв репликации. При изменении исходного объекта в БД мы изменяем версию тэга, связанного с ним (записываем туда текущее время, то есть время изменения). В другом процессе мы обнаруживаем, что кэш устарел, то есть его надо перестроить, перестроение – это читающий запрос (SELECT), который необходимо отправить на слейв-сервер БД, но в силу задержек репликации слейв-сервер еще мог не получить актуальную версию объекта в БД, в результате мы кэш сбросили, но при его перестроении снова закэшировали старый вариант объекта, что неприемлемо. Можно использовать версию тэга при решении вопроса, на какой сервер БД отправить запрос: если разница между текущим временем и версией какого-либо тэга кэша меньше некоторого интервала, определяемого максимальной задержкой репликации, мы отправляем запрос на мастер-сервер БД вместо слейва.

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

Продолжение следует…

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

Следующий пост будет посвящен тэгированию кэшей.

Одновременное перестроение кэшей

Данная проблема характерна в первую очередь для высоконагруженных проектов. Рассмотрим следующую ситуацию: у нас есть выборка из БД, которая используется на многих страницах или особо популярных страницах (например, на главной странице). Эта выборка закэширована с некоторым «сроком годности», т.е. кэш будет сброшен по прошествии некоторого интервала времени. При этом сама выборка является относительно сложной, её вычисление заметно нагружает backend (БД). В какой-то момент времени ключ в memcached будет удален, т.к. истечет срок его жизни (срок жизни был установлен у кэша), в этот момент несколько frontend’ов (несколько, т.к. выборка часто используется) обратятся в memcached по этому ключу, обнаружат его отсутствие и попытаются построить кэш заново, осуществив выборку из БД. То есть в БД одновременно попадет несколько одинаковых запросов, каждый из которых заметно нагружает базу данных, при превышении некоторого порога запрос не будет выполнен за разумное время, еще больше frontend’ов обратятся к кэшу, обнаружат его отсутствие и отправят еще больше запросов в базу данных, с которыми база данных тем более не справится. В результате сервер БД получил критическую нагрузку, и «прилёг». Что делать, как избежать такой ситуации?

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

Можно предложить следующую схему: мы больше не ограничиваем время жизни ключа с кэшом в memcached – он будет там находиться до тех пор, пока не будет вытеснен другими ключами. Но вместе с данными кэша мы записываем и реальное время его жизни, например:

{
    годен до: 2008-11-03 11:53,
    данные кэша:
    {
       ...
    }
}

Теперь при получении ключа из memcached мы можем проверить, истёк ли срок жизни кэша с помощью поля «годен до». Если срок жизни истёк, кэш надо перестроить, но мы будем делать это с блокировкой (о блокировках речь пойдет в следующем разделе), если не удастся заблокироваться, мы можем либо подождать еще (раз блокировка уже есть, значит кэш кто-то перестраивает), либо вернуть старое значение кэша. Если заблокироваться удастся, мы строим кэш самостоятельно, при этом другие frontend’ы не будут перестраивать этот же кэш, так как увидят нашу блокировку. Основное преимущество хранения в memcached без указания срока годности – именно возможность получить старое значение кэша в случае, если кэш уже перестраивается кем-то. Что именно делать – ждать, пока кэш построит кто-то другой, и получать новое значение из memcached, или возвращать старое значение, – зависит от задачи, насколько приемлемо старое значение и сколько можно провести времени в состоянии ожидания. Чаще всего можно позволить себе 2-3 секундное ожидание с проверкой удаления блокировки и, если кэш так и не построился (что маловероятно, получается что выборка происходит больше чем за 2-3 секунды), вернуть старое значение, освобождая frontend для других задач.

Пример такого алгоритма

1. Получаем доступ к кэшу cache, его срок жизни истёк.
2. Пытаемся заблокироваться по ключу user cache_lock.
   • Не удалось получить блокировку:
     • ждём снятия блокировки;
     • не дождались: возвращаем старые данные кэша;
     • дождались: выбираем значения ключа заново, возвращаем новые данные (построенный кэш другим процессом).
   • Удалось получить блокировку:
     • строим кэш самостоятельно.

Такая схема позволяет исключить или свести к минимуму ситуации «заваливания» backend’а одинаковыми «тяжелыми» запросами, когда реально запрос достаточно выполнить лишь один раз. Остается последний вопрос, как обеспечить корректную блокировку? Очевидно, что так как проблема одновременного перестроения возникает на разных frontend’ах, то блокировка должна быть в общедоступном для них всех месте, то есть в memcached.

Блокировки в memcached

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

Пусть мы хотим заблокироваться по ключу ‘lock’: пытаемся получить значения ключа с помощью операции get. Если ключ не найден, значит блокировки нет, и мы с помощью операции set устанавливаем значение этого ключа, например, в единицу, а время жизни устанавливаем в небольшой интервал времени, который превышает максимальное время жизни блокировки, например, в 10 секунд. Теперь, если frontend завершится аварийно и не снимет блокировку, она автоматически уничтожится через 10 секунд. Итак, с помощью set мы блокировку установили, выполнили все необходимые действия, после этого снимаем блокировку просто удаляя соответствующий ключ командой del. Если на первой операции get мы получили значение ключа, это означает, что блокировка уже установлена другим процессом, наша операция блокировки неуспешна.

Описанный способ обладает недостатком: наличием состояния гонки (race condition). Два процесса могут одновременно сделать get, оба могут получить ответ, что «ключа нет», оба сделают set, и оба будут считать, что установили блокировку успешно. В ситуациях, как одновременное перестроение кэшей, этого может быть допустимо, т.к. здесь цель не исключить все другие процессы, а резко уменьшить количество одновременных запросов к БД, что может обеспечить и этот простой, некорректный вариант.

Второй вариант корректен, и даже проще первого. Для захвата блокировки достаточно выполнить одну команду: add, указав имя ключа и время жизни (такое же маленькое, как и в первом варианте). Команда add будет успешной только в том случае, если ключа в memcached еще нет, то есть наш процесс и есть тот единственный процесс, которому удалось захватить блокировку. Тогда нам надо выполнить необходимые действия и освободить блокировку командой del. Если add вернет ошибку «такой ключ уже существует», значит, блокировка была захвачена раньше каким-то другим процессом.

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

1
2
3
4
5
6
7
8
9
10

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

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

1
2
3
4

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

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

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

Сегодня речь пойдет о:

• атомарных операциях в memcached;
• реализации счетчиков просмотров и онлайнеров.

Следующий пост будет посвящен проблеме одновременного перестроения кэшей.

Атомарность операций в memcached

Как таковые, все одиночные запросы к memcached атомарны (в силу его однопоточности и корректных внутренних блокировок в многопоточном случае). Это означает, что если мы выполняем запрос get, мы получим значения ключа таким, как кто-то его записал в кэш, но точно не смесь двух записей. Однако каждая операция независима, и мы не можем гарантировать, например, корректность такой процедуры в ситуации конкурентного доступа из нескольких параллельных процессов:

1. Получить значение ключа «x» ($x = get x).
2. Увеличение значения переменной на единицу ($x = $x + 1).
3. Запись нового значения переменной в memcached (set x = $x).

Если данный код выполняют несколько frontend’ов одновременно, может получиться так, что значение ключа x увеличится не n раз, как мы задумывали, а на меньшее значение (классическое состояние гонки, race condition). Конечно, такой подход неприемлем для нас. Классический ответ на сложившуюся ситуацию: применение синхронизационных примитивов (семафоров, мутексов и т.п.), однако в memcached они отсутствуют. Другим вариантом решения задачи является реализация более сложных операций, которые заменяют неатомарную последовательность get/set.

В memcached для решения этой проблемы есть пара операций: incr/decr (инкремент и декремент). Они обеспечивают атомарное увеличение (или, соответственно, уменьшение) целочисленного значения существующего в memcached ключа. Атомарными являются также дополнительные операции: append/prepend, которые позволяют добавить к значению ключа данные в начало или в конец, также в каком-то плане атомарными можно считать операции add и replace, которые позволяют задать значение ключа, только если он ранее не существовал, или, наоборот, заменить значение уже существующего ключа. Об еще одном варианте атомарных операций речь пойдет в разделе про реализацию блокировок средствами memcached. Необходимо дополнительно отметить, что любая блокировка в memcached должна быть мелкозернистой (fine-grained), то есть должна затрагивать как можно меньшее число объектов, так как основная задача сервера в любом случае – обеспечивать эффективный доступ к кэшу как можно большего числа параллельных процессов.

Счетчики в memcached

Memcached может использоваться не только для хранения кэшей выборок из backend’ов, не только для хранения сессий пользователей (о чем было упомянуто в начале статьи), но и для задачи, которая без memcached решается достаточно тяжело, – реализация счетчиков, работающих в реальном времени. Т.е перед нами стоит задача показывать текущее значение счетчика в данный момент времени, если откинуть требование «реального времени», это можно реализовать через логирование и последующий анализ накопленных логов. Рассмотрим несколько примеров таких счетчиков, как их можно реализовать, какие возможны проблемы.

Счетчик просмотров

Пусть в нашем проекте есть некоторые объекты (например, фото, видео, статьи и т.п.), для которых мы должны в реальном времени показывать число просмотров. Счетчик должен увеличиваться с каждым просмотром. Самый простой вариант – при каждом просмотре обновлять поле в БД, не будет работать, т.к. просмотров много и БД не выдержит такую нагрузку. Мы можем реализовать точный и аккуратный сбор статистики просмотров, их аккумулирование, и периодический анализ, который заканчивается обновлением счетчика в базе данных (например, раз в час). Однако остается задача показа текущего количества просмотров. Рассмотрим следующее возможное решение. Frontend в момент просмотра объекта формирует имя ключа счетчика в memcached, и пытается выполнить операцию incr (инкремент) над этим ключом. Если выполнение было успешным, это означает, что соответствующий ключ находится в memcached, мы просмотр засчитали, также мы получили новое значение счетчика (как результат операции incr), которое мы можем показать пользователю. Если же операция incr вернула ошибку, то ключ счетчика в данный момент отсутствует в memcached, мы можем выбрать в качестве начального значения число просмотров из базы данных, увеличить его на единицу, и выполнить операцию set, устанавливая новое значение счетчика. При последующих просмотрах ключ уже будет находиться в memcached, и мы будем просто увеличивать его значение с помощью incr.

Необходимо отметить, что приведенная схема не является вполне корректной: в ней присутствует состояние гонки (race condition). Если два frontend одновременно обращаются к счетчику, одновременно обнаруживают его отсутствие, и сделают две операции set, мы потеряем один просмотр. Это можно считать не очень критичным, так как процесс аккумулирования статистики восстановит правильное значение. В случае необходимости можно воспользоваться блокировками в memcached, речь о которых пойдет ниже. Или же реализовать инициализацию счетчика через операцию add, обрабатывая её результат.

Счетчик онлайнеров

Существует еще один вид счетчиков, который без memcached или подобного ему решения вряд ли может быть реализован: это счетчик «онлайнеров». Такие счетчики мы видим на большом количестве сайтов, однако в первую очередь необходимо определить, что же именно мы имеем в виду под «онлайнером». Пусть мы хотим рассчитать, сколько уникальных сессий (пользователей) обратилось к нашему сайту за последние 5 минут. Уникальность обращения пользователя с данной сессией в течение 5 минут можно отследить, сохраняя в сессии время последнего засчитанного обращения, если прошло более 5 минут – значит это новое (уникальное) обращение.

Итак, выделим в memcached шесть ключей с именами, например, c_0, c_1, c_2, …, c_5. Текущим изменяемым ключом мы будем считать счетчик с номером, равным остатку от деления текущей минуты на 6 (на рисунке это ключ c_4). Именно его мы будем увеличивать с помощью операции incr для обращения каждой уникальной в течение 5 минут сессии. Если incr вернет ошибку (счетчика еще нет), установим его значение в 1 с помощью set, обязательно указав время жизни 6 минут. Значением счетчика онлайнеров будем считать сумму всех ключей, кроме текущего (на рисунке это ключи c_0, c_1, c_2, c_3 и c_5).

Когда наступит следующая минута, текущим изменяемым ключом станет ключ c_5, при этом его предыдущее значение исчезнет (т.к. он был создан 6 минут назад с временем жизни те же 6 минут). Значением счетчика станет сумма ключей c с_0 по c_4, т.е. только что рассчитанное значение ключа с_4 уже начнет учитываться в отображаемом значении счетчика.

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

Продолжение следует…

Сегодня речь пойдет о:

• выборе ключа кэширования;
• кластеризации memcached и алгоритмах распределения ключей.

Следующий пост будет посвящен атомарности операций и счетчикам в memcached.

Ключ кэширования

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

• При изменении параметров выборки, которую мы кэшируем, ключ кэширования должен изменяться (чтобы с новыми параметрами мы не «попали» в старый кэш).
• По параметрам выборки ключ должен определяться однозначно, т.е. для одной и той же выборки ключ кэширования должен быть только один, иначе мы рискуем понизить эффективность процесса кэширования.

Конечно, мы могли бы для каждой выборки строить ключ самостоятельно, например, ‘user_158’ для выборки информации о пользователе с ID 158 или ‘friends_192_public_sorted_online’ для друзей пользователя с ID 192, которые доступно публично и притом отсортированы в порядке последнего появления на сайте. Такой подход чреват ошибками и несоблюдением условий, сформулированных выше.

Можно использовать следующий вариант (пример для PHP): если существует некоторая точка в коде, через которую проходят все обращения к БД, а любое обращение полностью описывается (содержит все параметры запроса) в некоторой структуре $options, можно использовать следующий ключ:

$key = md5(serialize($options)) 

Такой ключ несомненно удовлетворяет первому условию (при изменении $options будет обязательно изменен $key), но и второе условие будет соблюдаться, если мы будем все типы данных в $options использовать «канонически», т.е. не допускать строки "1" вместо числа 1 (хотя в PHP два таких значения равны, но их сериализованное представление различается). Функция md5 используется для «сжатия» данных: ключ memcached имеет ограничение по длине, а сериализованное представление может быть слишком длинным.

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

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

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

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

Исторически первой функцией распределения была функция модуля:

f(ключ) = crc32(ключ) % количество_серверов

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

Альтернативой для данной функции является механизм консистентного хэширования (consistent hashing), который при переконфигурации кластера сохраняет положение ключей по серверам. Этот подход был реализован в клиентах memcached впервые разработчиками сервиса Last.fm в апреле 2007 года.

Суть алгоритма заключается в следующем: мы рассматриваем набор целых чисел от 0 до 2­³², «закручивая» числовую ось в кольцо (склеиваем 0 и 2³²). Каждому сервера из пула memcached-серверов мы сопоставляем число на кольце (рисунок слева, сервера A, B и C). Ключ хэшируется в число в том же диапазоне (на рисунке – синие точки 1-4), в качестве сервера для хранения ключа мы выбираем сервер в точке, ближайшей к точке ключа в направлении по часовой стрелке. Если сервер удаляется из пула или добавляется в пул, на оси появляется или исчезает точка сервера, в результате чего лишь часть ключей перемещается на другой сервер. На рисунке 2 справа показана ситуация, когда сервер C был удалён из пула серверов и добавлен новый сервер D. Легко заметить, что ключи 1 и 2 не поменяли привязки к серверам, а ключи 3 и 4 переместились на другие сервера. На самом деле одному серверу ставится в соответствие 100-200 точек на оси (пропорционально его весу в пуле), что улучшает равномерность распределения ключей по серверам в случае изменения их конфигурации.

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

Продолжение следует…

Материалы

1. http://weblogs.java.net/blog/tomwhite/archive/2007/11/consistent_hash.html
2. http://www.lastfm.ru/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients

Введение

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

Кэширование сегодня является неотъемлемой частью любого Web-проекта, не обязательно высоконагруженного. Для каждого ресурса критичной для пользователя является такая характеристика, как время отклика сервера. Увеличение времени отклика сервера приводит к оттоку посетителей. Следовательно, необходимо минимизировать время отклика: для этого необходимо уменьшать время, требуемое на формирование ответа пользователю, а ответ пользователю требует получить данные из каких-то внешних ресурсов (backend). Этими ресурсами могут быть как базы данных, так и любые другие относительно медленные источники данных (например, удаленный файловый сервер, на котором мы уточняем количество свободного места). Для генерации одной страницы достаточно сложного ресурса нам может потребоваться совершить десятки подобных обращений. Многие из них будут быстрыми: 20 мс и меньше, однако всегда существует некоторое небольшое количество запросов, время вычисления которых может исчисляться секундами или минутами (даже в самой оптимизированной системе один могут быть, хотя их количество должно быть минимально). Если сложить всё то время, которое мы затратим на ожидание результатов запросов (если же мы будем выполнять запросы параллельно, то возьмем время вычисления самого долгого запроса), мы получим неудовлетворительное время отклика.

Решением этой задачи является кэширование: мы помещаем результат вычислений в некоторое хранилище (например, memcached), которое обладает отличными характеристиками по времени доступа к информации. Теперь вместо обращений к медленным, сложным и тяжелым backend’ам нам достаточно выполнить запрос к быстрому кэшу.

Memcached и кэширование

Принцип локальности

Кэш или подход кэширования мы встречаем повсюду в электронных устройствах, архитектуре программного обеспечения: кэш ЦП (первого и второго уровня), буферы жесткого диска, кэш операционной системы, буфер в автомагнитоле. Чем же определяется такой успех кэширования? Ответ лежит в принципе локальности: программе, устройству свойственно в определенный промежуток времени работать с некоторым подмножеством данных из общего набора. В случае оперативной памяти это означает, что если программа работает с данными, находящимися по адресу 100, то с большей степенью вероятности следующее обращение будет по адресу 101, 102 и т.п., а не по адресу 10000, например. То же самое с жестким диском: его буфер наполняется данными из областей, соседних по отношению к последним прочитанным секторам, если бы наши программы работали в один момент времени не с некоторым относительно небольшим набором файлов, а со всем содержимым жесткого диска, буферы были бы бессмысленны. Буфер автомагнитолы совершает упреждающее чтение с диска следующих минут музыки, потому что мы, скорее всего, будем слушать музыкальный файл последовательно, чем перескакивать по набору музыки и т.п.

В случае web-проектов успех кэширования определяется тем, что на сайте есть всегда наиболее популярные страницы, некоторые данные используются на всех или почти на всех страницах, то есть существуют некоторые выборки, которые оказываются затребованы гораздо чаще других. Мы заменяем несколько обращений к backend’у на одно обращения для построения кэша, а затем все последующие обращения будет делать через быстро работающий кэш. Кэш всегда лучше, чем исходный источник данных: кэш ЦП на порядки быстрее оперативной памяти, однако мы не можем сделать оперативную память такой же быстрой, как кэш – это экономически неэффективно и технически сложно. Буфер жесткого диска удовлетворяет запросы за данными на порядки быстрее самого жесткого диска, однако буфер не обладает свойством запоминать данные при отключении питания – в этом смысле он хуже самого устройства. Аналогичная ситуация и с кэшированием в Web’е: кэш быстрее и эффективнее, чем backend, однако он обычно в случае перезапуска или падения сервера не может сохранить данные, а также не обладает логикой по вычислению каких-либо результатов: он умеет возвращать лишь то, что мы ранее в него положили.

Memcached

Memcached представляет собой огромную хэш-таблицу в оперативной памяти, доступную по сетевому протоколу. Он обеспечивает сервис по хранению значений, ассоциированных с ключами. Доступ к хэшу мы получаем через простой сетевой протокол, клиентом может выступать программа, написанная на произвольном языке программирования (существуют клиенты для C/C++, PHP, Perl, Java и т.п.)

Самые простые операции – получить значение указанного ключа (get), установить значение ключа (set) и удалить ключ (del). Для реализации цепочки атомарных операций (при условии конкурентного доступа к memcached со стороны параллельных процессов) используются дополнительные операции: инкремент/декремент значения ключа (incr/decr), дописать данные к значению ключа в начало или в конец (append/prepend), атомарная связка получения/установки значения (gets/cas) и другие.

Memcached был реализован Брэдом Фитцпатриком (Brad Fitzpatrick) в рамках работы над проектом ЖЖ (LiveJournal). Он использовался для разгрузки базы данных от запросов при отдаче контента страниц. Сегодня memcached нашел своё применение в ядре многих крупных проектов, например, Wikipedia, YouTube, Facebook и другие.

Общая схема кэширования

В общем случае схема кэширования выглядит следующим образом: frontend’у (той части проекта, которая формирует ответ пользователю) требуется получить данные какой-то выборки. Frontend обращается к быстрому как гепард серверу memcached за кэшом выборки (get-запрос). Если соответствующий ключ будет обнаружен, работа на этом заканчивается. В противном случае следует обращение к тяжелому, неповоротливому, но мощному (как слон) backend’у, в роли которого чаще всего выступает база данных. Полученный результат сразу же записывается в memcached в качестве кэша (set-запрос). При этом обычно для ключа задается максимальное время жизни (срок годности), который соответствует моменту сброса кэша.

Такая стандартная схема кэширования реализуется всегда. Вместо memcached в некоторых проектах могут использоваться локальные файлы, иные способы хранения (другая БД, кэш PHP-акселератора и т.п.) Однако, как будет показано далее, в высоконагруженном проекте данная схема может работать не самым эффективным образом. Тем не менее, в нашем дальнейшем рассказе мы будем опираться именно на эту схему.

Архитектура memcached

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

Во-первых, memcached спроектирован так, чтобы все его операции имели алгоритмическую сложность O(1), т.е. время выполнения любой операции не зависит от количества ключей, которые хранит memcached. Это означает, что некоторые операции (или возможности) будут отсутствовать в нём, если их реализация требует всего лишь линейного (O(n)) времени. Так, в memcached отсутствуют возможность объединения ключей «в папки», т.е. какой-либо группировки ключей, также мы не найдем групповых операций над ключами или их значениями. Основными оптимизированными операциями является выделение/освобождение блоков памяти под хранение ключей, определение политики самых неиспользуемых ключей (LRU) для очистки кэша при нехватке памяти. Поиск ключей происходит через хэширование, поэтому имеет сложность O(1).

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

По сути, можно сказать, что время отклика сервера memcached определяется только сетевыми издержками и практически равно времени передачи пакета от frontend’а до сервера memcached (RTT). Такие характеристики позволяют использовать memcached в высоконагруженных web-проектов для решения различных задач, в том числе и для кэширования данных. Потеря ключей

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

1. Ключ был удален раньше окончания его срока годности в силу нехватки памяти под хранение значений других ключей. Memcached использует политику LRU, поэтому такая потеря означает, что данный ключ редко использовался и память кэша освобождается для хранения более популярных ключей.
2. Ключ был удален, так как истекло его время жизни. Такая ситуация строго говоря не является потерей, так как мы сами ограничили время жизни ключа, но для клиентского по отношению к memcached кода такая потеря неотличима от других случаев – при обращении к memcached мы получаем ответ «такого ключа нет».
3. Самой неприятной ситуацией является крах процесса memcached или сервера, на котором он расположен. В этой ситуации мы теряем все ключи, которые хранились в кэше. Несколько сгладить последствия позволяет кластерная организация: множество серверов memcached, по которым «размазаны» ключи проекта: так последствия краха одного кэша будут менее заметны.

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

«Можно потерять». К этой категории относятся кэши выборок из базы данных. Потеря таких ключей не так страшна, потому что мы можем легко восстановить их значения, обратившись заново к backend’у. Однако частые потери кэшей приводят к излишним обращениям к БД.

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

«Совсем не должны терять». Memcached удобен для хранения сессий пользователей – все сессии равнодоступны со всех серверов, входящих в кластер frontend’ов. Так вот содержимое сессий не хотелось бы терять никогда – иначе пользователей на сайте будет «разлогинивать». Как попытаться избежать? Можно дублировать ключи сессий на нескольких серверах memcached из кластера, так вероятность потери снижается.

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

Мои впечатления о конференции

Итак, мне понравилось. Интересные доклады – много интересных докладов. Жалко, что не было Яндекса – они делают хорошие доклады. В первый день была проблема поесть и попить, но ко второму дню ситуация как-то улучшилась. Народу чуть-чуть больше, чем хотелось бы (иногда в аудиторию к докладчику не пролезть через тела тех, которые устроили «пробку» на входе в зал). Но интересные или очень интересные доклады, много обсуждений, новых идей. Встретил старых знакомых, это всегда приятно

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

Краткие тезисы

Требуемое время: 50 минут Докладчик: Андрей Смирнов

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

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

Как эффективно использовать такое хранилище? Как исключить возможность одновременного построения “тяжелых” кешей разными мордами? Как сбросить одновременно группу кешей? Как отлаживать (собирать статистику) о кешировании? Как работает slab-аллокатор? Для чего еще может быть полезен memcached в веб-проекте?

Видео с конференции

Презентация

Полный текст доклада

Материалы

• Тезисы (RTF)
• Презентация (PowerPoint)
• Полный текст доклада (PDF)

Краткие тезисы доклада привожу ниже:

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

UPD: доклад будет во второй день, 7 октября, 17:20-18:10, второй зал.

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

Как эффективно использовать такое хранилище? Как исключить возможность одновременного построения “тяжелых” кешей разными мордами? Как сбросить одновременно группу кешей? Как отлаживать (собирать статистику) о кешировании? Как работает slab-аллокатор? Для чего еще может быть полезен memcached в веб-проекте?

Ниже вы найдете краткие тезисы доклады, полные тезисы, презентацию, а также видео с конференции.

Краткие тезисы

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

Аудитория доклада: уровень — средний, может быть интересно широкому классу специалистов.

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

Основные вопросы:

1. Организация файлового хранилища: доступ к серверам, мониторинг, бэкап данных.
2. Настройка сервера для FLV-стриминга.
3. Географическая распределенность (зеркала) «своими руками»: концепция и её реализация.
4. Применение географической распределенности к файлам видео.
5. Организация вещаний (трансляций), вещания с большим числом зрителей, ретрансляция. Оптимизация сервера вещаний.
6. Применение географической распределенности к вещаниям.

Оценка значимости и области применимости: Данные вопросы интересны как для видеохостинга, так и для произвольных вариантов вещаний через Internet (например, групповые видеочаты). Схожие проблемы могут возникать у любых ресурсов, имеющих контент довольно большого размера и требующих «быстрой» отдачи их пользователям (например, файлохранилища). Описываемое решение не является полностью уникальным, существуют другие более общие решения для части проблем, например, для файлов это GFS, концепция CDN и т.п. Для вещаний, насколько я знаю, подобные вопросы обсуждаются впервые.

Видео с конференции

Презентация

Полный текст доклада

Доставка видеоконтента пользователям

Материалы

• Эти же тезисы (OpenDocument)
• Презентация на РИТ: Высокие нагрузки (2008) (PowerPoint)
• Полный текст доклада (PDF)

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

• «фикс бага»;
• «закомитил всё, что сделал»;
• «тестовый комит»;
• «исправил опечатку»;
• и т.п.

Почему это плохо?

Один ответ на этот вопрос заключается в том, что лог комита является документацией на код и на изменение. Идеальный лог комита должен позволять по истории изменений конкретного файла понять, что произошло в каждой ревизии, не заглядывая в само изменение (дифф файла). Лог комита может содержать дополнительную мета-информацию: номер тикета, имя человека, который провел code-review, ссылки на другие комиты и т.п.

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

Сделать отступ 10 пикселей между блоками А и Б: был 
создан новый класс blockC, из класса blockA удалено 
padding-bottom: 0.5em, т.к. все paddingи перенесены в 
класс blockC.

Тикет: #1734

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

Что нового дает такой лог комита по сравнению с логом: «закомитил CSS-фикс»?

Мне кажется, основное преимущество состоит в вербализации изменения. И оно даже не для читающего этот лог когда-то, а для пишущего. Процесс программирования сегодня особенно в web-разработке очень быстрый. Мы не пишем псевдо-код, редко рисуем диаграммы, часто между постановкой задачи и выкладкой нового кода на рабочие сервера может пройти несколько часов. За эти часы код не может пройти естественные этапы: отлежаться «пару дней», чтобы автор мог вернуться к нему с «незамутненным взглядом», не успеет пройти code-review, другие разработчики не успеют получить его из репозитория, и т.п. В то время как основная масса кода оказывается лучше изучена и протестирована за время от одного релиза до другого. Но и очень часто мы допускаем ошибки просто в силу того, что упускаем из вида важные детали из-за каких-то еще причин: отсутствия опыта, усталости, частого переключения между задачами и т.п. Как обеспечить качество разработки в таких условиях?

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

Код написан, и вот сейчас подошло время фиксировать изменение в репозитории, а значит, писать лог комита! И это самое время попробовать вербализировать своё изменение на естественном языке. Если ограничиться отпиской вида «фикс бага» или скопировать часть фразы из тикета, процесс вербализации не включается, т.к. мы ничего не формулируем. А давайте попробуем на хорошем русском языке сформулировать что же именно мы изменили, почему мы изменили, какие это имеет последствия (возможно) для другого кода? Для того, чтобы сформулировать точно, что же именно мы изменили, потребуется просмотреть дифф текущего изменения, что замечательно, это фиксирует внимание на каждом блоке изменений в попытке рассмотреть каждую строчку кода, резюмировать изменения общей идеей, не упуская при этом важных деталей. Этот дополнительный взгяд на дифф изменений позволяет найти как простые технические ошибки, как, например, отсутствие докблока, так и нетривиальные – забытые отладочные операторы, изменения, сделанные временно в процессе программирования, «меньше» вместо «больше» и т.п.

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

AVPacket *m_pPacket = (AVPacket *)malloc(sizeof(AVPacket))
while(1)
{
     int ret = av_read_frame(formatCtx, m_pPacket);

     if (ret < 0)
         // error

     if (m_pPacket.stream_index == videoStreamIndex)
     {
         .... avcodec_decode_video ...
     }
 }
 av_free_packet(m_pPacket);
 free(m_pPacket);

Так вот, это неправильно, нужно вызывать av_free_packet после каждого av_read_packet:

AVPacket *m_pPacket = (AVPacket *)malloc(sizeof(AVPacket))
while(1)
{
     int ret = av_read_frame(formatCtx, m_pPacket);

     if (ret < 0)
         // error

     if (m_pPacket.stream_index == videoStreamIndex)
     {
         .... avcodec_decode_video ...
     }
     av_free_packet(m_pPacket);
 }
 free(m_pPacket);

P.S. Может, из текста не совсем понятно, это не бага в самом ffmpeg, это моя программа, используя libavcodec, libavformat (библиотеки ffmpeg), как я написал в начале поста, «текла».

Еду в машине, никого не трогаю. В телефоне симка МТС, которой уже много-много лет. Оператора и телефонный номер сто лет не менял, но последнее время напрягала сумма платежей МТСу (доходило до 2000 руб. каждый месяц при звонках внутри Москвы). Так вот, еду, в телефоне MIP живёт, аська зеленеет. Тут соединение рвётся и MIP делает тщетные попытки переподключиться. Ему это не удается ни за десять ни за двадцать минут. Телефон мой пишет «Нед доступа к сети», что звучит вполне как приговор. Подумал, что сота накрылась в том месте, где я ехал, но сеть не появилась и через час.

Звонок в МТС. После стандартных советов «включите-выключите телефон» следует вердикт: «Скорее всего, сим-карта сломалась». И предлагают «вставить её в другой телефон». Я один был, нет у меня другого телефона. Ну ладно, а где у вас ближайший центр обслуживания, чтобы съездить в субботу?

05.07.08 (суббота)

Лень ехать чинить МТСовскую симку, еду в ближайшую Евросеть – пять минут на машине, предварительно выбрав понравившийся тарифный план Билайн на их сайте. Почему не МТС – потому что было интересно попробовать что-то еще, а вдруг качественнее и дешевле? Отстоял очередь в Евросети плативших за телефон (свободных сотрудников нет), и получил ответ «к этому тарифному плану Билайн больше не подключает». Странно, ну ладно. Выбрал другой, предоплатный тариф. «У нас таких нет в продаже» – получил я ответ. Осталось только развернуться и уйти после такого желания осчастливить клиента контрактом

В следующем торговом центре (еще 10 минут на машине) как назло оказалась опять Евросеть, в ней нашелся нужный тарифный план, и вот я счастливый обладатель Билайна. Приехав домой и разглядев коробку с симкой повнимательнее, осознал, что ей уже год (sic!). И хотя и называется тарифный план так, как я хотел – расценки совсем не те. Окей, звоню в Билайн. «Девушка, а сколько у меня стоит минута?» … «6 руб.» .. «А как мне перейти на новые расценки по этому тарифному плану?». Девушка присылает мне СМС с номером, звоню по нему, на всё соглашаюсь, получаю ответ: «Вы и так находитесь на этом тарифном плане». Хм. Звоню снова, жалуюсь, молодой человек через минуту отвечает: «А у вас контракт не зарегистирован, вот поэтому и нельзя сменить тарифный план. Через семь рабочих дней всё будет хорошо». Отлично, из-за этого у меня еще и не работает управление контрактом через Интернет.

06.07.08 (воскресенье)

За это время обнаружил, что в отличие от МТС и Мегафон, Билайн отлично ловится у меня в квартире, а (о чудо!) в GPRS входит телефон с первой попытки. Прощай МТС (за качество связи).

Проснулся, приходит СМС на Билайн: «Ваш номер заблокирован». Хм, интересно, а ведь вчера 500 рублей кинул и они дошли до счета. Звоню. Девушка выясняет всё, сама удивляется, разблокирует. Говорит что проблема в том, что «мой контракт не зарегистрирован». Кажется, из-за этого все беды.

Продолжаю наслаждаться Билайном и тишиной (новый мой номер почти никто не знает, а старая симка так и лежит мертвая).

07.07.08 (понедельник)

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

Заказываю в МТС бесплатную доставку сим-карты рано утром. Вечером звонят из МТС, но не успеваю подобрать вызов, не перезванивают.

08.07.08 (вторник)

Звонили из МТС, обещали привезти симку, уточняли адрес, он из формы до них дошел в странном виде. Ждём…

09.07.08 (среда)

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

Вставляю симку в телефон – новое чудо «сим-карта не активна». Стоп-стоп-стоп. Звоню в МТС, получаю совет «включить и выключить телефон, подождать». (Видимо, забывают сказать, что надо еще с бубном потанцевать). Матерюсь, меняю симку в телефоне Билайн на МТС и обратно – не помогает. Звоню еще раз – получаю гениальный ответ… Я такого ожидал: «Курьер привез симку слишком быстро, она не успела активироваться!». Отлично, курьер видимо забыл «потупить», как его учили в МТС. Обещают, что заработает через сутки.

10.07.08 (четверг)

МТСовская симка так и не заработала… Снова звоню, жалуюсь… Оператор задумался надолго. Догадывается у меня спросить номер симки… Диктую ему и получаю еще один фантастический ответ: «Вам не эту симку должны были привезти!» Хм, я отвечаю, что другой нет, и она вот такая в красивом красном конверте (про мужиков на фотографии умолчал). Оператор подумал и обещал до вечера всё исправить.

Вечером всё заработало, итак, почти неделя без МТСа…

Кто-нибудь еще хочет пользоваться услугами наших сотовых операторов? А покупать что-либо в Евросети?

P.S. МТС нужен только для того, чтобы установить переадресацию с автоинформатором на Билайн.

Do you have any advice for up-and-coming programmers?

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

Можете что-то посоветовать начинающим программистам?

Изучайте основы программирования: алгоритмы, архитектуру машин, структуры данных и т.д. Не копируйте слепо подходы из одного приложения в другое. Вы всегда должны знать, что вы делаете, быть уверенными, что ваша программа работает, и твёрдо знать, почему она работает. Не думайте, что вы можете предсказать, какой будет индустрия программирования через 5 лет и чем именно придётся заниматься вам, поэтому учитесь более общим и полезным приёмам и подходам. Старайтесь писать код, который лучше, код, который больше соответствует вашим принципам программирования. Работайте так, чтобы программирование в большей степени было профессиональной деятельностью, а не низкоуровневым «хакерством» (программирование – это и ремесло, но не только ремесло). Учитесь на классике в области разработки и с помощью лучших книг, не надо полагаться на «how to» и документацию в онлайне – она недостаточно глубоко затрагивает вопросы программирования.

Проблема №3. Одного мемкеша мало

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

Самый простой алгоритм хеширования вида:

$memcache_server_id = crc32($key) % count($memcache_servers);

начинает «веселиться», когда обнаруживает, что сервер упал. Когда обнаруживается проблема сетевого доступа к серверу, драйвер memcachа убирает его из списка $memcacheservers. При этом count($memcacheservers) изменяется, какая-то часть ключей «сдвигается» на другие сервера, при этом «пропадает» куча кешей (хорошо, если кешей, которые не так жалко потерять, а если речь идёт о сессиях пользователей?).

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

Когда куча ключей теряется, резко начинают перестраиваться кеши, вырастает нагрузка на БД, и т.д., и т.п., то есть падение одного сервера мемкеша заваливает весь «отказоустойчивый» кластер.

Что делать? Есть другие алгоритмы хеширования ключей, устойчивые к удалению/добавлению серверов в пул. Для PHP-шного модуля Memcache это:

ini_set('memcache.hash_strategy', 'consistent');

Проблема №4. Одновременное перестроение кеша несколькими мордами

Если мы выставляем ключу (кешу) некоторое время жизни, рано или поздно, memcache скажет, что такого ключа на сервере нет. А если это «популярный» кеш, например, использующийся на главной странице, то такую ситуацию могут «обнаружить» одновременно несколько морд. И они все попытаются построить этот кеш, то есть они все одновременно отправят запрос в БД, то есть они отправят много запросов в БД, причём за короткий промежуток времени. Конечно, как только первый запрос завершится, морда запишет новое значение ключа и больше новых запросов за этой выборкой не будет. Но мы уже подвергли БД высокой нагрузке, хотя хотели этого избежать при помощи кеширования.

Напрашивается решение: пока одна морда строит кеш, все остальные должны её «подождать». Как это реализовать? Например, с помощью блокировок в том же мемкеше. Перед тем, как начать строить кеш для ключа mykey, прове