0

Я пытаюсь реализовать распределенный кеш с помощью spring-memcached. Документы предполагают, что использовать объект в качестве ключа, который должен иметь метод в моем классе домена, с аннотацией @CacheKeyMethod .Как указать разные ключи кеша на одном и том же ключевом объекте в simple-spring-memcached

Но проблема в том, что я использую один и тот же класс домена в разных сценариях, а ключ, который должен быть сгенерирован в каждом случае, имеет другую логику. Для примеров для класса User один из сценариев требует, чтобы ключ был уникальным с точки зрения city и gender, но в другом случае он должен быть уникальным с точки зрения пользователя email, по сути, на основе вашего поиска.

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

Есть ли способ определить разные ключи. Также было бы здорово, если бы логика генерации ключа могла быть нарушена из самого класса домена.

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

Редактировать .. ОК .. У меня есть ключ! Что делает CacheKeyBuliderImpl, он вызывает метод generateKey для экземпляра defaultKeyProvider, который ищет @cachekeyannotation для предоставленных методов класса домена и выполняет метод, найденный для получения ключа.

Так замена либо CacheKeyBuilderImpl с пользовательским осущий или заменами KeyProvider реализации по умолчанию в CacheKeyBuilderImpl с вашим может сделать трюк ... но ссылка keyprovider замонолична на DefaultKeyProvider.

Может кто-нибудь помочь мне реализовать CacheKeyBuilder (относительно того, что делать различные методы, документация не проясняет его), а также как я впрыснуть использовать его вместо ususal CacheKeyBuilderImpl

ответ

0

Simple Spring Memcached (SSM) не предназначено для такой низкоуровневой настройки. Как вы писали, один из способов - заменить CacheKeyBuilderImpl с собственной реализацией. Реализация по умолчанию является жесткой, но ее можно легко заменить, используя конфигурацию конфигурации simplesm-context.xml.

Как я понимаю ваш вопрос, вы хотите кешировать Пользователь объекты под разными ключами зависят от прецедента. Он поддерживается из коробки, потому что по умолчанию SSM использует аргумент метода для генерации кеш-ключа, а не результата.

Пример:

@ReadThroughMultiCache(namespace = "userslist.cityandgenre", expiration = 3600 
public List<User> getByCityAndGenre(@ParameterValueKeyProvider(order = 0) String city, @ParameterValueKeyProvider(order = 1) String genre) { 
    // implementation 
} 

@ReadThroughSingleCache(namespace = "users", expiration = 3600) 
public User getByEmail(@ParameterValueKeyProvider String email) { 
    // implementation 
} 

В общем @CacheKeyMethod используется только для генерации ключа кэша, если объект, который содержит метод передается в качестве параметра методу, а параметр прокомментированы @ParameterValueKeyProvider

+0

Мой сценарий немного надуман. Первый метод заключается не в поиске пользователей для города и пола .. скорее, поиск релевантных сделок для конкретного пользователя. Тип возврата - это список . Список сделок может быть кэширован по электронной почте, но релевантность сделок зависит от города и пола пользователя. Поэтому лучше кэшировать их на основе ключа, а не на электронной почте, чтобы одна запись могла обслуживать всех пользователей города и пола. В настоящее время метод принимает пользователя как параметр. Одним из вариантов может быть делегирование вызова другому методу с помощью city и gnder passd в метод и использование их как ключей – mickeymoon

+0

это как 'public List getDealsForUser (Пользователь пользователя) { String city = user.getCity(); Строка gender = user.getGender(); // вызов orm для получения предложений для пользователя } ' – mickeymoon

+0

Можете ли вы изменить подпись метода, а вместо пользовательского параметра используйте город и пол? Он решит вашу проблему и позволит кэшировать список сделок по городам и полу. Вы также можете создать новый bean-компонент с выделенным методом getDealsByCityAndGender и вызывать его из getDealsForUser (самозапуска не перехватываются, поэтому кеш не работает) – ragnor