Spring Webflux и аннотация @Cacheable

1. Введение

В этой статье мы объясним, как Spring WebFlux взаимодействует с аннотацией @Cacheable . Во-первых, мы рассмотрим некоторые распространенные проблемы и способы их избежать. Далее мы рассмотрим доступные обходные пути. Наконец, как всегда, мы приведем примеры кода.

2. @Cacheable и реактивные типы

Эта тема еще относительно новая. На момент написания этой статьи не было полной интеграции между @Cacheable и реактивными фреймворками. Основная проблема заключается в отсутствии неблокирующих реализаций кеша (API кеша JSR-107 блокирует). Только Redis предоставляет реактивный драйвер.

Несмотря на проблему, о которой мы упоминали в предыдущем абзаце, мы по-прежнему можем использовать @Cacheable в наших методах обслуживания. Это приведет к кэшированию наших объектов-оболочек ( Mono или Flux ), но не кеширует фактический результат нашего метода.

2.1. Настройка проекта

Проиллюстрируем это тестом. Перед тестом нам нужно настроить наш проект. Мы создадим простой проект Spring WebFlux с реактивным драйвером MongoDB . Вместо того, чтобы запускать MongoDB как отдельный процесс, мы будем использовать Testcontainers .

Наш тестовый класс будет аннотирован @SpringBootTest и будет содержать:

final static MongoDBContainer mongoDBContainer = new MongoDBContainer(DockerImageName.parse("mongo:4.0.10"));

@DynamicPropertySource
static void mongoDbProperties(DynamicPropertyRegistry registry) {
    mongoDBContainer.start();
    registry.add("spring.data.mongodb.uri",  mongoDBContainer::getReplicaSetUrl);
}

Эти строки запустят экземпляр MongoDB и передадут URI в SpringBoot для автоматической настройки репозиториев Mongo.

Для этого теста мы создадим класс ItemService с методами save и getItem :

@Service
public class ItemService {

    private final ItemRepository repository;

    public ItemService(ItemRepository repository) {
        this.repository = repository;
    }
    @Cacheable("items")
    public Mono<Item> getItem(String id){
        return repository.findById(id);
    }
    public Mono<Item> save(Item item){
        return repository.save(item);
    }
}

В application.properties мы устанавливаем логгеры для кеша и репозитория, чтобы мы могли отслеживать, что происходит в нашем тесте:

logging.level.org.springframework.data.mongodb.core.ReactiveMongoTemplate=DEBUG
logging.level.org.springframework.cache=TRACE

2.2. Начальный тест

После настройки мы можем запустить наш тест и проанализировать результат:

@Test
public void givenItem_whenGetItemIsCalled_thenMonoIsCached() {
    Mono<Item> glass = itemService.save(new Item("glass", 1.00));

    String id = glass.block().get_id();

    Mono<Item> mono = itemService.getItem(id);
    Item item = mono.block();

    assertThat(item).isNotNull();
    assertThat(item.getName()).isEqualTo("glass");
    assertThat(item.getPrice()).isEqualTo(1.00);

    Mono<Item> mono2 = itemService.getItem(id);
    Item item2 = mono2.block();

    assertThat(item2).isNotNull();
    assertThat(item2.getName()).isEqualTo("glass");
    assertThat(item2.getPrice()).isEqualTo(1.00);
}

В консоли мы видим этот вывод (для краткости показаны только основные части):

Inserting Document containing fields: [name, price, _class] in collection: item...
Computed cache key '618817a52bffe4526c60f6c0' for operation Builder[public reactor.core.publisher.Mono...
No cache entry for key '618817a52bffe4526c60f6c0' in cache(s) [items]
Computed cache key '618817a52bffe4526c60f6c0' for operation Builder[public reactor.core.publisher.Mono...
findOne using query: { "_id" : "618817a52bffe4526c60f6c0"} fields: Document{{}} for class: class com.foreach.caching.Item in collection: item...
findOne using query: { "_id" : { "$oid" : "618817a52bffe4526c60f6c0"}} fields: {} in db.collection: test.item
Computed cache key '618817a52bffe4526c60f6c0' for operation Builder[public reactor.core.publisher.Mono...
Cache entry for key '618817a52bffe4526c60f6c0' found in cache 'items'
findOne using query: { "_id" : { "$oid" : "618817a52bffe4526c60f6c0"}} fields: {} in db.collection: test.item

В первой строке мы видим наш метод вставки. После этого, когда вызывается getItem , Spring проверяет кеш на наличие этого элемента, но не находит его, и для извлечения этой записи обращается к MongoDB. При втором вызове getItem Spring снова проверяет кеш и находит запись для этого ключа, но по-прежнему обращается к MongoDB, чтобы получить эту запись.

Это происходит потому, что Spring кэширует результат метода getItem , который является объектом-оболочкой Mono . Однако для самого результата ему все равно нужно получить запись из базы данных.

В следующих разделах мы предложим обходные пути для этой проблемы.

3. Кэширование результата Mono/Flux

Mono и Flux имеют встроенный механизм кэширования, который мы можем использовать в этой ситуации в качестве обходного пути. Как мы уже говорили ранее, @Cacheable кэширует объект-оболочку, и с помощью встроенного кеша мы можем создать ссылку на фактический результат нашего метода службы:

@Cacheable("items")
public Mono<Item> getItem_withCache(String id) {
    return repository.findById(id).cache();
}

Давайте запустим тест из предыдущей главы с этим новым сервисным методом. Вывод будет выглядеть следующим образом:

Inserting Document containing fields: [name, price, _class] in collection: item
Computed cache key '6189242609a72e0bacae1787' for operation Builder[public reactor.core.publisher.Mono...
No cache entry for key '6189242609a72e0bacae1787' in cache(s) [items]
Computed cache key '6189242609a72e0bacae1787' for operation Builder[public reactor.core.publisher.Mono...
findOne using query: { "_id" : "6189242609a72e0bacae1787"} fields: Document{{}} for class: class com.foreach.caching.Item in collection: item
findOne using query: { "_id" : { "$oid" : "6189242609a72e0bacae1787"}} fields: {} in db.collection: test.item
Computed cache key '6189242609a72e0bacae1787' for operation Builder[public reactor.core.publisher.Mono...
Cache entry for key '6189242609a72e0bacae1787' found in cache 'items'

Мы видим почти аналогичный результат. Только на этот раз при обнаружении элемента в кеше не требуется дополнительного поиска в базе данных. С этим решением существует потенциальная проблема, когда срок действия нашего кеша истекает. Поскольку мы используем кеш кеша, нам нужно установить соответствующие сроки действия для обоих кешей. Эмпирическое правило заключается в том, что TTL кэша Flux должен быть больше, чем @Cacheable.

4. Использование надстройки Reactor

Надстройка Reactor 3 позволяет нам свободно использовать различные реализации кеша с классами CacheMono и CacheFlux . В этом примере мы настроим кеш Caffeine :

public ItemService(ItemRepository repository) {
    this.repository = repository;
    this.cache = Caffeine.newBuilder().build(this::getItem_withAddons);
}

В конструкторе ItemService мы инициализируем кеш Caffeine с минимальной конфигурацией, а в новом сервисном методе используем этот кеш:

@Cacheable("items")
public Mono<Item> getItem_withAddons(String id) {
    return CacheMono.lookup(cache.asMap(), id)
      .onCacheMissResume(() -> repository.findById(id).cast(Object.class)).cast(Item.class);
}

Поскольку CacheMono внутренне работает с классом Signal , нам нужно выполнить приведение типов, чтобы вернуть соответствующие объекты.

Когда мы повторно запустим тест ранее, мы получим такой же вывод, как и в предыдущем примере.

5. Вывод

В этой статье мы рассмотрели, как Spring WebFlux взаимодействует с @Cacheable . Кроме того, мы описали, как их можно использовать, и некоторые распространенные проблемы. Как всегда, код из этой статьи можно найти на GitHub .