Оптимизация и кастомизация запросов с использованием Spring Cache и Scope Bean

Привет! Меня зовут Алексей Салаев, я Java-разработчик команды Corp Digital в Росбанке. В этом посте я расскажу, как можно оптимизировать и кастомизировать запросы в Spring: опишу потенциальные проблемы, оценю возможные пути решения и проиллюстрирую всё примерами.

Представим, что у нас есть сервис по работе с документами. Это могут быть ордера, заявки, платежи или что-то другое. У каждого документа есть жизненный цикл — создание, подписание и затем исполнение (отправка в целевую систему).

С созданием всё понятно: сделали документ и положили в базу. На подписании остановимся подробней. Как оно может проходить? Представим, что у нас есть три уровня подписи: руководитель (HEAD), эксперт (EXPERT) и бухгалтер (ACCOUNTANT). И есть пользователи, каждых из которых уполномочен те или иные подписи проставлять:

• руководителю доступны все три — HEAD, EXPERT и ACCOUNTANT;

• эксперту — только своя, EXPERT;

• бухгалтеру — HEAD и ACCOUNTANT.

Рассмотрим, как может выглядеть запрос подписания:

1. Проверка прав пользователя на возможность подписания. Для этого необходимо обратиться в сервис USER, который по определенному идентификатору возвратит нам уровни подписей пользователя. С ними мы сможем проверить, уполномочен пользователь подписывать документ или нет.

2. Сам процесс подписания. Для этого необходимо снова обратиться в сервис USER за уровнями подписей пользователя, на основе которых уже пройдет само предписание.

3. Постобработка запроса — например, это может быть возврат в вызывающую систему для уровней других подписей, которые пользователь может проставить. Поскольку пользователь может иметь несколько уровней подписей, а проставить не все, то необходимо снова обратиться в сервис USER за уровнями подписей пользователя. Далее сервис определит, какие подписи не были проставлены, и вернет в вызывающую систему список уровней подписей, который пользователь еще может проставить.

Как это реализовано в коде? Мы получаем запрос в controller и затем идем в service в метод sign, где работает основная логика: 

1. Вызывается метод checkPermissions , которые отвечают за проверку прав.

2. Вызывается метод signing, который отвечает за сам процесс подписания. 

3. Вызывается метод getActions, который отвечает за постобработку.

В каждом из этих методов в адаптере сервиса USER вызывается метод getSignatureLevels, который возвращает уровни пользователя. То есть вызов сервиса User происходит трижды.

Потенциальные проблемы такого подхода — долгое выполнение запросов и нагрузка на вызываемый сервис. Что можно с этим сделать?

1. Остановиться на последовательном выполнении, то есть оставить всё как есть. Да, проблемы сохранятся, но если мы делаем какой-нибудь пилот, но нам куда важнее скорость разработки.

2. Передача в параметрах метода. Делаем один запрос, при первом обращении данные сохраняются в переменную метода, после чего полученные данные передаются в сигнатуре методов везде, где потребуется. Плюс такого подхода — простота. Минус — мы смешиваем бизнес-логику и техническую часть; их лучше разделять, потому что со временем это будет всё сложнее поддерживать и дорабатывать.

3. Локальное кеширование. Делается один запрос, при первом обращении данные сохраняются в поле класса, а при последующих обращениях подтягиваются из него. Если данные еще не сохранились, то мы снова обращаемся в сервис USER.

4. Кеширование с использованием Spring Cache. При первом обращении данные кешируются, при последующих подтягиваются из кеша. На мой взгляд, это самый логичный подход. Его преимущества — достаточно простое подключение, легкая кастомизация и последующая работа.

О двух последних подходах я расскажу подробнее.

Кеширование с использованием Spring Cache

В Spring Cache абстракцию нам предоставляет Spring, а реализацию cache мы подключаем сами. Есть много доступных вариантов:

• EhCache

• JCache

• Hazelcast

• Infinispan

• Couchbase

• Redis

• Caffeine

• Simple

Я остановлюсь на Caffeine, так как этот вариант достаточно простой и лучше всего подходит для примера.

Spring Cache подключается легко. Мы ставим аннотацию @Cachable над тем методом, которым хотим закешировать, указываем, какое имя кеша использовать, и добавляем аннотацию @EnableCaching для поддержки кеширования.

@Cacheable(cacheNames = {"signature"}) public Set<SignatureLevel> getSignatureLevels(long userId) {       //логика }

Что представляет собой Cache? По сути, это мапа, в которой есть ключ и значение. По ключу мы добавляем данные, а затем берем значение, если они там есть. По умолчанию Spring использует генератор ключей SimpleKeyGenerator, который можно заменить на свой. Но мы остановимся на стандартном.

SimpleKeyGenerator берет сигнатуру метода и смотрит, есть ли в ней параметры:

• Если параметров нет, он берет 0.

• Если параметр один, он берет хеш-код этого параметра.

• Если параметров несколько, то на основе хеш-кодов всех параметров вычисляется общее значение, которое используется в качестве ключа кеширования.

Использовать в качестве ключей данные из сигнатуры метода — это не очень хорошая практика. Со временем данные могут меняться, и туда могут добавляться поля, которые в кешировании участвовать не должны. Чтобы этого избежать, лучше указывать именно те параметры, которые мы хотим использовать в качестве ключа. В данном случае я указал userId:

@Cacheable(cacheNames = {"signature"},  key = "{#userId}") public Set<SignatureLevel> getSignatureLevels(long userId) {       //логика }

Мы запрашиваем уровни подписей пользователя по его идентификатору (userId) в сервисе USER, получаем данные и кешируем их. При последующих вызовах запрос в сервис USER выполняться не будет, а данные поступят из кеша. Вроде все просто.

Теперь давайте рассмотрим, как закешировать данные на основе еще одного параметра, которого нет в сигнатуре метода. Например, мы хотим иметь кеш в рамках одного запроса. Если параллельно придет другой запрос, то данные необходимо закешировать отдельно и не использовать кеш парольного запроса. Для этого будем использовать рассчитанный на основе userId ключ из сигнатуры метода и requestId, который может быть передан в заголовках http-запроса.

Возникает вопрос: как мы можем передать данные из заголовка запроса в качестве ключа кеширования. Можно, например, использовать ThreadLocal — он позволяет хранить данные, которые будут доступны только определенному потоку. Для этого настроим фильтр, который будет сохранять в ThreadLocal данные из заголовка http-запроса.

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

@Component public class CustomFilter implements Filter {      @Override  public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {    HttpServletRequest httpRequest = (HttpServletRequest) request;    try {    ThreadLocalCustom.setContext(new Context(httpRequest.getHeader("Custom-ID")));         chain.doFilter(request, response);    } finally {         ThreadLocalCustom.clearContext();    } 

Теперь осталось только указать данный параметр из ThreadLocal в качестве ключа для кеширования. Для этого можем использовать язык выражений SpEL:

@Cacheable(cacheNames = {"signature"},        key = "{#userID,T(ru.rosbank.ThreadLocalCustom).getCustomId()}") public Set<SignatureLevel> getSignatureLevels(long userId) {       //логика }

Мы рассмотрели, как можем в качестве ключа использовать любой параметр из запроса. Преимущество этого подхода: мы можем кешировать данные в рамках одного запроса, одной сессии или вообще на основе любого параметра.

Теперь представим, что у нас есть два пользователя — руководитель и исполняющий обязанности руководителя (и.о. руководителя). По бизнес-логике для и.о. руководителя мы можем кешировать, например, на одну минуту после записи. А для реального руководителя — на пять минут. Как это сделать?

Сначала нужно настроить CacheManager, который будет отвечать, сколько будут жить данные в кеше. Покажу на примере Caffeine. Создадим бин defaultCacheManager.

@Bean("defaultCacheManager") public CacheManager defaultCacheManager() {     var cacheManager = new CaffeineCacheManager("signature");     cacheManager.setCaffeine(caffeineCacheBuilder());     return cacheManager; }  public Caffeine<Object, Object> caffeineCacheBuilder() {     return Caffeine.newBuilder()             .maximumSize(5000)             .expireAfterWrite(Duration.ofSeconds(60)) //истечение после последней записи             //.expireAfterAccess(Duration.ofDays(1)) //истечение после последнего доступа }

После создания мы можем указать его в качестве cacheManager для кеширования:

@Cacheable(cacheNames = {"signature"},    cacheManager = "defaultCacheManager") public Set<SignatureLevel> getSignatureLevels(long userId) {       //логика } 

Мы, кстати, можем не указывать здесь cacheManager, если укажем Spring, чтобы он использовал бин defaultCacheManager по умолчанию, через аннотацию @Primary.

Мы настроили кеш для пользователей с одной минутой кеширования. Теперь настроим кеш для пользователей с пятью минутами после добавления в кеш. Назовем его constantLifetimeCacheManager.

@Bean("constantLifetimeCacheManager") public CacheManager constantLifetimeCacheManager() {     var cacheManager = new CaffeineCacheManager(“signatureConst”);     cacheManager.setCaffeine(constantLifetimeCacheBuilder());     return cacheManager; } // фиксированное время жизни 5 минут public Caffeine<Object, Object> constantLifetimeCacheBuilder() {     return Caffeine.newBuilder()             .initialCapacity(1000)             .maximumSize(5000)             .expireAfter(new Expiry<>() {                 @Override                 public long expireAfterCreate(Object key, Object value, long currentTime)  {                     return TimeUnit.MINUTES.toNanos(5);                 } ... 

Указываем данный CacheManager в параметрах аннотации:

@Cacheable(cacheNames = {“signature”},    cacheManager = “constantLifetimeCacheManager”) public Set<SignatureLevel> getSignatureLevels(long userId) {       //логика 

Представим, что по бизнес-логике мы, используя маску, можем определить по id пользователя, является ли он руководителем или и.о. руководителя. А как сделать, чтобы у нас по данной маске использовался либо defaultCacheManager, либо constantLifetimeCacheManager?

Самый простой вариант — через if-else. Создаем два метода, getSignatureLevels_1 и getSignatureLevels_2, с разными настройками кеширования и в зависимости от маски вызываем соответствующий метод. Но Spring предоставляет нам другую реализацию, на основе CacheResolver. Для этого нам необходимо реализовать метод Collection<? extends Cache> resolveCaches(CacheOperationInvocationContext<?> context) интерфейса CacheResolver:

public class MultipleCacheResolver implements CacheResolver {      @Qualifier("defaultCacheManager")     private final CacheManager defaultCacheManager;     @Qualifier("constantLifetimeCacheManager")     private final CacheManager constantLifetimeCacheManager;      @Override     public Collection<? extends Cache> resolveCaches(CacheOperationInvocationContext<?> context) {         var caches = new ArrayList<Cache>();         var userId = (long) context.getArgs()[0];         if (userId % 2 == 0) { //маска, например, четный или не четный id             caches.add(defaultCacheManager.getCache(CaffeineCacheConfig.CACHE_NAME_SIGNATURE));         } else {             caches.add(constantLifetimeCacheManager.getCache(CaffeineCacheConfig.CACHE_NAME_SIGNATURE_CONST));         }         return caches;     }

Здесь мы получаем из CacheOperationInvocationContext данные сигнатуры метода — в нашем случае это единственный параметр userId. Проверяем по маске: в примере выше смотрим, четный параметр или нечетный. В зависимости от результата проверки используется тот или иной CacheManager. 

Осталось указать данный CacheResolver в параметрах @Cacheable:

@Override @Cacheable(cacheNames = {"signature"},     key = "{#param, T(ru.rosbank.ThreadLocalCustom).getCustomId()}",  cacheResolver = "multipleCacheResolver") public Set<SignatureLevel> getSignatureLevels(long userId) {       //логика }

Перед выполнением метода getSignatureLevels вызывается CacheResolver, который определяет, какой кеш использовать, и использует его.

Мы рассмотрели, как можно кастомизировать кеш с использованием CacheResolver и SimpleKeyGenerator. Теперь я вернусь к третьему пункту списка: расскажу о подходе с локальным кешированием и, главное, о том, как можно провести в нем аналогичную (похожую) кастомизацию.

Локальное кеширование

Для начала хотелось бы уточнить, что понимается под локальным кешированием. У нас есть адаптер, который непосредственно обращается к сервису. В данном адаптере имеется коллекция, которая принадлежит классу UserImpl:

public class UserImpl implements UserApi {     private final Set<SignatureLevel> signatureLevels = new HashSet<>(); ...

В эту коллекцию сохраняется результат запроса из сервиса USER:

public class UserImpl implements UserApi   private final Set<SignatureLevel> signatureLevels  = new HashSet<>();   private boolean isCache = false;   public Set<SignatureLevel> getSignatureLevels(long userId) {       if (!isCache) {           signatureLevels.addAll(//запрос в сервис);           isCache = true;       }       return signatureLevels;     }  @Bean public UserApi getUserApi(){     return new UserImpl(); }

Вначале мы проверяем, заполнена ли коллекция. Если нет, то идем в сервис, получаем оттуда данные, добавляем в коллекцию и возвращаем результат. Если данные есть, то сразу возвращаем их из коллекции.

Вроде всё сделано хорошо… но работать не будет. Ведь Spring создаёт бины singleton. Так что когда к нам придет следующий запрос, в коллекции signatureLevels будут данные от предыдущего запроса. Как решить эту проблему? Логично сделать бин UserImpl prototype:

public class UserImpl implements UserApi {     private final Set<SignatureLevel> signatureLevels = new HashSet<>(); ...  @Bean @Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE) public UserApi getUserApi()     return new UserImpl();

Но это всё равно не сработает. Вспомним, как Spring создает бины. У нас есть два бина, handler или сервис, который является singleton, и UserApi — prototype, который, в свою очередь, заинжекчен в бин singleton. При создании бина singleton будут сначала созданы все зависимые бины, а затем один раз заинжекчены. Поэтому бин UserImpl для singleton будет один и тот же.

Один из вариантов заставить всё работать — использовать @Lookup:

@Lookup private UserApi getUserApi()     return null;

Рассмотрим, как можно кастомизировать это по аналогии с кешированием. Предлагаю достаточно простой способ — с помощью пользовательской области видимости.

Пользовательская область видимости

Попробуем сделать и использовать свой кастомный Scope, для этого необходимо:

• реализовать метод Object get(String name, ObjectFactory<?> objectFactory) интерфейса Scope. Он обязателен для реализации. Все другие методы этого интерфейса опциональны.

• зарегистрировать новый scope:

public class CustomScope implements Scope {     @Override    public Object get(String name, ObjectFactory<?> objectFactory) {        // логика    } ...

Для регистрации нового Scope необходимо реализовать интерфейс BeanFactoryPostProcessor и в методе PostProcessBeanFactory зарегистрировать новый Scope. В примере новый бин получил название CustomScope:

@Component public class CustomBeanFactoryPostProcessor implements BeanFactoryPostProcessor    @Override    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)         beanFactory.registerScope("customScope", new CustomScope());

Рассмотрим пример реализации пользовательской области видимости. Для хранения созданных бинов будем также использовать Caffeine. Можно использовать и обычную ConcurrentHashMap, но тогда придётся реализовывать механизм удаления бинов из хранилища в зависимости от того, сколько они должны жить. При использовании Caffeine всё будет само очищаться по заданной логике, рассмотренной в предыдущем разделе. Пример реализации: 

public class CustomScope implements Scope {     private final Cache<Object, Object> defaultCacheManager;     private final Cache<Object, Object> constantLifetimeCacheManager;      @Override     public Object get(String name,  ObjectFactory<?> objectFactory) {         if (Long.parseLong(ThreadLocalCustom.getContext().getCustomId()) % 2 == 0) {             return defaultCacheManager.get(name + ThreadLocalCustom.getContext().getCustomId(), k -> objectFactory.getObject());         } else {             return constantLifetimeCacheManager.get(name + ThreadLocalCustom.getContext().getCustomId(), k -> objectFactory.getObject());         }     } ...

В примере указано два CacheManager, с которыми мы работали. В качестве ключа для кеша используем название класса и CustomId из ThreadLocal, а значением будем непосредственно сам созданный бин.

Здесь, в отличие от предыдущего примера, для определения CacheManager’а используется CustomId, потому что параметр UserId получить достаточно сложно. Это решаемый вопрос, но в нашем случае я решил не усложнять примеры лишним кодом и использовал CustomId из ThreadLocal в качестве маски.

Осталось указать, что мы используем кастомный @Scope для UserImpl, и подсказать Spring, что надо брать новый @Bean из контекста в соответствии с нашими настройками, ведь мы имеем дело с разными scope’ами для бинов:

public class UserImpl implements UserApi      private final Set<SignatureLevel> signatureLevels = new HashSet<>();     private boolean isCache = false;      public Set<SignatureLevel> getSignatureLevels(long params) {         if (!isCache) {             signatureLevels.addAll(//запрос в сервис);             isCache = true;         }         return signatureLevels;     } @Bean @Scope(scopeName = "customScope", proxyMode = ScopedProxyMode.TARGET_CLASS) public UserApi getUserApi(){     return new UserImpl();

Опишем, как работает данный механизм в целом. Когда запрос попадает в handler, для определения, какой бин использовать UserImpl, будет вызван метод get класса CustomScope. Если в методе get бин находится в кеше, он будет возвращен, если его нет в кеше, то будет создан, помещен в кеш и возвращен.

И уже в возвращенном бине UserImpl будет отрабатываться логика нахождения уровней подписи SignatureLevels.

Подведем итоги

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