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

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

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

Смотрите в полноэкранном режиме.

Статья с пошаговой инструкцией по установке memcached под ОС Windows. Скачать дистрибутив для Win32 можно отсюда: http://jehiah.cz/projects/memcached-win32/

Мануал по пользованию memcached из PHP: http://www.php.net/memcache.

Что кэшируем?

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

2. Кэширование результатов запросов, которые очень редко меняются. Например, если вы храните настройки сайта в базе, то при каждой загрузке страницы эти настройки надо получить из базы. Такой запрос отработает моментально быстро, и очевидной необходимости его кешировать нет. Но если выделить с десяток таких запросов, то их суммарное время уже можно считать значительным. При этом нагрузка ложится на часто самое узкое место в производительности сайта — демона базы данных. По-этому, может иметь смысл хранить результаты таких запросов на сервере кэширования. Для такого кэширования подойдет только способ 2 из пункта 1. Кстати, сюда же можно отнести кэширование «статических страниц», которые динамически генерирует CMS.

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

Юзерозависимость

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

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

Чего не хватает в memcache?

Вобщем-то всего там хватает, потому что сама библиотека (представленная как extionsion в php) представляет собой лишь инструмент для хранения кэшированных данных. Чтобы обеспечить удобную работу с кэшем, необходимо надстроить над механизмом хранения контроллер взаимодействия (интерфейс). В первую очередь он должен обеспечить функционал «пространств имен» для создания условий модульной разработки, что очень важно в MVC. Так же он должен обеспечить работу с юзерозависимыми данными через пару «ключ—id пользователя» и соответствующие связанные операции, упомянутые выше. Нужна и возможность пометки данных по принадлежности к некоему классу, чтобы потом очистить сразу весь кэш, относящийся к данному классу (например, при обновлении таблицы, от которой зависит вся хранимая в кэше информация данного класса).

Думаю, что завтра реализую оболочку для API memcached в PHP, которая реализует эти три дополнения, и открою ее для всех желающих.