使用响应式弹簧数据mongdb和阻塞方法的负面影响/性能影响

如何解决使用响应式弹簧数据mongdb和阻塞方法的负面影响/性能影响

我对反应式编程非常陌生，目前正在从事微服务，其中使用spring mvc和使用Spring Data MongoDb进行数据库连接。

我正在查看Spring Data Mongo db文档时，支持反应式存储库，相对模板api等。

因此，如果我选择使用具有阻塞性质的反应性模板和存储库，会有什么弊端吗？

Ex.    
reactiveMongoTemplate.add(entity).block()
reactiveMongoTemplate.update(id,entity).block()

使用上述调用与使用阻塞存储库和模板api本身还有显着区别吗？

解决方法

答案取决于您使用的堆栈：Spring WebFlux或Spring Web MVC。

对于 Spring WebFlux ，选择是显而易见的：您必须使用ReactiveMongoTemplate 并从不调用 block，而是从模板获取它时返回Mono / Flux。

对于 Spring Web MVC ，您可以将常规阻止MongoTemplate和ReactiveMongoTemplate与block一起使用。尽管在大多数情况下，为简单起见和性能，您应该使用旧的MongoTemplate 。与阻塞式MongoTemplate相比，ReactiveMongoTemplate具有一些开销，因为反应性类型Mono / Flux给内存带来了额外的压力。

我可以想象一个用例，即使在Spring MVC中，ReactiveMongoTemplate也可以提供一些优势：当在一个HTTP请求期间，您必须同时执行多个Mono操作。如果您使用了阻塞MongoTemplate，那么您将需要设置一个线程池并在其中委派查询执行。但是，使用ReactiveMongoTemplate，您可以使用Mono和Flux的许多运算符来完成此任务，而不必担心线程，线程池和扩展问题。

,

在传统编程中，您通常拥有正在运行的线程，而在反应式编程中则并非如此。这个“执行的基础单元”（如果需要，可以使用cpu资源）不是您的，而是当前执行任务的“全局”事物，但是可以很快地做其他事情。

因此，当您阻止时，您就对这个“全局执行单元”说“嘿，别做任何事情，等我”。在传统方法中，这是可以的，因为您有一个与当前请求关联的线程，所以其他请求（如果您的系统不是基于Web的则为流）应该与来自相当大的线程池的其他线程一起执行。但是，在反应式系统中，情况并非如此，因为您尝试利用少量的这些“全局执行单元”。

好，因此，如果您阻止了，则整个地方的事件将停止发出并开始缓冲。这可能会导致整个系统无法使用。