День 1476. #ЗаметкиНаПолях
Стратегии Кэширования на Стороне Сервера. Окончание
Начало

3. Сквозная запись (Write-through): кэш может записывать в БД СИНХРОННО
Данные сначала записываются в кэш, а затем синхронно в источник.

Приложение просит кэш сохранить некоторые данные. Кэш сохраняет эти данные в своём внутреннем хранилище, а затем записывает в БД, используя плагины и настройки. Затем, когда и кэш, и БД обновят значение, происходит возврат к приложению с результатом выполнения сохранения (успех/неудача). Приложение не записывает данные напрямую в БД, а сам кэш знает, как записывать данные в БД.

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

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

4. Отложенная запись (Write-behind): кэш может писать в БД АСИНХРОННО
Отложенная запись аналогична сквозной записи, но все операции записи в источник выполняются асинхронно.

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

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

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