用于阻塞I/O任务的ParallelFlux vs flatMap() [英] ParallelFlux vs flatMap() for a Blocking I/O task

问题描述

我有一个Project Reactor链，其中包括一个阻止任务(网络调用，我们需要等待响应).我想同时运行多个阻止任务.

I have a Project Reactor chain which includes a blocking task (a network call, we need to wait for response). I'd like to run multiple blocking tasks concurrently.

似乎可以使用ParallelFlux或flatMap()来作为准系统示例:

It seems like either ParallelFlux or flatMap() could be used, bare-bone examples:

Flux.just(1)
    .repeat(10)
    .parallel(3)
    .runOn(Schedulers.elastic())
    .doOnNext(i -> blockingTask())
    .sequential()
    .subscribe()

或

Flux.just(1)
    .repeat(10)
    .flatMap(i -> Mono.fromCallable(() -> {blockingTask(); return i;}).subscribeOn(Schedulers.elastic()), 3)
    .subscribe();

这两种技术的优点是什么?一个比另一个更受青睐吗?有其他选择吗?

What are the merits of the two techniques? Is one to be preferred over the other? Are there any alternatives?

推荐答案

parallel专为出于性能目的而并行化任务，并在"rails"或"groups"之间分配工作，每个任务均具有自己的执行力从Scheduler传递给runOn的上下文.简而言之，如果您进行大量的CPU工作，它将使您所有的CPU内核正常工作.但是您正在做I/O绑定的工作...

parallel is tailored for parallelization of tasks for performance purposes, and dispatching of work between "rails" or "groups", each of which get their own execution context from the Scheduler you pass to runOn. In short, it will put all your CPU cores to work if you do CPU intensive work. But you're doing I/O bound work...

因此，在您的情况下，flatMap是更好的选择. flatMap用于并行化的更多内容是关于业务流程.

So in your case, flatMap is a better candidate. That use of flatMap for parallelization is more about orchestration.

如果您不计算flatMapSequential的flatMap风格略有不同(concatMap实际上不允许并行化)，那么这几乎是2种选择.

These are pretty much the 2 alternatives, if you don't count the slightly different flavor of flatMap that flatMapSequential is (concatMap doesn't really allow for parallelization).

这篇关于用于阻塞I/O任务的ParallelFlux vs flatMap()的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！