Сколько хранится кеш?

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

Если обобщить, то кеш хранится столько, сколько задано политикой инвалидации (обновления), и пока для него есть место в хранилище. Давайте разберем подробно.

Основные политики определения срока жизни кеша (TTL)

Срок хранения обычно определяется одной из следующих стратегий:

1. Фиксированный TTL (Time To Live):

    *   Самый распространенный подход. Для каждой записи в кеше задается абсолютное время "смерти" с момента ее создания.
    *   **Пример**: Кеш данных о погоде обновляется каждые 10 минут. `TTL = 10m`.
    *   **Плюсы**: Простота реализации и понимания.
    *   **Минусы**: Может приводить к "толчкам" (thundering herd) — если множество ключей истекает одновременно, это создает пиковую нагрузку на источник данных (БД, API).

```yaml
# Конфигурация в Redis или приложении
cache_config:
  default_ttl: 600  # 10 минут в секундах
  user_profile_ttl: 3600 # 1 час для профилей
```

2. Скользящий TTL (Sliding Expiration):

    *   Время жизни записи обновляется (сдвигается) при каждом обращении к ней. Запись "жива", пока ее используют.
    *   **Идеально подходит для** кеширования сессий пользователей или часто запрашиваемых данных.
    *   **Пример**: Сессия пользователя в приложении истекает через 30 минут неактивности.

```python
# Псевдокод логики скользящего TTL
def get_from_cache(key):
    data = cache.get(key)
    if data:
        cache.expire(key, 1800)  # Сбросить TTL на 30 мин при каждом чтении
        return data
    else:
        data = fetch_from_database(key)
        cache.set(key, data, ttl=1800)
        return data
```

3. Явная инвалидация:

    *   Кеш хранится до тех пор, пока явное событие в приложении не приведет к его удалению или обновлению.
    *   **Пример**: Кеш списка товаров в категории хранится до тех пор, пока администратор не добавит новый товар. После этого события кеш для этой категории принудительно сбрасывается.
    *   **Плюсы**: Данные в кеше всегда актуальны с точки зрения бизнес-логики.
    *   **Минусы**: Требует сложной системы отслеживания зависимостей (cache invalidation).

Ключевые факторы, влияющие на выбор TTL

Принимая решение, инженер анализирует:

• Частота изменения данных (Волатильность): Данные рейтинга акций (TTL=1с) vs. справочник стран мира (TTL=30 дней).
• Требования к актуальности (Сonsistency): Насколько критично показывать устаревшие данные? Для финансовых операций — недопустимо, для ленты новостей — приемлемо несколько секунд.
• Стоимость получения данных (Cost of Computation/IO): Чем дороже запрос к БД (тяжелые JOIN, агрегации), тем дольше может жить кеш, чтобы окупить затраты на его создание.
• Объем доступной памяти: Если память кеша ограничена, используются алгоритмы вытеснения (LRU - Least Recently Used, LFU - Least Frequently Used), которые удаляют записи, даже если их TTL не истек, чтобы освободить место для новых.
• Шаблон доступа: Если данные запрашиваются "пачками" (например, отчет в начале часа), эффективен фиксированный TTL. Для постоянного фонового спроса — скользящий.

Практические примеры из реального мира

• CDN для статики (JS, CSS, изображения): TTL = от 1 часа до 1 года. Инвалидация через изменение имени файла (хеш в URL).
• Кеш веб-страницы (Full Page Cache): TTL = 1-5 минут для главной страницы, TTL = 1 час для страницы "О компании".
• Кеш результатов поиска/рекомендаций: TTL = 1-10 минут. Баланс между актуальностью каталога и производительностью.
• Кеш сессий пользователя: TTL = 20-30 минут скользящего типа.

Роль QA Engineer в работе с кешем

Инженер по обеспечению качества должен не только знать теорию, но и уметь тестировать поведение кеша:

1. Проверка корректности TTL: Убедиться, что данные действительно обновляются по истечении заданного времени.
2. Тестирование инвалидации: Проверять сценарии, когда кеш должен сброситься явно (после редактирования данных).
3. Тестирование на согласованность (Consistency): Не приводит ли кеш к тому, что пользователь видит устаревшие данные там, где это критично?
4. Нагрузочное тестирование: Проверять, как ведет себя система при массовом истечении TTL (проблема "толчка").

Итог: Продолжительность хранения кеша — это настраиваемый параметр, который является результатом анализа требований к актуальности данных, паттернов доступа и ресурсных ограничений. "Правильный" TTL — это тот, который обеспечивает баланс между производительностью системы и согласованностью данных, приемлемый для конкретного бизнес-контекста.