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 代码中看到回调嵌套 4 层、5 层甚至更多层并不罕见。
我们再次来权衡一下。如果你的主要性能问题是 I/O，则 Node 模型工作正常。然而，它的关键是，你可以在一个处理 HTTP 请求的函数里面放置 CPU 密集型的代码，而且不小心的话会导致每个连接都很慢。
最自然的非阻塞：Go在我进入 Go 部分之前，我应该披露我是一个 Go 的粉丝。我已经在许多项目中使用过它，我是一个其生产力优势的公开支持者，我在我的工作中使用它。
那么，让我们来看看它是如何处理 I/O 的。Go 语言的一个关键特征是它包含自己的调度程序。在 Go 中，不是每个执行线程对应于一个单一的 OS 线程，其通过一种叫做 “协程goroutine” 的概念来工作。而 Go 的运行时可以将一个协程分配给一个 OS 线程，使其执行或暂停它，并且它不与一个 OS 线程相关联——这要基于那个协程正在做什么。来自 Go 的 HTTP 服务器的每个请求都在单独的协程中处理。
调度程序的工作原理如图所示：
I/O Model Go
在底层，这是通过 Go 运行时中的各个部分实现的，它通过对请求的写入/读取/连接等操作来实现 I/O 调用，将当前协程休眠，并当采取进一步动作时唤醒该协程。
从效果上看，Go 运行时做的一些事情与 Node 做的没有太大不同，除了回调机制是内置到 I/O 调用的实现中，并自动与调度程序交互。它也不会受到必须让所有处理程序代码在同一个线程中运行的限制，Go 将根据其调度程序中的逻辑自动将协程映射到其认为适当的 OS 线程。结果是这样的代码：
func ServeHTTP(w http.ResponseWriter, r *http.Request){
// the underlying network call here is non-blocking
rows, 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 的方式不在其中。
谎言，可恶的谎言和基准