Кеширование данных, а не их повторная генерация — один из фундаментальных принципов высокопроизводительных систем. Однако большинство разработчиков задумываются о нём лишь в виде подключения Redis или работы с браузерным кешем, упуская возможность системного подхода. Рассмотрим многоуровневую модель кеширования как единую архитектурную концепцию.
Зачем много уровней?
Современное приложение обрабатывает запросы через десятки слоев: от базы данных до JavaScript в браузере. Каждый переход между этими слоями создает задержку. Многоуровневое кеширование сокращает количество переходов путем сохранения данных на разных уровнях:
- Уровень браузера
- Уровень CDN/Обратного прокси
- Уровень приложения
- Уровень базы данных
Уровень браузера: больше, чем Cache-Control
Мета-теги и HTTP-заголовки — основа, но возможности современных браузеров шире. Рассмотрим практический пример Cache API в Service Worker:
// service-worker.js
const CACHE_NAME = 'app-v1';
self.addEventListener('fetch', event => {
event.respondWith(
caches.match(event.request)
.then(response => {
// Возвращаем кешированный ответ, если найден
if (response) {
return response;
}
// Делаем сетевой запрос
return fetch(event.request).then(response => {
// Клонируем ответ
const responseClone = response.clone();
// Кешируем только успешные GET-запросы
if (event.request.method === 'GET' && response.status === 200) {
caches.open(CACHE_NAME).then(cache => {
cache.put(event.request, responseClone);
});
}
return response;
});
})
);
});
Но настоящая мощь реализуется через стратегию Cache-First с фоновым обновлением:
self.addEventListener('fetch', event => {
if (event.request.url.includes('/api/data')) {
event.respondWith(
caches.open('api-cache').then(cache => {
return cache.match(event.request).then(cachedResponse => {
const fetchPromise = fetch(event.request).then(networkResponse => {
cache.put(event.request, networkResponse.clone());
return networkResponse;
});
return cachedResponse || fetchPromise;
});
})
);
}
});
CDN и обратные прокси: кеширование на границе сети
Конфигурация Nginx для кеширования статических ресурсов — база, но для API нужны продвинутые схемы. Пример для кеширования API-ответов в Fastly (CDN):
sub vcl_recv {
if (req.url.path ~ "^/api/products") {
# Кешируем GET-запросы на 5 минут
if (req.method == "GET") {
set req.ttl = 5m;
}
}
}
sub vcl_backend_response {
if (bereq.url.path ~ "^/api/products") {
// Автоматическая инвалидация при мутациях
if (beresp.http.Cache-Control ~ "no-cache") {
set beresp.ttl = 120s;
set beresp.uncacheable = true;
return(deliver);
}
set beresp.ttl = 30m;
set beresp.grace = 1h;
}
}
Ключевые параметры:
beresp.grace: разрешает обслуживать устаревший кеш пока идет фоновое обновлениеstale-while-revalidate: аналогичный HTTP-заголовок для браузеров
Техника сюрприз: Связь между CDN и сервером через ETag для предотвращения передачи одинаковых данных.
Уровень приложения: запросы к БД и Redis
Типичная ошибка: кеширование всего подряд без учета паттернов доступа. Эффективная стратегия для ORM:
# Пример для Django ORM с Django Cacheops
from cacheops import cached_as
@cached_as(Product.objects.filter(active=True), timeout=60*15)
def get_active_products():
return list(Product.objects.filter(active=True).select_related('category'))
Но что при изменении? Рассмотрим паттерн Write-Through Cache:
// Node.js + Redis API
const updateProduct = async (id, data) => {
const updated = await db.query('UPDATE products SET ... RETURNING *', [id, ...]);
// Обновление кеша синхронно с записью
await redis.set(`product:${id}`, JSON.stringify(updated));
// Инвалидация агрегированных данных
await redis.del('active_products');
await redis.del('products_by_category');
return updated;
};
// Read-Through функция
const getProduct = async (id) => {
let product = await redis.get(`product:${id}`);
if (!product) {
product = await db.query('SELECT * FROM products WHERE id = $1', [id]);
await redis.setEx(`product:${id}`, 3600, JSON.stringify(product));
}
return product;
};
Критические нюансы:
- Сериализация JSON дороже, чем proto или MessagePack
- TTL должен зависеть от частоты изменений
- Используйте pipelining для множественных операций
- Рассмотрите Redis в режиме LRU против TTL для флуд-запросов
Инвалидация: когда кеш болит
Проектирование системы инвалидации сложнее разработки кеширования. Методы:
- Tag-Based Invalidation: Привязка записей кеша к тегам
# При обновлении товара
redis.sadd('invalidated_tags', `product:${id}`)
# При чтении
if (redis.sismember('invalidated_tags', cache_key)) {
redis.del(cache_key)
}
-
Event-Driven: Канал с уведомлениями через Redis Pub/Sub или Kafka
-
Versioned Keys: Ключи с хешем данных (
user:{id}:{hash})
Для распределенных систем используйте репликацию задержки (запись на мастера, чтение со слейва с кешированием). Это позволит выдерживать буст без нагрузки на основную БД.
Баланс: consistency vs performance
- Системы с высокими TPS: Кеш L1 в памяти процесса + Redis L2
- Высокая консистентность: Write-through + bloom фильтры
- Аналитика: Счетчики попаданий в кеш >= 80% считаются эффективными
Мониторинг — обязательный элемент. Инструменты:
- Grafana с разбивкой по слоям кеша
- REDIS INFO keyspace_misses/keyspace_hits
- HTTP-метрики: Cache-Control: hit,miss
Заключение
Многоуровневое кеширование — не просто localStorage.setItem() и пара настроек Nginx. Это системный подход, требующий:
- Анализа шаблонов доступа для каждого типа данных
- Проектирования стратегий инвалидации
- Инструментирования всех уровней
- Балансировки между свежестью данных и нагрузкой
Неправильное кеширование усугубляет проблемы производительности, тогда как продуманная архитектура может снизить нагрузку на бэкенд на порядки при росте трафика. Начинайте проектирование с вопросов: "Через сколько слоев проходит этот запрос?" и "Где этот результат может быть сохранён?". Ответ на них — основа производительных приложений.