День 1476. #ЗаметкиНаПолях Стратегии Кэширования на Стороне Сервера. Окончание Начало 3. Сквозная запись (Write-through): кэш может записывать в БД СИНХРОННО Данные сначала записываются в кэш, а затем синхронно в источник. Приложение просит кэш сохранить некоторые данные. Кэш сохраняет эти данные в своём внутреннем хранилище, а затем записывает в БД, используя плагины и настройки. Затем, когда и кэш, и БД обновят значение, происходит возврат к приложению с результатом выполнения сохранения (успех/неудача). Приложение не записывает данные напрямую в БД, а сам кэш знает, как записывать данные в БД. Преимущества - Поскольку все записи данных проходят через кэш, у нас не будет устаревших данных, а так как все запросы на чтение проходят через кэш, данные в приложении всегда будут в актуальном состоянии. Недостатки - Аналогично сквозному чтению, мы ввели единую точку отказа. Более того, если кэш выйдет из строя или будет недоступен, мы потеряем и данные, которые пытаемся записать. - Так как операции происходят синхронно, увеличится задержка: прежде чем продолжить работу, приложение должно дождаться, пока и кэш, и БД завершат свою работу и запишут новые данные. 4. Отложенная запись (Write-behind): кэш может писать в БД АСИНХРОННО Отложенная запись аналогична сквозной записи, но все операции записи в источник выполняются асинхронно. Преимущества - Поскольку теперь нам не нужно ждать, пока БД завершит запись, мы улучшим общую производительность, т.к. сократим задержку. - Мы также можем выполнять пакетную запись в БД, сокращая количество обращений к хранилищу данных. Недостатки - Аналогично сквозному чтению и сквозной записи, мы ввели единую точку отказа. Если кэш выходит из строя, данные не сохраняются в БД. - Если кэш правильно обновляет своё внутреннее состояние, но по какой-то причине БД не сможет обновить данные, у нас будут несогласованные данные. И приложение не узнает, правильно ли данные были сохранены в БД. Источник: https://www.code4it.dev/architecture-notes/caching-strategies