Size: a a a

Архитектура ИТ-решений

2020 November 29

PT

Peter Tugolukov in Архитектура ИТ-решений
Я не встречал такого.
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Вариант с ручной инвалидацией не подходит?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Leonid Vygovskiy
Я хочу не такого умного агента ))
Задача-то проста. Если пришел POST/PUT/... на /entity, то инвалидировать кэш на GET /entity.*?
Почему? У вас доменная логика на клиенте?
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Gennadiy Kruglov
Почему? У вас доменная логика на клиенте?
Не понял, что вы имеете ввиду. У меня есть ресурсы, которым управляют stateless клиенты. Доменная логика у вас где начинается в этом случае?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Обновляться кэш должен не по запросу от клиента, а при изменении состояния объекта (со стороны приложения/сервиса)
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Peter Tugolukov
Вариант с ручной инвалидацией не подходит?
В смысле дернуть из севера кэш? Нет, мне бы решение, которое самое удалит.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Gennadiy Kruglov
Обновляться кэш должен не по запросу от клиента, а при изменении состояния объекта (со стороны приложения/сервиса)
На основание чего оно изменится? Понятно, что в общем случае это может быть событие внутри системы. Но если все изменения только снаружи?
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Peter Tugolukov
Вариант с ручной инвалидацией не подходит?
У меня был запрос на поиск решения, которое позволит мне НЕ изменять приложение. Точнее, сделать так, чтобы для приложения (сервера) ничего не менялась работает кэш или нет.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Задача больше теоретическая, тем практическая.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Leonid Vygovskiy
Не понял, что вы имеете ввиду. У меня есть ресурсы, которым управляют stateless клиенты. Доменная логика у вас где начинается в этом случае?
Нет, у вас есть ресурсы, консистентность и персистетность которых вы должны обеспечить. То есть, говоря простым языком, сначала сохранить в постоянном хранилище, а потом обновить в кэше

Да, по запросу от клиента
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
В моей картине мира мы это достигаем за счет того, что при любом изменении клиента мы удаляем кэш. А при следующем запросе к ресурсы кэш будет создан заново.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Т.е POST /entity/id удаляет из кэша /entity/id, а последующий GET /entity/id его возвращает в кэш
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
При этом POST /entity/id также инвалидирует GET /entity.*
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
В моёй картине мире сервис после обновления модели записи обновляет модели чтения, одной из которых является кэш
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Это понятная и мне модель мира. Особенно если сразу вспомнить про различные витрины и прочее.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Но вот техническое решение я ищу именно такое. Если не найду, то посмотрю varnish, а если он не может - значит и правда что-то не то хочу.
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
На самом деле такая штука выглядит интересной - воткнул такой посредник перед приложением и довольный.
Но там будет куча ограничений - надо что бы либо проверка доступа отсутствовала, либо зарешивалась до этого компонента (например на api gateway), так же сервис кеширования зависит от того, что отдает основной сервис. Например, если отдалась 4**, кеш не инвалидировать, например.
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Получается достаточно существенная пачка ограничений, изза которых видится гораздо более простым бахнуть тот же редис и прикрутить кеширование на уровне сервиса, а не перед ним.
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
@leonidvspb , как решите задачу, напишите  сюда, пожалуйста. Интересно, что получится в итоге.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Peter Tugolukov
На самом деле такая штука выглядит интересной - воткнул такой посредник перед приложением и довольный.
Но там будет куча ограничений - надо что бы либо проверка доступа отсутствовала, либо зарешивалась до этого компонента (например на api gateway), так же сервис кеширования зависит от того, что отдает основной сервис. Например, если отдалась 4**, кеш не инвалидировать, например.
Может разъехаться с моделью записи. Иными словами, трудно будет управлять консистентностью.
источник