Тезисы

Вступление

Каждый разработчик web приложений рано или поздно сталкивается с довольно типичной проблемой: перед ним стоит задача построить фабрику по производству омнониевых торсиометров.
Фабрика производит омнониевые торсиометры очень быстро, но для калибровки прибора (как известно) необходим омноний, за которым приходится летать на Андромеду.
Пока корабль летит до Андромеды, фабрика простаивает.
Самый очевидный выход из ситуации - построить склад омнониума прямо рядом с фабрикой.

Терминология кэширования

В связи решением построить склад возникает ряд проблем:
Вырастает сложность предприятия. Нужно организовать доставку на склад и со склада, вести складской учет, и т.д.
- Cклад ограничен по объему (cache size). Слишком много омнониума привезти нельзя
- Для калибровки необходимо быстро найти образец омнониума нужной формы и породы (cache hit / miss)
- Омнониум быстро портится (freshness), а испорченным омнониумом торсиометры калибровать нельзя (stale data). Сначала нужно проверить (validation) пригодность, и выбросить просроченный омнониум со склада (invalidation)
- Иногда случается обидная ситуация - корабль прилетает раньше, чем фабрика успеет израсходовать весь омнониум. Склад переполняется, и приходится выбрасывать ещё годный омнониум, чтобы освободить место для новоприбывшего (eviction).

Выбор места для кэширования в WEB

Браузер <-> Кэш браузера <-> Сервер
Браузер <-> Кэш браузера <-> Proxy / CDN <-> Сервер
Браузер <-> Кэш браузера <-> Proxy / CDN <-> Сервер <-> Кэш(и) сервера

Выбор данных для кэширования

Кэширование эффективно только при "хороших" данных.

Бесполезно кэшировать часто изменяющиеся данные.
- Объем кэша всегда ограничен. Кэшировать нужно 20% данных, которые используются 80% времени.
- Нужно учитывать размер данных. Иногда доставка данных из кэша делает кэширование бессмысленным. Например: хранить в памяти 3Gb данных, которые вычитываются по сети, со скоростью 1Mb/s

Хорошие кандидаты для кэширования:
- Небольшие картинки: лого, аватары, пр.
- Java script / CSS / иногда HTML страницы целиком.
- Внутренние объекты бизнес-логики
- Временные данные: сессии, статистику

Кэширование на стороне бэкенда

Опять-таки, кэш можно разместить в разных местах, или сразу в нескольких

HTTP Server cache

Релевантные HTTP Headers
- Expires:
- Cache-Control:
- Etag:
- Last-Modified:
- Content-Length:
- Vary:

Прямо в коде бэкенда
- Хранить во внутренней структуре используемного ЯП (dict / map / HashTable / unordered_map / etc.)
- Использовать библиотеки (cachelot)

Отдельный кэширующий сервис

Основное преимущество - доступен сразу для нескольких приложений backend.

Пара слов о memcached

Key value storage. Expiration. Flags.

set / get / add / replace / delete

Пара слов о Redis

Структуры: String / List / Set / Hash / Sorted Sets

Почему noSQL подобные кэши - это удобно

За счет K-V структуры очень высокая скорость get / set операций.

С помощью K-V можно представить любые данные (чаще даже проще, чем в реляционных СУБД).

account:311:some.key = "Some value"

Для кэша это важно, т.к. данные, как правило, плохо структурированные, или очень разнородные.

Упрощается внутренняя структура кэша - понижается шанс ошибок, порчи данных и пр.



Использование Memcached в архитектуре бэкенда
Настройка и общие паттерны использования

Много одновременных сессий
Batch запросов
Настройка потоков memcached (-t)
Memcached как in-memory хранилище временных данных (режим консистентного хранилища -M)

Статистика

Чтение и расшифровка статистики. Как реагировать на различные показатели.


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

Варианты архитектур

routing на стороне клиента (например libketama)
Brocker (например mcrouter) упрощает общую архитектуру , дает пространство для maintenance
Что такое constent hashing и для чего он нужен.

Пара слов про DHT.


Проблема консистентности данных

Chain replication

Share nothing