Преобразования в памяти реактивного потока в Project Reactor - PullRequest
Новая
       31

Преобразования в памяти реактивного потока в Project Reactor

0 голосов
/ 08 июня 2018

У меня есть следующий интерфейс: 

interface Checker {
  Mono<Foo> check(Bar bar);
}

Также обратите внимание, что Bar имеет метод getPizzas(): 

class Bar {
  List<Pizza> getPizzas() { ... }
}

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

Однако в других случаях операций ввода-вывода нет, поэтому я хочу использовать только метод transform, который принимает List<Pizza>и возвращает экземпляр Foo и возвращает его как Mono<Foo>.

Подпись transform: 

Foo transform(List<Pizza> pizzas) { ... }

Насколько я понимаю, у меня есть два варианта(возможно, больше), чтобы реализовать такой Checker:

Опция [1.a] - максимально использовать подход реактивного потока: 

Mono<Foo> check(Bar bar) {
  return Flux.fromIterable(bar.getPizzas()).collectList().map(pizzas -> transform(pizzas));
}

Опция [1.b] - почтикак [1.a]: 

Mono<Foo> check(Bar bar) {
  return Mono.just(bar.getPizzas()).map(pizzas -> transform(pizzas));
}

Опция [2] - использовать чистую Java для преобразования в памяти: 

Mono<Foo> check(Bar bar) {
  return Mono.just(transform(bar.getPizzas()));
}

Мои вопросы:

Есть ли разница в опциях, описанных выше?

Будет ли лучше использование реактивного map, если transform интенсивно использует процессори занимает значительное время (скажем, более 2 секунд)?

1 Ответ

0 голосов
/ 26 апреля 2019

Если вы не выполняете трансформацию для каждой пиццы, нет причин использовать Flux.Кроме того, каждый из предоставленных вами методов будет делать то же самое.Если вас беспокоит интенсивная загрузка ЦП, вы должны подписаться на операцию, используя параллельный пул потоков, чтобы переложить работу и освободить поток цикла событий. 

Mono.just(bar.getPizzas())
   .map(pizzas -> transform(pizzas))
   .subscribeOn(Schedulers.parallel())
...