Node.js中的响应顺序？
我已经阅读了关于Node.js和Event Loop的一些介绍性文章，但有一点是不清楚的 – 如果有多个并发请求，那么响应总是按请求的顺序连续的？ 如果20个请求同时完成，那么第20个响应是否需要等待另外19个请求被清除（回复给客户端）？
更新：我想知道的是，这是否类似于多个setTimeouts排队？
node.js以单线程运行Javascript。 因此，在任何时候只有一块Javascript正在运行。
但是，几乎所有的I / O（例如networking，文件访问等）都是asynchronous和非阻塞的。 因此，如果20个请求是在很短的时间内完成的，那么到达服务器的第一个请求将开始执行请求处理程序，其他请求将排队。 但是，只要第一个请求遇到asynchronous操作（例如从本地文件系统读取），该请求将被挂起，而非阻塞asynchronousI / O正在发生，并且下一个请求将开始运行。
然后这个第二个请求将运行，直到它完成或直到它也碰到一个asynchronousI / O。 当第二个请求等待asynchronousI / O时，另一个请求将会运行。 系统调度程序将确定下一个操作是否完成来自第一个请求的asynchronousI / O请求，或者是否将启动在队列中等待的第三个请求。
各种要求将继续这种方式，直到一切完成。 多个请求可能同时处于“正在运行中”（意味着它们已经启动，但还没有完成），但是在任何特定时刻，只有一个实际上正在执行代码。
这有时被称为合作任务。 在不同的请求之间没有先发制人的多任务，每个请求都自动获得主机CPU的时间片。 但是，任何时候请求都会触发一个asynchronousI / O操作，然后告诉调度器等待运行的其他请求可以运行。
这是从node.js中的事件队列pipe理的。 一段JavaScript运行，直到它完成。 如果它产生一个asynchronousI / O请求，然后完成，那么等待运行的另一块Javascript也可以开始运行。 完成后，JS引擎将下一个项目从事件队列中拉出并运行。 这可能是一个新的传入请求，也可能是某个其他请求的一些asynchronousI / O操作的完成。
这种types的系统的优点是：
-
它的扩展性非常好，尤其是对于I / O绑定的服务器操作，因为只有一个单独的Javascript线程可以同时有很多请求“在线”。 合作任务非常轻巧，快捷。
-
对这样的系统进行编程，要注意的“竞争条件”要less得多，因为在实际的同一时间，没有两个Javascript脚本运行。 这意味着您可以经常在请求之间共享状态，而不必使用互斥锁（就像在multithreading环境中一样）。 由于线程安全的错误通常是非常难以避免和testing的，所以消除这些types的错误是一个主要优势。
-
合作模式在概念上简单易学，安全编程。
这种types的系统的缺点是：
-
它不会在CPU限制的任务之间共享CPU。 一个有大量计算CPU的node.js程序员往往不得不使用集群或subprocess来处理堆栈CPU计算，以避免主要请求处理Javascript线程负担过重，并且使得它不能响应。
-
需要对进程进行集群，以最大限度地利用多个处理器，然后必须在这些进程之间共享任何共享数据。 人们经常使用像Redis这样的内存数据库来在进程之间共享数据。
-
你不能只是无法启动另一个Javascript线程去做什么。