一些（Linux 系统调用的）示例可能有助于澄清： -read()是一个壅塞调用 - 你向它通报一个句柄，解释哪个文件和一个缓冲区将它读取的数据通报到哪里，并且当数据在那里时调用返回。请把稳，这具有都雅和大略的优点。-和调用epoll_create()，分别让您创建一组句柄进行监听，从该组添加/删除处理程序，然后壅塞直到有任何活动。这使您可以利用单个线程有效地掌握大量 I/O 操作。如果您须要该功能，这很好，但正如您所见，利用起来肯定更繁芜。epoll_ctl()epoll_wait()
在这里理解韶光差异的数量级很主要。如果 CPU 内核以 3GHz 运行，而无需进行 CPU 可以进行的优化，它每秒实行 30 亿个周期（或每纳秒 3 个周期）。一个非壅塞系统调用可能须要大约 10 秒的周期才能完成 - 或“相对几纳秒”。阻挡通过网络吸收信息的调用可能须要更长的韶光 - 例如 200 毫秒（1/5 秒）。例如，非壅塞调用耗时 20 纳秒，壅塞调用耗时 200,000,000 纳秒。您的进程只是等待壅塞调用的韶光长了 1000 万倍。
内核供应了壅塞 I/O（“从这个网络连接读取并给我数据”）和非壅塞 I/O（“见告我这些网络连接何时有新数据”）的方法。并且利用哪种机制将壅塞调用过程的韶光长度差异很大。
须要遵照的第三件事是当您有很多线程或进程开始壅塞时会发生什么。
就我们的目的而言，线程和进程之间并没有太大的差异。在现实生活中，与性能干系的最显著差异是，由于线程共享相同的内存，并且每个进程都有自己的内存空间，因此单独的进程每每会占用更多的内存。但是当我们评论辩论调度时，它真正归结为一个事物列表（线程和进程等），每个事物都须要在可用的 CPU 内核上得到一段实行韶光。如果你有 300 个线程和 8 个内核在运行它们，你必须将韶光分开，以便每个内核都得到它的份额，每个内核运行一小段韶光，然后转移到下一个线程。这是通过“高下文切换”完成的，使 CPU 从运行一个线程/进程切换到下一个。
这些高下文切换有与之干系的本钱——它们须要一些韶光。在一些快速的情形下，它可能小于 100 纳秒，但根据实现细节、处理器速率/架构、CPU 缓存等，它须要 1000 纳秒或更长的韶光并不少见。
并且线程（或进程）越多，高下文切换就越多。当我们评论辩论数千个线程，每个线程数百纳秒时，事情会变得非常缓慢。
然而，非壅塞调用实质上见告内核“只有当你在这些连接中的任何一个上有一些新数据或事宜时才给我打电话。” 这些非壅塞调用旨在有效处理大型 I/O 负载并减少高下文切换。
跟我到现在？由于现在是有趣的部分：让我们看看一些盛行的措辞如何利用这些工具，并就易用性和性能之间的权衡得出一些结论……以及其他有趣的花絮。
请把稳，虽然本文中显示的示例是微不足道的（并且是部分仅展示了干系内容）；数据库访问、外部缓存系统（memcache 等）以及任何必要 I/O 的东西终极都会在后台实行某种 I/O 调用，这与所示的大略示例具有相同的效果。此外，对付 I/O 被描述为“壅塞”的场景（PHP、Java），HTTP 要乞降相应的读取和写入本身便是壅塞调用：同样，更多的 I/O 隐蔽在系统中并伴随着性能问题考虑到。
为项目选择编程措辞有很多成分。当您只考虑性能时，乃至还有很多成分。但是，如果您担心您的程序将紧张受到 I/O 的限定，如果 I/O 性能对您的项目来说是成败，那么这些都是您须要理解的事情。
“保持大略”的方法：PHP早在 90 年代，很多人都穿着Converse鞋并用 Perl 编写 CGI 脚本。然后 PHP 涌现了，只管有些人喜好利用它，但它使动态网页变得更加随意马虎。
PHP 利用的模型相称大略。它有一些变革，但你的普通 PHP 做事器看起来像：
HTTP 要求来自用户的浏览器并访问您的 Apache Web 做事器。Apache 为每个要求创建一个单独的进程，并进行一些优化以重用它们，以只管即便减少它必须做的事情（相对而言，创建进程很慢）。Apache 调用 PHP 并见告它.php在磁盘上运行适当的文件。PHP 代码实行并壅塞 I/O 调用。您调用file_get_contents()PHP 并在后台进行read()系统调用并等待结果。
当然，实际代码只是直接嵌入到您的页面中，并且操作是壅塞的：
<?php// blocking file I/O$file_data = file_get_contents(‘/path/to/file.dat’);// blocking network I/O$curl = curl_init('http://example.com/example-microservice');$result = curl_exec($curl);// some more blocking network I/O$result = $db->query('SELECT id, data FROM examples ORDER BY id DESC limit 100');?>
就如何与系统集成而言，它是这样的：
非常大略：每个要求一个进程。I/O 调用只是壅塞。上风？这很大略，而且很有效。坏处？同时利用 20,000 个客户端攻击它，您的做事器将动怒。这种方法不能很好地扩展，由于没有利用内核供应的用于处理大量 I/O（epoll 等）的工具。雪上加霜的是，为每个要求运行一个单独的进程每每会利用大量系统资源，尤其是内存，这常日是在这种情形下你首先会用完的东西。
把稳：用于 Ruby 的方法与 PHP 的方法非常相似，并且从广义上讲，它们可以被认为与我们的目的相同。
多线程方法：Java以是 Java 涌现了，就在你购买第一个域名的时候，在一句话之后随便说“dot com”很酷。Java 在措辞中内置了多线程，这（尤其是在创建时）非常棒。
大多数 Java Web 做事器的事情办法是为每个传入的要求启动一个新的实行线程，然后在这个线程中终极调用您作为运用程序开拓职员编写的函数。
在 Java Servlet 中实行 I/O 看起来像这样：
public void doGet(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException{// blocking file I/OInputStream fileIs = new FileInputStream("/path/to/file");// blocking network I/OURLConnection urlConnection = (new URL("http://example.com/example-microservice")).openConnection();InputStream netIs = urlConnection.getInputStream();// some more blocking network I/Oout.println("...");}
由于我们doGet上面的方法对应一个要求并且在它自己的线程中运行，而不是每个要求须要自己的内存的单独进程，我们有一个单独的线程。这有一些不错的好处，比如能够在线程之间共享状态、缓存数据等，由于它们可以访问彼此的内存，但是对它如何与调度交互的影响仍旧险些与 PHP 中所做的相同前面的例子。每个要求都会得到一个新线程，并且该线程内的各种 I/O 操作会壅塞，直到要求被完备处理。线程被池化以最小化创建和销毁它们的本钱，但是，数千个连接意味着数千个线程，这对调度程序不利。
一个主要的里程碑是，Java 在 1.4 版（以及 1.7 版的重大升级）中得到了进行非壅塞 I/O 调用的能力。大多数运用程序，网络和其他运用程序，不该用它，但至少它是可用的。一些 Java Web 做事器试图以各种办法利用这一点。但是，绝大多数已支配的 Java 运用程序仍按上述办法事情。
Java 让我们更靠近，当然也有一些很好的开箱即用的 I/O 功能，但它仍旧不能真正办理当你有一个严重 I/O 绑定的运用程序时会发生的问题。有成千上万个壅塞线程的地面。
作为一等公民的非壅塞 I/O：Node当谈到更好的 I/O 时，盛行的孩子是 Node.js。任何对 Node 进行过最大略先容的人都被奉告它是“非壅塞的”并且它可以有效地处理 I/O。这在一样平常意义上是精确的。但妖怪在细节中，当谈到演出时，实现这种巫术的手段很主要。
从实质上讲，Node 实现的范式转变不是说“在此处编写代码以处理要求”，而是说“在此处编写代码以开始处理要求”。每次你须要做一些涉及 I/O 的事情时，你都会发出要求并给出一个回调函数，当它完成时 Node 会调用该回调函数。
在要求中实行 I/O 操作的范例 Node 代码如下所示：
http.createServer(function(request, response) {fs.readFile('/path/to/file', 'utf8', function(err, data) {response.end(data);});});
如您所见，这里有两个回调函数。第一个在要求开始时调用，第二个在文件数据可用时调用。
这样做基本上是让 Node 有机会在这些回调之间有效地处理 I/O。一个更干系的场景是你在 Node 中进行数据库调用，但我不会打扰这个例子，由于它的事理完备相同：你启动数据库调用，并给 Node 一个回调函数，它利用非壅塞调用分别实行 I/O 操作，然后在您要求的数据可用时调用您的回调函数。这种排队 I/O 调用并让 Node 处理它然后获取回调的机制称为“事宜循环”。而且效果很好。
然而，这个模型有一个问题。在幕后，它的缘故原由更多地与 V8 JavaScript 引擎（Node 利用的 Chrome 的 JS 引擎）的实现办法1有关。您编写的所有 JS 代码都在单个线程中运行。想一想。这意味着虽然 I/O 是利用高效的非壅塞技能实行的，但实行 CPU 绑定操作的 JS 可以在单个线程中运行，每个代码块都会壅塞下一个。可能涌现这种情形的一个常赐教例是循环数据库记录以在将它们输出到客户端之前以某种办法处理它们。这是一个示例，它显示了它是如何事情的：
var handler = function(request, response) {connection.query('SELECT ...', function (err, rows) {if (err) { throw err };for (var i = 0; i < rows.length; i++) {// do processing on each row}response.end(...); // write out the results})};
虽然 Node 确实有效地处理了 I/O，但上面示例中的循环(for)是在您的一个且唯一的主线程中利用 CPU 周期。这意味着，如果您有 10,000 个连接，则该循环可能会使您的全体运用程序陷入困境，详细取决于它须要多永劫光。每个要求都必须在主线程中共享一段韶光，一次一个。
全体观点所基于的条件是 I/O 操作是最慢的部分，因此有效地处理这些操作是最主要的，纵然这意味着要串行实行其他处理。在某些情形下确实如此，但并非全部如此。
另一点是，虽然这只是一种不雅观点，但编写一堆嵌套回调可能会很烦人，有些人认为这会使代码更难遵照。在 Node 代码深处嵌套四、五乃至更多级别的回调并不少见。
我们又回到了权衡。如果您的紧张性能问题是 I/O，则 Node 模型运行良好。然而，它的致命弱点是你可以进入一个处理 HTTP 要求的函数，并放入 CPU 密集型代码，如果你欠妥心的话，就会让每个连接都运行起来。
自然无壅塞：Go在我进入Go部分之前，我有必要透露一下我是Go迷。我已经将它用于许多项目，并且我公开支持它的生产力上风，当我利用它时，我在我的事情中看到了它们。
也便是说，让我们看看它是如何处理 I/O 的。Go 措辞的一个关键特性是它包含自己的调度程序。它不是每个实行线程都对应一个 OS 线程，而是利用“goroutines”的观点。Go 运行时可以将一个 goroutine 分配给一个 OS 线程并让它实行，或者挂起它并且让它不与 OS 线程干系联，这取决于该 goroutine 正在做什么。来自 Go 的 HTTP 做事器的每个要求都在一个单独的 Goroutine 中处理。
调度程序的事情事理图如下所示：
在底层，这是由 Go 运行时中的各个点实现的，这些点通过发出写入/读取/连接/等要求来实现 I/O 调用，使当前 goroutine 进入就寝状态，并供应唤醒 goroutine 的信息当可以采纳进一步辇儿为时。
实际上，Go 运行时所做的事情与 Node 所做的事情并没有太大的不同，只是回调机制内置在 I/O 调用的实现中并自动与调度程序交互。它也不受必须让你的所有处理程序代码在同一个线程中运行的限定，Go 会根据其调度程序中的逻辑自动将你的 Goroutine 映射到它认为得当的尽可能多的 OS 线程。结果是这样的代码：
func ServeHTTP(w http.ResponseWriter, r http.Request) {// the underlying network call here is non-blockingrows, err := db.Query("SELECT ...")for _, row := range rows {// do something with the rows,// each request in its own goroutine}w.Write(...) // write the response, also non-blocking}
正如您在上面看到的，我们所做的基本代码构造类似于更大略的方法，但在底层实现了非壅塞 I/O。
在大多数情形下，这终极会成为“两全其美”。非壅塞 I/O 用于所有主要的事情，但您的代码看起来像是壅塞的，因此更易于理解和掩护。Go 调度程序和 OS 调度程序之间的交互处理别的的。这不是完备的邪术，如果你构建了一个大型系统，值得花韶光理解更多关于它如何事情的细节；但与此同时，您“开箱即用”的环境可以很好地事情和扩展。
Go 可能有它的缺陷，但一样平常来说，它处理 I/O 的办法不在个中。
谎话，该死的谎话和基准很难给出这些不同模型所涉及的高下文切换的确切韶光。我也可以争辩说它对你没那么有用。因此，我将为您供应一些比较这些做事器环境的整体 HTTP 做事器性能的基本基准。请记住，全体端到端 HTTP 要求/相应路径的性能涉及很多成分，这里供应的数字只是我汇总的一些示例，以进行基本比较。
对付这些环境中的每一个，我编写了适当的代码来读取一个包含随机字节的 64k 文件，对其运行 SHA-256 哈希 N 次（N 在 URL 的查询字符串中指定，例如，.../test.php?n=100）并打印结果十六进制哈希。我之以是选择它，是由于它是一种非常大略的方法，可以通过一些同等的 I/O 运行相同的基准测试，并且是一种增加 CPU 利用率的受控方法。
有关所利用环境的更多详细信息，请参阅这些基准测试解释。
首先，让我们看一些低并发的例子。运行 2000 次迭代和 300 个并发要求，每个要求只有一个哈希（N=1）给我们这个：
韶光是在所有并发要求中完成要求的均匀毫秒数。越低越好。
仅从这张图很难得出结论，但在我看来，在这种连接和打算量下，我们看到的韶光更多地与措辞本身的一样平常实行有关，更主要的是输入/输出。请把稳，被认为是“脚本措辞”的措辞（疏松类型、动态阐明）实行速率最慢。
但是如果我们将 N 增加到 1000 会发生什么，仍旧有 300 个并发要求 - 相同的负载但 100 倍以上的哈希迭代（显著更多的 CPU 负载）：
韶光是在所有并发要求中完成要求的均匀毫秒数。越低越好。
溘然之间，Node 性能显著低落，由于每个要求中的 CPU 密集型操作相互壅塞。有趣的是，PHP 的性能变得更好（相对付其他）并且在这个测试中击败了 Java。（值得把稳的是，在 PHP 中，SHA-256 实现是用 C 编写的，并且实行路径在该循环中花费了更多韶光，由于我们现在正在进行 1000 次哈希迭代）。
现在让我们考试测验 5000 个并发连接（N=1）——或者尽可能靠近。不幸的是，对付这些环境中的大多数，故障率并非微不足道。对付此图表，我们将查看每秒的要求总数。越高越好：
每秒的要求总数。越高越好。
而且图片看起来完备不同。这是一个预测，但看起来在高连接量下，产生新进程所涉及的每个连接开销以及 PHP+Apache 中与之干系的额外内存彷佛成为紧张成分，并降落了 PHP 的性能。显然，Go 是这里的赢家，其次是 Java、Node，末了是 PHP。
虽然与您的整体吞吐量有关的成分很多，并且因运用程序而异，但您对幕后发生的事情和所涉及的权衡理解得越多，您的情形就会越好。
综上所述，很明显，随着措辞的发展，处理大量 I/O 的大规模运用程序的办理方案也随之发展。
公正地说，只管本文中有描述，但 PHP 和 Java 都具有可用于Web 运用程序的非壅塞I/O实现。但是这些并不像上述方法那样普遍，并且须要考虑利用这些方法掩护做事器所带来的操作开销。更不用说您的代码必须以适用于此类环境的办法构建；您的“普通” PHP 或 Java Web 运用程序常日不会在这样的环境中未经重大修正而运行。
作为比较，如果我们考虑一些影响性能和易用性的主要成分，我们会得到：
措辞
线程与进程
非壅塞 I/O
便于利用
PHP
流程
否
java
线程
可用的
须要回调
node.js
线程
是的
须要回调
Go
线程（Goroutines）
是的
不须要回调
线程常日比进程的内存效率要高得多，由于它们共享相同的内存空间，而进程则没有。将其与与非壅塞 I/O 干系的成分结合起来，我们可以看到，至少在考虑到上述成分的情形下，当我们向下移动列表时，与 I/O 干系的一样平常设置得到了改进。因此，如果我必须在上述比赛中选出一名得胜者，那肯定是Go!
只管如此，在实践中，选择构建运用程序的环境与您的团队对该环境的熟习程度以及您可以通过它实现的整体生产力密切干系。因此，每个团队都开始利用 Node 或 Go 开拓 Web 运用程序和做事可能没故意义。事实上，探求开拓职员或熟习内部团队常日被认为是不该用不同措辞和/或环境的紧张缘故原由。也便是说，在过去十五年旁边的韶光里，时期已经发生了很大变革。
希望以上内容有助于更清楚地理解幕后发生的事情，并为您供应一些关于如何处理运用程序的实际可伸缩性的想法。快乐的输入和输出！
