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

Зачем кешировать данные?

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

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

Проблема с кэшированием данных

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

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

Скорость изменения исходных данных, а также политика кэширования для обновления данных будут определять, насколько противоречивыми будут данные. https://aws.amazon.com/builders-library/caching-challenges-and-strategies/?did=ba_card&trk=ba_card

Стратегии обеспечения совместимости кеша с Origin (насколько это возможно)

  1. Частичное кэширование — вместо всего кэширования кэшируются только некоторые поля. Эти поля могут быть относительно стабильными и редко обновляются.
  2. Боковой кэш (или дополнительный кэш) — приложение поддерживает актуальность кэша. Подходит, когда данные из кэша необходимо загружать по запросу. Или когда операции встроенного кэша (сквозное чтение или запись) не поддерживаются. Подробнее об этом шаблоне https://learn.microsoft.com/en-us/azure/architecture/patterns/cache-aside

3. Встроенный кэш. Кэш является частью API доступа к данным, и кэш прозрачен для пользователей API доступа к данным. Встроенный кэш можно разделить на следующие категории.

3.1 Кэш сквозного чтения — каждый запрос на чтение сначала просматривается в кеше, если он недоступен в кеше (или был признан недействительным), кеш считывает его из источника данных и обновляет себя для будущие поиски и возвращает результат.

3.2 Кэширование с предварительным обновлением. Чтобы уменьшить задержку кэша сквозного чтения и сохранить актуальные объекты в кэше, некоторые кэши могут поддерживать загрузку данных заранее. Если доступ к объекту осуществляется после истечения срока действия, это синхронный вызов для чтения и представления результата (например, сквозное чтение). Но если к объекту обращаются за настроенное время до истечения срока действия, значение возвращается, но асинхронное чтение из источника пополняет кеш последним значением.

3.3 Кэш со сквозной записью. Каждая запись выполняется в кеш, который обновляет себя и источник. Прямо вперед для кэширования на стороне сервера. Это замедляет операцию записи, когда данные записываются как в кэш, так и в источник.

3.4. Кэш с отложенной записью. Он отличается от кеша со сквозной записью, поскольку ускоряет запись за счет асинхронной записи в источник.

Работает ли стратегия кэширования или нет, можно определить, просмотрев матрицы промахов в кеше (когда объект не найден в кеше и считывается из источника) и матриц попадания в кеш (когда объект найден в кеше).

В следующей части я напишу, где мы можем применить кеширование и какие преимущества или последствия оно может иметь.

Ссылка на предыдущую часть, посвященную запросам, CQRS и применению CQRS в различных контекстах.

Кредиты —