Серверное кэширование: как разделить слои HTTP и данных

Вы подключили CDN, статика отдается за миллисекунды, но TTFB (Time to First Byte) на страницах каталога, корзины и профиля по-прежнему пробивает секунду.

CDN — это кэширование на границе сети (Edge). Он отлично справляется с картинками и JS, но любые персонализированные или динамические запросы (фильтры, авторизация, корзина) неизбежно проходят сквозь CDN и идут на ваш Origin-сервер. Если на сервере каждый такой запрос заново поднимает PHP-fpm и делает тяжелый SELECT в базу данных — сайт будет тормозить независимо от провайдера CDN.

Решение проблемы — кэширование на самом сервере. Но главная ошибка при его настройке — пытаться выбрать «победителя» между Varnish, Redis и Memcached. Это инструменты для разных слоев архитектуры.

Матрица архитектуры кэша: HTTP vs Данные

Чтобы эффективно снять нагрузку с сервера, кэш необходимо внедрять на двух независимых уровнях.

Varnish: отсекаем запросы до бэкенда

Varnish стоит перед вашим веб-сервером (или работает в связке с Nginx). Его задача — отдать готовый HTML до того, как запрос вообще коснется интерпретатора (PHP/Python) и базы данных.

• Сценарий: Идеален для витрины магазина, новостных порталов и любых страниц, которые выглядят абсолютно одинаково для всех неавторизованных посетителей.

• Ограничение: Категорически не подходит для персонализированного контента (например, личного кабинета).

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

Redis vs Memcached: кэширование внутри бэкенда

Когда запрос пробивает HTTP-кэш (пользователь авторизован или использует динамический фильтр), в работу вступает бэкенд. Чтобы не нагружать реляционную БД (MySQL/PostgreSQL), бэкенд обращается к кэшу объектов.

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

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

Золотое правило архитектуры: Используйте Varnish для кэширования публичного HTML на самом входе, а Redis — для кэширования тяжелых запросов к БД и хранения сессий внутри самого приложения.

Узкие места: о чем молчат гайды

При проектировании серверного кэширования разработчики часто сталкиваются с двумя критическими проблемами:

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

   • Решение: Использование блокировок (mutex) при перегенерации кэша или алгоритмы вероятностного раннего обновления.

2. Инвалидация: Сбросить кэш конкретного товара в Redis при изменении его цены легко. Но найти и сбросить все сгенерированные HTML-страницы каталога в Varnish, где этот товар выводится — сложная задача.

   • Решение: Требуется внедрение системы тегирования кэша (Cache Tags) и настройка прямой связи (webhook/API) между бэкендом и HTTP-акселератором.

Выбор подходящего сервера для таких задач (требования к RAM/CPU) мы подробно разбирали в нашем гайде про сервер для парсинга.

Практика: отсекаем PHP с помощью Nginx и Redis (FastCGI Cache)

Чтобы показать, как кэш работает на уровне сервера без поднятия интерпретатора, ниже приведен базовый пример использования встроенного кэширования Nginx. Эта конфигурация позволяет Nginx самостоятельно обращаться к кэшу и отдавать ответ напрямую, экономя ресурсы CPU.

⚠️ Ограничение среды (когда это не сработает): Приведенный ниже конфиг жестко привязан к маршрутам и cookie-файлам авторизации WordPress. Если вы используете Laravel, Symfony или кастомный фреймворк, регулярные выражения в блоке skip_cache необходимо переписать под ваши сессионные пути. В противном случае вы закэшируете приватные данные из личного кабинета.

Конфигурация Nginx:

# В блоке http определяем зону кэша
fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

# В блоке server отключаем кэш для динамики
set $skip_cache 0;

if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|^/feed/*|/tag/.*/feed/*|index.php|/.*sitemap.*\.(xml|xsl)") {
    set $skip_cache 1;
}

if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
    set $skip_cache 1;
}

# В блоке location PHP передаем управление
location ~ \.php$ {
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    fastcgi_cache WORDPRESS;
    fastcgi_cache_valid 200 60m;
    
    fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
    include fastcgi_params;
}