Springboot Webflux反​​应器并发模型

Question

我想了解更多有关springboot webflux的基础并发模型的信息？

对于CPU密集型Web服务，传统的阻塞多线程模型是否更合适？还是根据本文https://people.eecs.berkeley.edu/~brewer/papers/threads-hotos-2003.pdf，在一般传统线程池模型中更合适？

如果我在反应堆链中有阻塞步骤，则可以使用publishOn将其调度到其他线程池。这样是否可以释放原始线程并使整个链仍然畅通无阻？

Answer 1

WebFlux适合何处以及如何在引擎盖下工作

以我的观点，最适合Spring WebFlux的是网络密集型应用程序。在幕后，Spring WebFlux使用Reactor-Netty，它是Netty 周围支持背压的包装器。Reactor-Netty使用几乎相同的Netty线程策略，并Runtime.getRuntime().availableProcessors() * 2为其内部创建线程EventLoopThreadPool。这意味着每个Thread绑定到自己的内核/处理器，并以最少的CPU资源争用工作。这种模型在端到端的非阻塞通信中非常有效。因此，在传入请求最终以远程网络调用结束的情况下，该调用应以非阻塞方式执行，以便同一线程可以返回到偶数循环队列中的其余任务。这种技术使我们能够高效利用硬件，而几乎没有在上下文切换和高争用上花费的开销，这是阻止与大量相关线程进行通信的常见属性。

项目反应堆的作用

Spring WebFlux中Project Reactor的中心作用是提供一种编程模型，该模型可以保持复杂的非阻塞，异步执行的清晰度。它隐藏了数据处理连续性的复杂性，并使我们能够轻松地构建功能性的声明式元素处理管道。而且，Reactor的线程模型只是几个运算符，它们使复杂而高效的元素处理能够在专用线程池上进行重新调度而不会造成麻烦。在底层，使用了与Java Core库相同的ThreadPools和ExecutorServices。

如何处理CPU密集型任务，Project Reactor是否适合在那里？

我会说-Reactor Netty也非常适合CPU密集型任务。但在这种情况下，应适当使用Project Reactor。在复杂的算法处理或类似工作的情况下，最好使用纯Java，因为Reactor在性能方面会增加大约100-150％的开销。

如何使用Project Reactor和Reactor-Netty（WebFlux）构建高效的CPU密集型任务处理

我建议遵循以下模式“工作队列”，以便每个线程在上一个任务完成后将承担一个新任务。

如果我们有CPU密集型任务，则始终建议将其安排在专用线程池上。即使会增加一点点开销，我们的I / O读写延迟也会更高，这是任何联网应用程序不可或缺的一部分。对于Netty，我们将确保Netty的EventLoop只对网络进行读写。

要在专用线程池上安排任务，我们可以遵循以下代码示例中显示的技术：

@PostMapping
public Mono<CpuIntensiveResult> cpuIntensiveProcessingHandler(
    Mono<CpuIntensiveInput> monoInput
) {
    return monoInput
        .publishOn(Schedulers.fromExecutorService(myOwnDedicatedExecutor))
        .map(i -> doCpuIntensiveInImperativeStyle(i));
}

从上面的代码可以看到，使用Project Reactor军火库中的一名操作员，我们可以轻松地在专用Threadpool上安排工作处理。反过来，我们可以将任何现有的Executor服务快速包装到Scheduler中，并使用whit-in Reactor生态系统

阻塞多线程技术呢？

在通常的多线程技术中，线程多于内核，我们将不会获得任何好处。这里的缺点是相同的-上下文切换和竞争。似乎任务是同时处理的。但是，系统调度程序会在并发线程之间完成CPU时间分配方面的相同工作。它将在多个密集任务之间共享相同的CPU，因此最终导致每个任务的延迟增加。平均而言，处理时间将比使用与系统中CPU /内核相同数量的线程完成相同工作的时间长。

关于将线程模型作为“真实”处理模型的一些注意事项。

根据提到的白皮书，线程模型是真正的编程模型。我想，本文的作者正在谈论“ 绿色线程”。Green Threads可能是更好的编程模型，但是最后，您将必须遵循上述针对Reactor编程模型的相同规则。Thread和随后的命令式编程模型的缺点是无法使用数据流，而Reactor编程模型非常适合。

另外，我建议重新审视《通用可扩展性法》，并审查争用和一致性的问题（这与当前的Java线程执行有关）。另外，以下白皮书中对可伸缩性进行了很好的概述。

有效使用异步+非阻塞请求处理的另一个示例是Facebook体系结构，该体系结构在加载时将工作队列转换为工作堆栈，从而可以保持最低的延迟。