Паттерны кеширования и способы инвалидации кеша

Паттерны кеширования для чтения

1. Пользователь отправляет запрос на чтение данных. Приложение проверяет кеш. Если данные найдены, происходит попадание в кеш.
2. Если данные не найдены, происходит кеш-промах и приложение отправляет запрос к базе данных.
3. Пользователь получает ответ. Данные заносятся в кеш.

• Устойчивость к сбоям кеша Если сервер кеша выходит из строя, система всё равно может работать, обращаясь напрямую к базе данных. Хотя это всё равно нежелательно, ведь увеличение нагрузки на базу данных может привести к выходу её из строя. В таких случаях кеш лучше реплицировать.
• Модель данных в кеше может отличаться от модели данных в БД Это позволяет выполнить запрос к БД, объединяющий несколько таблиц, и сохранить его в кеше под одним ключом. Так можно избежать дальнейшего выполнения сложной логики.

• Низкая скорость обновления данных Обрабатываются только операции чтения, а не записи. Следовательно, любая операция записи всегда будет миновать кеш и выполняться непосредственно в базу данных, что считается медленной операцией.
• Несогласованность данных в кеше с базой данных Запись делается в базу данных, но не в кеш — в нём всё ещё старые данные. Чтобы справиться с этим, разработчики обычно используют параметр TTL для содержимого кеша и продолжают отдавать потенциально устаревшие данные до истечения TTL. Если нужно гарантировать свежесть данных, можно вручную инвалидировать кеш, используя одну из стратегий инвалидации, которые рассмотрим позже в этом уроке.

Read-Through

// Псевдокод реализации
// выполняется кешем, если кеш пустой
cache.onmiss = (key) => {
  return db.get(key) // return data from the database
};

const data = cache.readThrough(key, data, ttl); 

• Меньшая сложность приложения и низкая вероятность ошибок
  Кеш не обновляется на стороне приложения — теперь это ответственность базы данных. В стратегии Read-Through кеш является вспомогательным сервисом БД и приложению не нужно обновлять кеш при чтении.

• Кеш-промах при первом запросе Когда данные запрашиваются в первый раз, это всегда приводит к кеш-промаху и влечёт за собой дополнительное время на загрузку данных в кеш. Это можно исправить с помощью «прогрева кеша» — ручной отправки запросов на старте приложения, чтобы данные из БД успешно подгрузились в кеш.
• Ограничения на выбор модели данных в кеше Модель данных в кеше должна быть идентична модели базы данных.
• Чувствительность к ошибкам в отличие от Cache-Aside Из-за того, что к базе обращается не приложение, а кеш, в случае ошибки данные будет брать неоткуда. И вернётся запрос с ошибкой. В паттерне Cache-Aside приложение в случае ошибки само отправит запрос к БД.

Refresh-ahead

• Низкая стоимость чтения данных из БД;
• Согласованность записей кеша, к которым часто обращаются пользователи;
• Высокая чувствительность к задержкам.

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

//псевдокод реализации
setInterval(()=> {
     let data = db.read(key);
     cache.set(key,data);
},10000); 

Паттерн Write-Through

1. Приложение обновляет кеш.
2. Кеш немедленно обновляет базу данных.
3. База данных обновляется в соответствии с задачей.
4. Ответ об успешной операции возвращается клиенту.

// Псевдокод 
function updateData(id, data) {
  // выполняется после сохранения записи в кеше
  cache.writeThrough(id, data, cache.defaultTTL, (key, value) => {
    return db.save(key, value) // сохранение в базу
  });
}
// Сначала обновляем в бд
function updateDataAnotherWay(id, data) {
  // сначала в базе
  const record = db.findAndUpdate(id, data)
  // потом в кеше
  cache.set(customerId, record, cache.defaultTTL)
} 

• Данные между кешем и базой данных всегда будут синхронизированы. Это исключает возможность неконсистентности кеша и его инвалидацию.

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

Паттерн Write-Behind

1. Приложение обновляет кеш.
2. Кеш возвращает клиенту ответ.
3. Кеш планирует асинхронную задачу на обновление базы данных.
4. База данных обновляется в соответствии с задачей.

//псевдокод реализации
function updateData(id, data) {
  await cache.set(id,data); //ждём обновления в кеше
  async db.save(id,data); //асинхронно обновляем бд
  return data;
}
 

Способы инвалидации кеша

Временная инвалидация

Инвалидация, основанная на запросах

Инвалидация на основе изменений

Программная инвалидация

Инвалидация по ключу

Итоги

• Паттерн Cache-Aside лучше всего подходит для приложений с большим объёмом запросов на чтение, ведь в рамках этой стратегии оптимизируется именно чтение.
• Паттерн Read-Through устроен так, что к базе данных обращается именно кеш, а не приложение.
• Паттерн Refresh-ahead имеет низкую стоимость чтения данных, но кеш должен работать без ошибок, поскольку в случае ошибки это приведёт к неконсистентности.
• Паттерн Write-Through применяет похожую на Read-Through логику для операций записи. Любая операция записи проходит и через кеш, и через базу данных последовательно.
• Паттерн Write-Behind выполняется быстрее, поскольку перед возвратом ответа приложению необходимо обновить только кеш. Пользователю не нужно ждать ответа базы данных: её обновление произойдёт в фоновом режиме.
• В реальных приложениях используют смешанный подход из нескольких паттернов кеширования. Чаще всего это комбинация Read-Through и Write-Through.
• Очистку данных называют инвалидацией. Способов инвалидации кеша несколько: временная и программная инвалидация, инвалидация на основе запросов, на основе изменений и по ключу. Каждый способ имеет свои особенности и подходит для определённых задач.