Обновление кеша пререндеринга
Страницы с пререндерингом грузятся молниеносно. Но есть подвох: они не обновляются автоматически. Когда данные меняются в базе, рендеринг страницы остаётся старым — кеш показывает пользователю устаревший контент. На блоге новая статья не видна. В магазине цена обновилась, а кеш показывает старое значение. Обновление кеша пререндеринга — решение, позволяющее использовать оба преимущества: скорость при рендеринге и свежесть контента. В статье разберем стратегии обновления — от простых примеров до решений для приложений под нагрузкой. Главное — баланс между производительностью рендеринга и актуальной информацией для пользователя.
Представьте ресторан, который вывесил на стену ламинированное меню. Оно грузится в голове посетителя мгновенно — свежее, быстро. Но повар давно переделал половину блюд, убрал три позиции, добавил новые. Меню на стене не обновилось. Гости заказывают несуществующие блюда, повар их не готовит. Уходят в другой ресторан. Ресторан теряет деньги.
Так работает статический html при изменении данных. Сначала это чудо — готовый html грузится за миллисекунды. Потом это боль, когда данные устаревают. Кеш показывает снимок прошлого.
Почему это больно на практике
Запустили блог. Написали статью в 3 часа ночи. Пубдиковали. Проверили главную — статья не видна. Проверили ещё раз через час — всё ещё нет. В базе данных она живёт, прямой поиск находит. Но главная показывает вчерашний список.
Статья не получает трафик. Тысячи потенциальных читателей видят только старые посты. Это происходит потому, что готовый html главной не обновляется самостоятельно. Никакой процесс рендеринга не запустился. Кеш просто лежит с устаревшей информацией, пока вы не вызовете обновление контента вручную.
Где это переходит в убытки: три реальных сценария
Интернет-магазин. Цена товара упала с 5000 рублей до 3000. В базе данных стоит 3000. Кеш показывает 5000. Покупатель видит высокую цену, уходит к конкуренту. Умножьте это на тысячи посетителей в день — конверсия падает на 2-3%. За неделю можно потерять миллионы рублей, потому что кеш не обновляется автоматически.
Каталог товаров. Товар раскупился. В БД статус "недоступен". Кеш всё ещё показывает "в наличии". Покупатели заказывают несуществующие вещи. Вы часами отменяете заказы, делаете возвраты. Система выглядит ненадёжной.
Новостной сайт. Крупная новость в 10 утра. На главной вчерашние новости — потому что статический html не обновлён. Читатели ищут свежее в других источниках. Трафик уходит конкурентам.
Когда приложение получает тысячи запросов в минуту, даже несколько часов без обновления контента могут обойтись в миллионы упущенной выручки.
Нагрузка на сервер при обновлении контента
Здесь начинается технический слой. Когда вы обновляете кеш, система не просто берёт готовый html из буфера. Она перезапускает повторный рендеринг. Это означает запросы к базе данных — может быть 5, может быть 50 запросов на одну страницу. Если одновременно обновляется 500 страниц, нагрузку на сервер может возрасти в разы.
Пример: блог с 500 статьями. Вы настроили кеш на 24 часа. В полночь полный список страниц теряет актуальность одновременно. Система начинает их переделывать. За 20 секунд идёт 500 запросов к БД вместо обычных 10 в секунду. База не справляется. Все переделываются медленно. Пользователи, открывающие новые страницы, получают задержку. Это cache stampede — когда весь кеш требует перегенерации залпом.
Edge cases высоконагруженных систем
На высоконагруженных приложениях проблемы обостряются.
Race conditions. При параллельных обновлениях один процесс генерирует кеш на момент времени T, другой на T+100ms. В базе появились новые данные. Они оба записывают результат. Теперь в памяти смешанные данные: часть старая, часть новая. Пользователь видит странный результат.
Несогласованность распределённого кеша. Если Redis на трёх узлах и обновилось только два, третий ещё хранит старые данные. Разные пользователи получают разный контент.
Каскадные отказы. Webhook для обновления работает асинхронно. Если очередь запросов зависает, события накапливаются. Потом приходят залпом. Сервер перегружается. Становится медленнее. Webhook обрабатываются ещё медленнее. Система ломается.
Когда обновлять: выбор времени жизни
Универсального ответа нет. Это зависит от типа контента и приложения.
Для статичных страниц (информация о компании) время жизни может быть неделя. Контент меняется редко, нагрузка — минимальная.
Для новостей и каталогов — часы или минуты. Актуальность критична.
Для цен и статуса товаров — минуты или даже секунды. Неправильная цена стоит денег прямо.
Для лент и аналитики — иногда секунды.
Когда вы выбираете время жизни, вы балансируете между тремя факторами: насколько свежий контент нужен пользователю, какую нагрузку может выдержать сервер и как часто нужно обновлять данные. Нет идеального решения — только оптимальное для вашего случая.
В следующих разделах разберём конкретные стратегии, которые помогают найти этот баланс. От простых способов до решений для высоконагруженных систем, где нужно гарантировать консистентность и избежать ошибок, даже когда приложение получает миллионы запросов в день.