阻塞 Spring Data 和响应式 Spring Data 之间的区别？答案

【问题标题】：Difference between blocking Spring Data and reactive Spring Data?阻塞 Spring Data 和响应式 Spring Data 之间的区别？
【发布时间】：2020-09-06 02:19:41
【问题描述】：

如果我们可以将标准阻塞查询结果包装在反应流中，为什么还需要非阻塞数据库连接器？ Mongo、Redis 等非阻塞连接器实际上是从数据源流式传输数据，还是以阻塞方式获取数据，然后从内存中流式传输？ Mongo查询示例：

public interface ItemReactiveRepository extends ReactiveMongoRepository<Item,String> {

    //
}

...
Flux<Item> itemsFlux = itemReactiveRepository.findAll();

和

public interface ItemRepository extends MongoRepository<User, String> {
    // 
}
...
List<Item> itemsList = itemRepository.findAll(); 
Flux<Items> itemsFlux = Flux.fromIterable(itemsList );

如果有人能花时间解释一下，或者提供一个链接，我将不胜感激

【问题讨论】：

标签： java spring-data reactive-programming nonblocking project-reactor

【解决方案1】：

简短的回答是可扩展性。

在阻塞世界（JDBC、JPA 等）中，如果您想同时执行许多数据库查询，那么您需要的线程数与要执行的并发数据库查询数一样多。这工作正常，直到某一点。但是，线程不是免费的：它们需要内存，并且上下文切换会消耗 CPU 时间。因此，您拥有的并发性越多，您的系统就越困难。

非阻塞 IO（R2DBC、Reactive Mongo Driver 等）和响应式可让您摆脱这种每个连接线程的模型，并让您通过使用实现相同的并发性固定的低线程数（通常等于 CPU 内核数）。该模型提供了更高的可扩展性。

如果您只是将阻塞代码封装到响应式流中，则不会摆脱每个连接线程模型，您只会隐藏问题并最终会遇到相同的可伸缩性问题。

【讨论】：

一个数据库服务器可以同时处理多少个连接？我担心可伸缩性问题发生在服务器端的方式比客户端发生的问题要早，所以让客户端可伸缩是浪费时间。

【解决方案2】：

响应式代码不仅仅是“使用不同的对象”。这是一种完全不同的编写代码的方式，以确保线程永远不会阻塞（或等待）其他事情发生。它要么很忙，正在做一些处理，要么已经准备好等待。这些对象只是以这种风格编写代码的副作用。

理论上，我们可以使用现有的 Java 对象并仅使用“回调”来编写该代码。然而，虽然这种方法适用于在 UI 上单击按钮，但如果您尝试扩展这种方法，您很快就会陷入“回调地狱”。这就是为什么我们拥有提供诸如Flux 和Mono 之类的对象的框架，使我们能够以更明智、更强大的方式管理非阻塞代码。

这些对象还提供了获取“标准”对象并包装它们的实用方法（例如fromIterable() 或just()。）这些在某些情况下很有用，但可能会被误用 - 您的第二个示例就是这样；一些人称之为“冒名顶替”反应代码的情况。它根本不是“反应式”或非阻塞式的，它只是将阻塞方法调用包装在反应式对象中，以使它们看起来是反应式的。这很糟糕，因为这意味着使用您的方法的人，假设它们是响应式的，因为它们看起来是响应式的，实际上最终会在非阻塞线程上调用阻塞代码。这要么会导致整个实现崩溃，要么会严重减慢它的速度，然后可能意味着需要引入 Blockhound 等工具来追踪正在发生的事情。

简而言之，不可能采用阻塞代码并使其成为非阻塞 - 所以如果你认为你已经以某种方式做到了，那你就错了。它必须从头开始编写（不幸的是，这就是为什么 Java 上的完整反应式堆栈需要很长时间才能变得可行的原因。）然而，另一种方式是微不足道的 - 你可以阻止任何你想要的反应式调用。

【讨论】：