Sobes.tech
Назад к вопросам
Junior — Middle
55

Объясните механизм сброса или обновления данных в кэше при изменении источника информации.

Компании, где спрашивали
Код Открытия

Ответ от нейросети

sobes.tech AI

Что хотят услышать интервьюеры:

Важно показать, что кэш всегда должен быть согласован с источником данных, иначе приложение будет отдавать устаревшие результаты. Обычно используют инвалидацию, обновление по событию или стратегию с TTL, чтобы контролировать время жизни данных. На практике выбор механизма зависит от того, насколько критична актуальность и как часто меняется источник.

Определение:

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

Основные подходы:

  • Инвалидация — удалить запись из кэша после изменения данных.
  • Перезапись — сразу положить в кэш обновлённое значение.
  • TTL / time-to-live — автоматически считать данные устаревшими через заданное время.
  • Event-driven update — обновлять кэш по событию из системы, где данные изменились.

Пример использования:

Допустим, в кэше хранится профиль пользователя. Пользователь меняет имя в базе данных, и приложение должно либо удалить старую запись из кэша, либо сразу записать туда новое имя.

cache = {}

def get_user(user_id):
    if user_id in cache:
        return cache[user_id]

    user = load_user_from_db(user_id)
    cache[user_id] = user
    return user

def update_user(user_id, new_name):
    save_user_to_db(user_id, new_name)

    # Вариант 1: инвалидация
    cache.pop(user_id, None)

    # Вариант 2: обновление кэша сразу
    # cache[user_id] = load_user_from_db(user_id)

Пояснение кода:

В этом примере сначала данные читаются из кэша, если они там есть. Если записи нет, данные берутся из базы и сохраняются в кэш.

При изменении пользователя в базе показаны два подхода:

  1. Инвалидация — после записи в БД кэш по user_id удаляется. Следующий запрос заново загрузит актуальные данные из источника.
  2. Обновление — после изменения можно сразу перечитать данные из БД и положить их в кэш, чтобы следующий запрос уже получил свежую версию.

Если код не используется, сам процесс можно описать так:

  1. Меняется источник данных.
  2. Система определяет, какие кэшированные значения затронуты.
  3. Эти записи удаляются или пересчитываются.
  4. При следующем обращении к данным кэш либо отдаёт свежую версию, либо пересоздаётся.

Ключевые моменты:

  • Кэш должен быть синхронизирован с источником, иначе появляются устаревшие данные.
  • Инвалидация проще и безопаснее, но может увеличить нагрузку на источник.
  • Обновление кэша сразу после изменения даёт более свежие данные, но требует аккуратности.
  • TTL помогает автоматически ограничивать “жизнь” данных, но не гарантирует мгновенную актуальность.
  • В распределённых системах особенно важно учитывать гонки, задержки доставки событий и возможную рассинхронизацию.