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

[little-brother]

Write-Through (Запись сквозь кеш)

• Данные сначала пишутся в кеш.

• Затем они пишутся в базу данных.

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

[offiziellen]

Согласен с вами, для простых сценариев "сначала в БД, потом в кеш" проще сделать и он будет более безопасным.

[tempart]

Статья классная, но местами зависал.
В "1. Cache-Aside (Ленивая загрузка, кеш "в стороне")":

Данные, полученные из БД, кладутся в кеш на будущее. "Вот, кеш, сохрани, может еще пригодится."

Данные - это объект. Они сами никуда не кладутся, их кто-то/что-то кладёт. Судя по контексту, приложение? Но тогда как понимать следующий шаг, если данные уже у приложения?:

Данные отдаются тому, кто их просил

Если отбросить эротические фантазии, кто тут отдаёт данные?

[Protector_RTD]

Прекрасная статья, спасибо за полезные материалы

P.S
Read-Through - разве не является просто логической итерацией - Cache-Aside. Сложилось впечатление, что Read-Through это просто обертка поверх Cache-Aside, когда добавили 1 уровень абстракции. В целом стало интересно, а есть ли ещё какие-то паттерны чтения помимо этих двух (если это в целом не одно и тоже)

[offiziellen]

Вы абсодютно правы, Read-Through "обертка" над Cache-Aside. Но у них есть отличие - Cache-Aside, приложение само проверяет кеш. Если данных нет, приложение идет в БД, получает данные, кладет их в кеш и использует. При Read-Through, приложение всегда обращается только к провайдеру кеша. Если данных в кеше нет, то провайдер идет в БД, загружает данные, сохраняет их у себя и возвращает приложению. Приложение как бы не знает, откуда пришли данные – напрямую из кеша или их только что подгрузили из БД. Других паттернов именно для заполнения кеша при чтении не выделяют.