вытеснение кеша весной с использованием ключа регулярного выражения

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

ниже мой код для вставки значения в кеш

@Cacheable(value = CACHE_NAME, key = "")
    public InputStream getFiles(String fileName, String id) {
        clearCache(fileName, id);
        return restTemplate.getForObject(configurationFileUrl, InputStream.class, id);
    }

для удаления

@CacheEvict(value = CACHE_NAME, key = " ")
    public void clearCache(String fileName, String id) {

    }

Здесь я пытаюсь передать ключ как SpEL с регулярным выражением, которое удалит ключ, начинающийся с того же имени файла, но отличающийся от последнего обновленного ключа. например, если в кеше была запись ниже krishna1 -> obj1, теперь obj был изменен в БД некоторых других проектов, и теперь он поддерживает запись Krishna2 для ссылки на измененный Obj1

Поэтому, как только вызов придет в мою службу, мне нужно проверить комбинацию имя + ключ в кеше, если ее нет, я должен вставить новую запись (Кришна2), но теперь моя старая запись с именем ключа Кришна1 никогда не будет использоваться, так что как Я удаляю это.

Я не могу создать ключ с именем файла, иначе он не сможет определить, был ли изменен файл или нет.

Постановка проблемы: предположим, что у меня есть одна микрослужба, которая поддерживает доступ к БД и развернута внутри моего доменного имени Service1. БД содержит 3 класса java class1 -> для рисования прямоугольника, class2-> рисования круга и class3 -> для треугольника. Теперь представьте, что у вас есть микросервис, развернутый где-то снаружи, и он получает запрос на отрисовку. Возьмем сценарий, в котором он получил запрос на рисование круга, и он получил конфигурацию, говорящую, что class2 и V1 (информация о версии) отвечают за рисование круга. поэтому он сделает остаточный вызов service1, загрузит class2 и скомпилирует его и кэширует его .class, чтобы следующий запрос он мог обслуживать напрямую, если нет изменений в логике рисования круга (class2). Изменение класса 2 может произойти в будущем, но редко. Теперь, перейдя к проблеме в следующий раз, когда он получит запрос, он сначала проверит, есть ли у него класс с той же версией, если да, затем нарисуйте круг, иначе он сделает вызов rest, чтобы получить файл Java обновления, и скомпилирует и кэширует его в Память. По этой причине я добавил версию (идентификатор) к ключу, чтобы он мог различать, существует ли уже файл и изменен ли он.


person Krishna    schedule 04.11.2015    source источник
comment
У вас могут быть проблемы с дизайном. Если значение ключа сущности может измениться, то это плохой ключ, не для сопоставления кеша и не для большинства других целей. - Или, с другой точки зрения, используйте кеш для хранения сущностей, но не для хранения отношений между сущностями.   -  person JimmyB    schedule 04.11.2015
comment
Я добавил формулировку проблемы в свой вопрос, дайте мне знать, если это прояснит. Также было бы интересно узнать ваши мысли о том же, если вы обнаружите недостаток в дизайне. Спасибо. @ХанноБиндер   -  person Krishna    schedule 04.11.2015
comment
Я понимаю это требование, как будто кто-то изменит источник кэшированного объекта (например, class2) без уведомления кеша, что может привести к устаревшим чтениям и т. д. Решение должно состоять в том, чтобы очистить любой кешированный объект при изменении источника. Поэтому тот, кто меняет class2 или сопоставление того, какой класс для чего использовать, должен обязательно удалить/аннулировать/... соответствующие кэшированные записи. Тогда вам, вероятно, не понадобится версия №. в кеше: у вас есть только 0 или 1 объект в кеше для каждого ключа, и тот, который у вас есть, синхронизирован с последней версией источника.   -  person JimmyB    schedule 04.11.2015


Ответы (1)


Да, в этом я с @Hanno Binder; кажется, у вас может быть проблема с дизайном, особенно в том, как вы пытаетесь версионировать объекты в кэше, используя ключ для различения версий.

(Отказ от ответственности) Я не совсем понимаю ваши требования здесь, но, кажется, вы могли бы просто немного упростить ситуацию, сохранив последнюю (обновленную) версию объекта в кеше, используя тот же ключ. Почему пользователей кэшированного объекта волнует, какая версия используется, если они получают самую последнюю версию, когда она доступна?

В этом случае очень просто убедиться, что последняя версия кэширована (и возвращена из методов @Cacheable), не прибегая к «специальным» критериям исключения, используя файл Аннотация Spring @CachePut. Затем вам нужно только убедиться, что все обновления маршрутизируются с помощью метода, аннотированного @CachePut. Впоследствии все вызываемые методы @Cacheable получат последнюю «версию».

Еще раз приношу свои извинения, если не учел ваши требования.

person John Blum    schedule 13.11.2015