Что такое TTL (Time to Live) в контексте кеширования?

TTL (Time to Live, Время жизни) — это параметр, определяющий максимальный срок, в течение которого запись (например, результат запроса, DNS-запись, значение ключа) может храниться в кеше, прежде чем будет считаться устаревшей и потребует обновления из исходного источника.

Принцип работы и цели:

1. Кеширование: При первом запросе данные извлекаются из медленного источника (БД, внешний API) и сохраняются в быстром хранилище (Redis, Memcached, CDN, локальный кеш) с установленным TTL.
2. Повторный запрос: Последующие запросы в течение срока TTL обслуживаются из кеша, что резко снижает нагрузку на источник и улучшает время отклика.
3. Инвалидация: По истечении TTL запись автоматически помечается как недействительная. Следующий запрос попадет в источник (cache miss), и цикл повторится.

Практические примеры настройки TTL:

В Redis:

# Установка ключа 'user:1001:profile' со значением на 300 секунд (5 минут)
SET user:1001:profile '{"name":"Alice"}' EX 300

# Установка TTL для существующего ключа
EXPIRE api:rates 60

# Проверка оставшегося времени жизни
TTL user:1001:profile

В конфигурации CDN (например, CloudFront) или обратного прокси (NGINX):

# NGINX: кешировать ответы бэкенда с кодом 200 на 1 час
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m;
location /api/ {
    proxy_cache my_cache;
    proxy_cache_valid 200 1h; # TTL = 1 час для ответов 200 OK
    proxy_pass http://backend;
}

Критерии выбора TTL:

• Короткий TTL (секунды/минуты): Для очень динамичных данных (курсы валют, статус заказа). Гарантирует актуальность, но увеличивает нагрузку на источник.
• Длинный TTL (часы/дни): Для относительно статичных данных (страницы «О нас», списки городов). Максимально разгружает источник, но рискует отдавать устаревшие данные.
• Стратегии: Часто используют комбинацию — базовый TTL и принудительная инвалидация кеша при изменении данных (cache purge).