День 1475. #ЗаметкиНаПолях
Стратегии Кэширования на Стороне Сервера. Начало
Кэширование — это технология, позволяющая хранить данные таким образом, чтобы доступ к ним был невероятно эффективным. Более быстрое чтение приводит к увеличению скорости работы приложений, поэтому почти каждое приложение, которое должно обеспечивать высокую производительность, использует какой-либо тип кэша.

Кэширование существует на разных уровнях
- Уровень клиента (например, в браузере), чтобы избежать лишних обращений к серверу: так кэшируются изображения, файлы CSS и JavaScript.
- Уровень инфраструктуры (например, CDN). CDN — эффективный способ хранения статических ресурсов: браузерам по-прежнему приходится обращаться к серверу для их загрузки, но вместо вызова «основного» приложения они вызывают CDN для получения статических ресурсов, позволяя основному приложению обрабатывать запросы, требующие динамических данных.
- Уровень приложения. Если вам нужно обслуживать данные, которые не меняются очень часто, вы можете кэшировать их, чтобы избежать лишних обращений к источнику данных, которым обычно является БД или внешний API.

Рассмотрим самые распространённые стратегии кэширования в приложении.

1. Сторонний кэш (Cache-aside): кэш и БД не взаимодействуют
Cache-aside или ленивое кэширование используется наиболее часто. Читаем из кэша; если элемент не существует, извлекаем его из источника и добавляем в кэш, чтобы в следующий раз, когда приложение попытается извлечь тот же элемент, он уже присутствовал в кэше.

Преимущества
- Отлично подходит для рабочих нагрузок с большим объёмом чтения: каждый раз, когда происходит промах кэша, вы добавляете недостающие данные в кэш, поэтому при следующей попытке доступа к тем же данным они уже будут доступны.
- Если кэш недоступен, приложение всё равно работает: вместо того, чтобы запрашивать кэш, придётся каждый раз обращаться к БД; приложение станет медленнее, но будет работать.
- Не всё должно быть в кэше: используя Cache-aside, вы храните в кэше только те данные, которые кому-то нужны.

Недостатки
- Первый доступ будет медленнее (придётся вызывать и кэш, и БД).
- Если данные в БД меняются (например, из-за того, что другое приложение обновляет те же таблицы), у вас будут противоречивые данные — это означает, что вы должны найти способ вытеснять из кэша данные, обновлённые другими сервисами.

2. Сквозное чтение (Read-through): кеш знает, как запрашивать БД
В кэше есть компонент, который позволяет ему обращаться к БД и извлекать недостающие данные.

Для популярных систем кэширования, вроде Redis, существуют плагины, позволяющие им обращаться к БД. Другие системы, такие как NCache, позволяют вам реализовать такие модули в вашем приложении. Для NCache вы можете создать класс, который реализует IReadThruProvider, и настроить NCache для использования его при попытке чтения данных.

Преимущества
- Оптимально для рабочих нагрузок с большим количеством операций чтения: данные всегда доступны, а данные с истекшим сроком действия обновляются автоматически.
- Уменьшает код приложения и упрощает управление: ваш код больше не запрашивает БД, всё управляется через кэш.

Недостатки
- Единая точка отказа. Каждый раз, когда нужно получить какие-то данные, они должны пройти через кэш. Если по какой-то причине кэш недоступен, приложение не сможет получить данные.
- Тесная связь между кэшем и БД: если модель в БД изменится, мы должны обновить код запроса к БД в кэше.

Окончание следует…

Источник: https://www.code4it.dev/architecture-notes/caching-strategies