非阻塞IO + fork/join VS标准多线程管理

Question

我会比较这两种方法的Java和NodeJS的例子。当然，如果你愿意，你可以选择其他语言。

我们有什么： 如您所知，非阻塞IO成为编写高负载系统的主流。如您所知，NodeJS是单线程非阻塞IO，具有clustering possibilities。这意味着，我们可以有多个单线程服务器，而不是一个多线程服务器。而Java同时具有：非阻塞IO库（Netty和基于它的框架，如Play框架）和传统多线程（不基于事件），它为程序员提供所有线程管理。

我的困惑：我听到很多抱怨传统的多线程，大约是多么困难调试这些程序和他们与非阻塞IO相比是相当缓慢的。另一方面，我听到很多关于非阻塞IO的恭维，比如Node，以及如何轻松地将它扩展到带有fork/join库的多线程程序。

所以，如果非阻塞IO是那么好 问题：当我们仍然可以从传统（基于事件没有）多线程获得优势与非阻塞IO相比？

P.S.有人曾经写过应用程序，你有很多单线程非阻塞IO服务器，只是分配它们之间的负载？

Answer 1

非阻塞IO -的NodeJS
所有请求都由一个单独的线程，其不断循环，并具有处理多个请求处理。那么它怎么不会被压倒？那么通常需要最长时间的操作是I/O操作（读取文件/数据库）。节点将这些传递给另一个进程，并在其循环中继续进行呼叫。当I/O完成时，发生回调并且主循环处理它。

只要主循环不会在计算任务中陷入停滞状态，它就可以很好地工作。

传统阻塞服务器
每个请求都有自己的线程这确实它自己的计算和I/O操作。计算是在I/O交给OS或其他进程时在其自己的线程上执行的。线程将在I/O执行时阻塞，但不重要，因为每个请求都有一个单独的线程。

因为每个请求都有自己的线程，所以计算密集型任务不会像其他节点那样影响其他请求。

Answer 2

最好的解决方案是使用nodejs来处理I/O（db查询，对web服务的请求，与其他应用程序的套接字连接...），让我们说Apache来处理需要计算的请求。

想象一下，需要回答一个I/O部分和一个计算部分的请求：例如，从数据库中检索大量记录，并在这些记录上检索某些消耗CPU的任务。 我可以想象最适合上述需求的最佳应用程序是请求由一个nodejs Web服务器处理的应用程序，该服务器查询数据库，然后将记录传递给Apache Web服务器以执行计算部分。 最后，当Apache使用完全使用的专用线程处理计算部分时，nodejs执行2个I/O任务（db查询和询问Apache web服务）。