Стратегии кэширования

Стратегия кэширования — это схема разводки двух путей

Когда ставишь кэш перед медленным хранилищем, надо ответить на два независимых вопроса. При чтении: кто идёт в базу при промахе кэша — приложение или сам кэш? При записи: куда попадает новое значение — в кэш, в базу или в оба, и в каком порядке? Именованные стратегии — cache-aside, read-through, write-through, write-back, write-around — это просто небольшой набор разумных ответов на эти два вопроса. Это не флажки, а сам поток данных, и выбор одной фиксирует твою гарантию свежести, штраф за промах и поведение при смерти узла кэша.

Пять стратегий делятся чисто: cache-aside и read-through — паттерны пути чтения (как данные попадают в кэш), а write-through, write-back и write-around — паттерны пути записи (что запись делает с кэшем). Реальные системы комбинируют по одному из каждого — самая частая боевая пара — cache-aside на чтении с write-around или TTL на записи.

К концу урока ты поймёшь, какой именно выбор сделала команда из вступления — и как делать его осознанно для своих данных.

Cache-aside (lazy loading): оркестрирует приложение

В cache-aside — AWS зовёт это lazy loading — логикой владеет приложение. При чтении: спроси кэш; при попадании верни; при промахе сходи в базу, запиши результат в кэш и верни. Кэш — тупой key-value ящик, ничего не знающий про твою базу.

ЧТЕНИЕ (cache-aside):
  v = cache.get(key)
  if v is null:               # промах
      v = db.read(key)        #   поход в БД
      cache.set(key, v, ttl)  #   заполнить
  return v

Достоинства — ровно те, что перечисляет AWS: кэшируются только запрошенные данные (рабочий набор заполняется естественно, ты не греешь то, что никто не читает), и сбой узла переживаем — свежий пустой узел просто даёт промахи, которые его заполняют, с деградацией задержки, но без сбоя. Цена: каждый промах — штраф в три похода (промах кэша, чтение БД, запись в кэш), и поскольку при изменении базы кэш не обновляется, кэшированные значения устаревают, пока не добавишь TTL или инвалидацию. Это устаревание и есть баг из вступления.

Read-through: оркестрирует кэш

Read-through переносит логику промаха в слой кэша (или библиотеку/провайдер перед ним). Приложение всегда зовёт только cache.get(key); при промахе сам кэш грузит из базы, сохраняет и возвращает. Поток данных идентичен cache-aside — разница в том, кто пишет код. Read-through централизует логику загрузки, чтобы все вызывающие вели себя одинаково и нельзя было выкатить сервис, забывший заполнить кэш при промахе; плата — нужен провайдер кэша с поддержкой этого и теряется свобода формировать каждый запрос.

Три стратегии записи: куда ложится запись

Когда ты трогаешь путь записи, ты решаешь не просто куда сохранить данные, а насколько кэш останется честным, какую производительность получишь и чем рискуешь при сбое. У этого решения есть имя. На пути записи вопрос — что write(key, value) делает с кэшем. Три ответа:

• Write-through — пиши кэш и базу синхронно, на каждой записи. Кэш никогда не устаревает (обновляется вместе с БД), но каждая запись платит два похода, и кэш заполняется данными, которые могут вообще не прочитать (cache churn) — поэтому write-through обычно идёт с TTL, вытесняющим непрочитанный мусор. AWS отмечает компромисс ровно так: записи замедляются, но пользователи терпят задержку записи лучше, чем чтения.
• Write-back (write-behind) — пиши кэш сейчас, верни вызывающему и сбрось в базу асинхронно (батчем, позже). Это даёт минимальную задержку записи и поглощает всплески записи, склеивая много обновлений в меньше походов в БД. Опасность жестокая: если узел кэша умрёт до сброса, эти подтверждённые записи пропадут. Write-back меняет надёжность на скорость, поэтому подходит метрикам, счётчикам и просмотрам — не деньгам.
• Write-around — пиши только базу, минуя кэш; значение войдёт в кэш позже, лениво, при следующем чтении (через cache-aside). Это избегает забивания кэша данными с интенсивной записью, которые скоро не читают, ценой гарантированного промаха на первом чтении после записи. Подходит данным «записал-раз-читаю-может-быть» вроде логов.

Вместе эти три стратегии означают, что ты меняешь задержку записи, надёжность и свежесть между собой. Когда встретишь write-back в проектировании, первый вопрос — какие именно данные мы можем позволить себе потерять, если узел упадёт до сброса?

Консистентность: что обещает и нарушает каждая стратегия

Весь смысл выбора в том, что каждая стратегия даёт своё обещание свежести:

• Cache-aside / write-around / read-through все допускают устаревшие чтения между изменением БД и следующим обновлением кэша — им нужен TTL или явная инвалидация, чтобы ограничить устаревание. Это частый, принятый компромисс: пара секунд устаревания за огромную пропускную способность чтения.
• Write-through — единственная, кто держит кэш непрерывно консистентным с БД на записях — но она не защищает от обновления, обходящего кэш (батч-задача, второй сервис, пишущий прямо в БД), что тихо возвращает устаревание.
• Write-back неконсистентна с БД по дизайну во время окна сброса и рискует потерей данных при сбое кэша — самая сильная производительность, самая слабая надёжность.

Senior-формулировка: нет варианта «свежо, быстро и надёжно»; ты выбираешь, чем из трёх пожертвовать, для каждого класса данных. Цены и балансы хотят write-through или явной инвалидации; список трендов норм на cache-aside с коротким TTL; счётчик просмотров — хрестоматийный write-back.