PT
Я не встречал такого.
Size: a a a
2020 November 29
PT
Вариант с ручной инвалидацией не подходит?
GK
Я хочу не такого умного агента ))
Задача-то проста. Если пришел POST/PUT/... на /entity, то инвалидировать кэш на GET /entity.*?
Задача-то проста. Если пришел POST/PUT/... на /entity, то инвалидировать кэш на GET /entity.*?
Почему? У вас доменная логика на клиенте?
LV
Почему? У вас доменная логика на клиенте?
Не понял, что вы имеете ввиду. У меня есть ресурсы, которым управляют stateless клиенты. Доменная логика у вас где начинается в этом случае?
GK
Обновляться кэш должен не по запросу от клиента, а при изменении состояния объекта (со стороны приложения/сервиса)
LV
Вариант с ручной инвалидацией не подходит?
В смысле дернуть из севера кэш? Нет, мне бы решение, которое самое удалит.
LV
Обновляться кэш должен не по запросу от клиента, а при изменении состояния объекта (со стороны приложения/сервиса)
На основание чего оно изменится? Понятно, что в общем случае это может быть событие внутри системы. Но если все изменения только снаружи?
LV
Вариант с ручной инвалидацией не подходит?
У меня был запрос на поиск решения, которое позволит мне НЕ изменять приложение. Точнее, сделать так, чтобы для приложения (сервера) ничего не менялась работает кэш или нет.
LV
Задача больше теоретическая, тем практическая.
GK
Не понял, что вы имеете ввиду. У меня есть ресурсы, которым управляют stateless клиенты. Доменная логика у вас где начинается в этом случае?
Нет, у вас есть ресурсы, консистентность и персистетность которых вы должны обеспечить. То есть, говоря простым языком, сначала сохранить в постоянном хранилище, а потом обновить в кэше
Да, по запросу от клиента
Да, по запросу от клиента
LV
В моей картине мира мы это достигаем за счет того, что при любом изменении клиента мы удаляем кэш. А при следующем запросе к ресурсы кэш будет создан заново.
LV
Т.е POST /entity/id удаляет из кэша /entity/id, а последующий GET /entity/id его возвращает в кэш
LV
При этом POST /entity/id также инвалидирует GET /entity.*
GK
В моёй картине мире сервис после обновления модели записи обновляет модели чтения, одной из которых является кэш
LV
Это понятная и мне модель мира. Особенно если сразу вспомнить про различные витрины и прочее.
LV
Но вот техническое решение я ищу именно такое. Если не найду, то посмотрю varnish, а если он не может - значит и правда что-то не то хочу.
PT
На самом деле такая штука выглядит интересной - воткнул такой посредник перед приложением и довольный.
Но там будет куча ограничений - надо что бы либо проверка доступа отсутствовала, либо зарешивалась до этого компонента (например на api gateway), так же сервис кеширования зависит от того, что отдает основной сервис. Например, если отдалась 4**, кеш не инвалидировать, например.
Но там будет куча ограничений - надо что бы либо проверка доступа отсутствовала, либо зарешивалась до этого компонента (например на api gateway), так же сервис кеширования зависит от того, что отдает основной сервис. Например, если отдалась 4**, кеш не инвалидировать, например.
PT
Получается достаточно существенная пачка ограничений, изза которых видится гораздо более простым бахнуть тот же редис и прикрутить кеширование на уровне сервиса, а не перед ним.
PT
@leonidvspb , как решите задачу, напишите сюда, пожалуйста. Интересно, что получится в итоге.
GK
На самом деле такая штука выглядит интересной - воткнул такой посредник перед приложением и довольный.
Но там будет куча ограничений - надо что бы либо проверка доступа отсутствовала, либо зарешивалась до этого компонента (например на api gateway), так же сервис кеширования зависит от того, что отдает основной сервис. Например, если отдалась 4**, кеш не инвалидировать, например.
Но там будет куча ограничений - надо что бы либо проверка доступа отсутствовала, либо зарешивалась до этого компонента (например на api gateway), так же сервис кеширования зависит от того, что отдает основной сервис. Например, если отдалась 4**, кеш не инвалидировать, например.
Может разъехаться с моделью записи. Иными словами, трудно будет управлять консистентностью.