Reactor Mono中zip+map与flatMap/map的并行调用差异对比

针对你提到的三个已通过scheduleOn(Schedulers.parallel())指定并行调度的Mono调用场景，除了写法复杂度外，二者还有以下关键差异：

1. 实际执行模式：并行 vs 串行 #

• Mono.zip：会同时订阅三个Mono实例，三个服务调用会真正并行执行，总耗时取决于三个服务中耗时最长的那个（忽略调度线程切换开销）。
• 嵌套flatMap：虽然每个Mono都配置了scheduleOn，但flatMap的订阅逻辑是链式触发的——只有mono1执行完成并返回结果后，才会订阅并执行mono2；同理mono3要等mono2完成才会启动。最终三个服务调用是串行执行，总耗时是三个服务耗时的总和，完全失去了并行的意义。

2. 错误处理逻辑不同 #

• Mono.zip：遵循"快速失败"原则，只要三个Mono中的任意一个触发错误，整个zip操作会立即终止，同时取消另外两个未完成的Mono的订阅，错误会直接向上传播。
• 嵌套flatMap：错误传播是链式的：
  • 如果mono1出错，整个链直接终止，mono2和mono3不会被订阅；
  • 如果mono2出错，mono1已经执行完成（不会被取消），错误向上传播；
  • 如果mono3出错，mono1和mono2都已完成，错误向上传播。
    另外，你可以在每个flatMap阶段单独添加错误处理（如onErrorResume），对不同阶段的错误做差异化处理，这一点比zip更灵活。

3. 结果依赖与执行前提 #

• Mono.zip：三个Mono之间没有依赖关系，只要订阅就会并行启动，最终收集所有成功结果。
• 嵌套flatMap：隐含了结果依赖的逻辑——mono2的执行可以依赖mono1的结果，mono3可以依赖mono1和mono2的结果。如果你的场景中服务调用本身不需要依赖前序结果，这种写法完全是冗余的，还会导致串行执行。

代码示例对比 #

并行执行的正确方式（Mono.zip） #

Mono<A> mono1 = service1.call().scheduleOn(Schedulers.parallel());
Mono<B> mono2 = service2.call().scheduleOn(Schedulers.parallel());
Mono<C> mono3 = service3.call().scheduleOn(Schedulers.parallel());

Mono.zip(mono1, mono2, mono3)
    .map(tuple -> {
        A res1 = tuple.getT1();
        B res2 = tuple.getT2();
        C res3 = tuple.getT3();
        // 处理三个并行结果
        return combineResults(res1, res2, res3);
    })
    .onErrorResume(e -> {
        // 处理任意一个服务调用失败的情况
        return Mono.just(defaultResult());
    });

串行执行的嵌套flatMap（无依赖场景下不推荐） #

Mono<A> mono1 = service1.call().scheduleOn(Schedulers.parallel());
Mono<B> mono2 = service2.call().scheduleOn(Schedulers.parallel());
Mono<C> mono3 = service3.call().scheduleOn(Schedulers.parallel());

mono1.flatMap(res1 -> 
    mono2.flatMap(res2 -> 
        mono3.map(res3 -> {
            // 此时res1、res2、res3是串行获取的
            return combineResults(res1, res2, res3);
        })
    )
)
.onErrorResume(e -> {
    // 错误可能来自任意一个阶段，但前序已完成的服务不会被取消
    return Mono.just(defaultResult());
});

内容的提问来源于stack exchange，提问作者wrm