问题描述
阅读有关Play框架和ReactiveMongo的文档使我相信ReactiveMongo的工作方式是使用很少的线程，并且永远不会阻塞.
但是，似乎从Play应用程序到Mongo服务器的通信必须发生在某个地方的某个线程上.如何实施?还将非常感谢您链接到Play，ReactiveMongo，Akka等源代码.
此页面上的Play框架包含与此有关的一些文档关于线程池 .它开始于:
然后它谈论了有关ReactiveMongo的一些内容:
以下是有关使用期货的注释:
页面处理异步结果:
文档似乎在说ReactiveMongo是非阻塞的，因此您不必担心它会耗尽线程池中的许多线程.但是ReactiveMongo必须与Mongo服务器某处进行通信.
如何实现这种通信，以使Mongo不会用尽Play的默认线程池中的线程?
再次，链接到播放， ReactiveMongo ， Akka 等，将不胜感激.
是的，确实，您仍然需要使用线程来执行任何类型的工作，包括与数据库的通信.重要的是该通信发生的准确程度.
ReactiveMongo在不使用阻塞I/O 的意义上不使用线程".像java.io.InputStream这样的常规Java I/O设施正在阻塞；这意味着从这样的InputStream读取或写入OutputStream会阻塞线程，直到另一侧"提供所需的数据或准备接受它为止.对于网络通信，这意味着线程 将被阻止.
但是，Java提供了 NIO API ，该API支持 non-blocking 和 asynchronous I/O.我现在不想详细介绍它，但是基本的想法自然是，非阻塞I/O不允许阻塞需要与外界交换一些数据的线程:例如，这些线程可以轮询数据源以检查是否有可用数据，如果没有可用数据，它们将返回线程池并可用于其他任务.当然，这些功能是由底层操作系统提供的.
非阻塞I/O的确切实现细节通常隐藏在 Netty 之类的高级库中，因为它根本不适合使用.例如，Netty(正是ReactiveMongo使用的库)提供了不错的异步回调类API，该API确实易于使用，但功能强大且表达能力强，可以构建具有高吞吐量的复杂I/O繁重的应用程序. >
因此，ReactiveMongo使用Netty与Mongo数据库服务器进行通信，并且由于Netty是异步网络I/O的实现，因此ReactiveMongo确实不需要长时间阻塞线程.
Reading the documentation about the Play Framework and ReactiveMongo leads me to believe that ReactiveMongo works in such a way that it uses few threads and never blocks.
However, it seems that the communication from the Play application to the Mongo server would have to happen on some thread somewhere. How is this implemented? Links to the source code for Play, ReactiveMongo, Akka, etc. would also be very appreciated.
The Play Framework includes some documentation about this on this page about thread pools. It starts off:
It then talks a little bit about ReactiveMongo:
Following is a note about using Futures:
There is a similar note in the Play documentation on the page Handling Asynchronous Results:
The documentation seems to be saying that ReactiveMongo is non-blocking, so you don't have to worry about it eating up a lot of the threads in your thread pool. But ReactiveMongo has to communicate with the Mongo server somewhere.
How is this communication implemented so that Mongo doesn't use up threads from Play's default thread pool?
Once again, links to the specific files in Play, ReactiveMongo, Akka, etc, would be very appreciated.
Yes, indeed, you still need to use threads to perform any kind of work, including communication with the database. What's important is how exactly this communication happens.
ReactiveMongo "does not use threads" in a sense that it does not use blocking I/O. Usual Java I/O facilities like java.io.InputStream are blocking; this means that reading from such an InputStream or writing to OutputStream blocks the thread until the "other side" provides the required data or is ready to accept it. For network communication this means that threads will be blocked.
However, Java provides NIO API which supports non-blocking and asynchronous I/O. I don't want to get into its details right now, but the basic idea, naturally, is that non-blocking I/O allow not to block threads which need to exchange some data with the outside world: for example, these threads can poll the data source to check if there is some data available, and if there is none, they return to the thread pool and can be used for other tasks. Of course, down there these facilities are provided by the underlying OS.
Exact implementation details of non-blocking I/O is usually hidden inside high-level libraries like Netty because it is not at all nice to use. Netty (which is exactly the library ReactiveMongo uses), for example, provides nice asynchronous callback-like API which is really easy to use but is also powerful and expressive enough to allow building complex I/O-heavy applications with high throughput.
So, ReactiveMongo uses Netty to talk with Mongo database server, and because Netty is an implementation of asynchronous network I/O, ReactiveMongo really does not need to block threads for a long time.
这篇关于如何实现ReactiveMongo，以便将其视为非阻塞?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！