blocks|key|196312|text|如果你读得更深入一些-“当然，在后端，有用于DB访问和进程执行的线程和进程。但是，这些线程和进程并没有显式地暴露给你的代码，所以除了知道I/O交互(例如与数据库或与其他进程的I/O交互)从每个请求的角度来看将是异步的，因为这些线程的结果通过事件循环返回到你的代码之外，你不需要担心它们。”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|196313|关于-“除了你的代码之外所有的东西都是并行运行的”-你的代码是同步执行的，每当你调用一个异步操作，比如等待IO，事件循环就会处理所有的事情并调用回调。这不是你必须要考虑的事情。|196314|在您的示例中:有两个请求A(最先出现)和B。您执行请求A，您的代码继续同步运行并执行请求B。事件循环处理请求A，当它使用结果调用请求A的回调时，请求B也是如此。|196315|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

if you read a bit further - "Of course, on the backend, there are threads and processes for DB access and process execution. However, these are not explicitly exposed to your code, so you can’t worry about them other than by knowing that I/O interactions e.g. with the database, or with other processes will be asynchronous from the perspective of each request since the results from those threads are returned via the event loop to your code."

about - "everything runs in parallel except your code" - your code is executed synchronously, whenever you invoke an asynchronous operation such as waiting for IO, the event loop handles everything and invokes the callback. it just not something you have to think about.

in your example: there are two requests A (comes first) and B. you execute request A, your code continue to run synchronously and execute request B. the event loop handles request A, when it finishes it invokes the callback of request A with the result, same goes to request B.

blocks|key|3040180|text|好吧，为了提供一些观点，让我来比较一下node.js和apache。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3040181|Apache是一个多线程HTTP服务器，对于服务器接收到的每个请求，它都会创建一个单独的线程来处理该请求。|3040182|另一方面，Node.js是事件驱动的，从单个线程异步处理所有请求。|3040183|当apache接收到A和B时，将创建两个处理请求的线程。每个都单独处理查询，每个都在提供页面之前等待查询结果。该页面仅在查询完成之前提供。查询获取被阻塞，因为服务器在收到结果之前无法执行线程的其余部分。|3040184|在节点中，c.query是异步处理的，这意味着当c.query获取A的结果时，它跳转到处理B的c.query，当A的结果到达时，它将结果发送回发送响应的回调。Node.js知道在fetch完成时执行回调。|3040185|3040186|在我看来，因为它是单线程模型，所以没有办法从一个请求切换到另一个请求。|blockquote|3040187|3040188|3040189|实际上，节点服务器一直都在为您做这件事。为了进行切换，(异步行为)您将使用的大多数函数都会有回调。|3040190|编辑|3040191|SQL查询取自mysql库。它实现了回调样式和事件发射器来对SQL请求进行排队。它不异步执行它们，这是由提供非阻塞I/O抽象的内部libuv线程完成的。执行查询需要执行以下步骤：|offset|length|3040192|3040193|打开到数据库的连接，连接本身即可连接到数据库，查询将传递到服务器。查询可以排队。|ordered-list-item|3040194|通过回调或事件通知主事件循环完成。|3040195|主循环执行您的查询|3040196|3040197|以类似的方式处理到http服务器的传入请求。内部线程架构是这样的：|3040198|​|3040199|📷|atomic|3040200|3040201|Libuv线程是执行异步I/O+(磁盘或网络)的C%2B%2B线程。在将请求分派到线程池之后，主事件循环将继续执行。它可以接受更多的请求，因为它不等待或休眠。SQL查询/HTTP请求/文件系统读取都是这样发生的。|3040202|entityMap|0|LINK|mutability|MUTABLE|url|https://npmjs.org/package/mysql|1|http://nikhilm.github.io/uvbook/index.html|2|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/2b9e6d6090c4b204d7fef478a45721ad.png|imageAlt^0|0|0|0|0|0|0|0|0|0|0|0|7|5|0|1T|5|1|0|0|0|0|0|0|0|0|0|1|2|0|0|0^^$0|@$1|2|3|4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1X|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|20|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|21|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|22|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|23|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|24|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|25|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|26|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|27|8|@]|9|@$V|28|W|29|1|2A]|$V|2B|W|2C|1|2D]]|A|$]]|$1|X|3|-4|5|6|7|2E|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|10|7|2F|8|@]|9|@]|A|$]]|$1|11|3|12|5|10|7|2G|8|@]|9|@]|A|$]]|$1|13|3|14|5|10|7|2H|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|2I|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|2J|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|2K|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|1C|7|2L|8|@]|9|@$V|2M|W|2N|1|2O]]|A|$]]|$1|1D|3|19|5|6|7|2P|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|1G|3|-4|5|6|7|2R|8|@]|9|@]|A|$]]]|1H|$1I|$5|1J|1K|1L|A|$1M|1N]]|1O|$5|1J|1K|1L|A|$1M|1P]]|1Q|$5|1R|1K|1S|A|$1T|1U|1V|-4]]]]

Well, to give some perspective, let me compare node.js with apache.
Apache is a multi-threaded HTTP server, for each and every request that the server receives, it creates a separate thread which handles that request.
Node.js on the other hand is event driven, handling all requests asynchronously from single thread.
When A and B are received on apache, two threads are created which handle requests. Each handling the query separately, each waiting for the query results before serving the page. The page is only served until the query is finished. The query fetch is blocking because the server cannot execute the rest of thread until it receives the result.
In node, c.query is handled asynchronously, which means while c.query fetches the results for A, it jumps to handle c.query for B, and when the results arrive for A arrive it sends back the results to callback which sends the response. Node.js knows to execute callback when fetch finishes.
<blockquote>
In my opinion, because it's a single thread model, there is no way to
switch from one request to another.
</blockquote>
Actually the node server does exactly that for you all the time. To make switches, (the asynchronous behavior) most functions that you would use will have callbacks.
<h3>Edit</h3>
The SQL query is taken from <a href="https://npmjs.org/package/mysql" rel="noreferrer">mysql</a> library. It implements callback style as well as event emitter to queue SQL requests. It does not execute them asynchronously, that is done by the internal <a href="http://nikhilm.github.io/uvbook/index.html" rel="noreferrer">libuv</a> threads that provide the abstraction of non-blocking I/O. The following steps happen for making a query :
<ol>
<li>Open a connection to db, connection itself can be made asynchronously.</li>
<li>Once db is connected, query is passed on to the server. Queries can be queued.</li>
<li>The main event loop gets notified of the completion with callback or event.</li>
<li>Main loop executes your callback/eventhandler.</li>
</ol>
The incoming requests to http server are handled in the similar fashion. The internal thread architecture is something like this:
<img src="https://i.stack.imgur.com/YCTgK.png" alt="node.js event loop" />
The C++ threads are the libuv ones which do the asynchronous I/O (disk or network). The main event loop continues to execute after the dispatching the request to thread pool. It can accept more requests as it does not wait or sleep. SQL queries/HTTP requests/file system reads all happen this way.

blocks|key|3040255|text|Node.js构建在libuv之上，这是一个跨平台库，为受支持的OSes+(至少是Unix、OS和Windows+)提供的异步(非阻塞)输入/输出抽象apis/系统调用。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3040256|异步IO|3040257|在此编程模型中，设备和资源(套接字、文件系统等)上的打开/读/写操作由文件系统管理，不要阻塞调用线程(就像在典型的同步类c模型中一样)，只需标记进程(在内核/OS级数据结构中)，以便在有新数据或事件可用时得到通知。如果是类似web服务器的应用程序，则流程负责找出通知的事件属于哪个请求/上下文，并从那里继续处理请求。请注意，这必然意味着您将处于与向OS发出请求的堆栈框架不同的堆栈框架上，因为后者必须屈从于进程的调度程序，以便让单线程进程处理新事件。|3040258|我所描述的模型的问题是，对于程序员来说，它并不熟悉，也很难推理，因为它本质上是非顺序的。“您需要在函数A中发出请求，并在另一个函数中处理结果，在该函数中，来自A的本地变量通常不可用。”|3040259|节点的模型(延续传递风格和事件循环)|3040260|Node利用javascript的语言特性解决了这个问题，通过诱导程序员使用某种编程风格，使这个模型看起来更同步。每个请求IO的函数都有一个类似于function+(...+parameters+...,+callback)的签名，并且需要提供一个回调函数，该回调函数将在请求的操作完成时调用(请记住，大部分时间都花在等待操作系统发出完成信号-可以用来做其他工作的时间)。Javascript对闭包的支持允许您使用在回调主体内的外部(调用)函数中定义的变量-这允许在将由节点运行时独立调用的不同函数之间保持状态。另请参见Continuation+Passing+Style。|style|CODE|3040261|此外，在调用产生IO操作的函数之后，调用函数通常会将控制return到节点的事件循环。此循环将调用计划执行的下一个回调或函数(很可能是因为操作系统通知了相应的事件)-这允许并发处理多个请求。|BOLD|3040262|您可以将节点的事件循环看作类似于内核的分派器的：内核将调度阻塞的线程在其挂起的IO完成后执行，而节点将在相应的事件发生时调度回调。|3040263|高并发，无并行|3040264|最后，“除了你的代码之外的所有东西都是并行运行的”这句话很好地抓住了这一点，节点允许你的代码通过在一个单一的执行流中对所有的js逻辑进行多路复用和排序，用一个线程并发地处理来自数十万个打开的套接字的请求(即使在这里说“所有东西都并行运行”可能是不正确的-请参阅Concurrency+vs+Parallelism+-+What+is+the+difference?)。这对于webapp服务器非常有效，因为大多数时间实际上都花在等待网络或磁盘(数据库/套接字)上，并且逻辑并不是真正的CPU密集型-也就是说：这对于IO绑定的工作负载很有效。|3040265|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/libuv/libuv|1|http://en.wikipedia.org/wiki/Continuation_passing_style|2|https://stackoverflow.com/questions/1050222/concurrency-vs-parallelism-what-is-the-difference^0|A|5|0|0|0|0|0|0|21|13|78|Q|1|0|S|6|12|4|0|N|16|0|0|7|0|0|7I|3M|1G|2|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@$A|1B|B|1C|1|1D]]|C|$]]|$1|D|3|E|5|6|7|1E|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1F|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|1G|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1H|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1I|8|@$A|1J|B|1K|N|O]]|9|@$A|1L|B|1M|1|1N]]|C|$]]|$1|P|3|Q|5|6|7|1O|8|@$A|1P|B|1Q|N|O]|$A|1R|B|1S|N|R]]|9|@]|C|$]]|$1|S|3|T|5|6|7|1T|8|@$A|1U|B|1V|N|R]]|9|@]|C|$]]|$1|U|3|V|5|6|7|1W|8|@$A|1X|B|1Y|N|R]]|9|@]|C|$]]|$1|W|3|X|5|6|7|1Z|8|@$A|20|B|21|N|R]]|9|@$A|22|B|23|1|24]]|C|$]]|$1|Y|3|-4|5|6|7|25|8|@]|9|@]|C|$]]]|Z|$10|$5|11|12|13|C|$14|15]]|16|$5|11|12|13|C|$14|17]]|18|$5|11|12|13|C|$14|19]]]]

Node.js is built upon <a href="https://github.com/libuv/libuv" rel="noreferrer">libuv</a>, a cross-platform library that abstracts apis/syscalls for asynchronous (non-blocking) input/output provided by the supported OSes (Unix, OS X and Windows at least).

<h2>Asynchronous IO</h2>

In this programming model open/read/write operation on devices and resources (sockets, filesystem, etc.) managed by the file-system don't block the calling thread (as in the typical synchronous c-like model) and just mark the process (in kernel/OS level data structure) to be notified when new data or events are available. In case of a web-server-like app, the process is then responsible to figure out which request/context the notified event belongs to and proceed processing the request from there. Note that this will necessarily mean you'll be on a different stack frame from the one that originated the request to the OS as the latter had to yield to a process' dispatcher in order for a single threaded process to handle new events.

The problem with the model I described is that it's not familiar and hard to reason about for the programmer as it's non-sequential in nature. "You need to make request in function A and handle the result in a different function where your locals from A are usually not available."

<h2>Node's model (Continuation Passing Style and Event Loop)</h2>

Node tackles the problem leveraging javascript's language features to make this model a little more synchronous-looking by inducing the programmer to employ a certain programming style. Every function that requests IO has a signature like <code>function (... parameters ..., callback)</code> and needs to be given a callback that will be invoked when the requested operation is completed (keep in mind that most of the time is spent waiting for the OS to signal the completion - time that can be spent doing other work). Javascript's support for closures allows you to use variables you've defined in the outer (calling) function inside the body of the callback - this allows to keep state between different functions that will be invoked by the node runtime independently. See also <a href="http://en.wikipedia.org/wiki/Continuation_passing_style" rel="noreferrer">Continuation Passing Style</a>.

Moreover, after invoking a function spawning an IO operation the calling function will usually <code>return</code> control to node's event loop. This loop will invoke the next callback or function that was scheduled for execution (most likely because the corresponding event was notified by the OS) - this allows the concurrent processing of multiple requests.

You can think of node's event loop as somewhat similar to the kernel's dispatcher: the kernel would schedule for execution a blocked thread once its pending IO is completed while node will schedule a callback when the corresponding event has occured.

<h2>Highly concurrent, no parallelism</h2>

As a final remark, the phrase "everything runs in parallel except your code" does a decent job of capturing the point that node allows your code to handle requests from hundreds of thousands open socket with a single thread concurrently by multiplexing and sequencing all your js logic in a single stream of execution (even though saying "everything runs in parallel" is probably not correct here - see <a href="https://stackoverflow.com/questions/1050222/concurrency-vs-parallelism-what-is-the-difference">Concurrency vs Parallelism - What is the difference?</a>). This works pretty well for webapp servers as most of the time is actually spent on waiting for network or disk (database / sockets) and the logic is not really CPU intensive - that is to say: this works well for IO-bound workloads.

blocks|key|196420|text|好的，到目前为止大多数事情都应该很清楚了.棘手的部分是SQL：如果它实际上不是在另一个线程或进程中完整运行的，SQL+-必须被分解成单独的步骤(由一个为异步执行而设计的SQL处理器！)，在那里非阻塞的部分被执行，而阻塞的部分(例如睡眠)实际上可以被转移到内核(作为警报中断/事件)并放在主循环的事件列表中。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|196421|这意味着，例如，SQL等的解释是立即完成的，但在等待期间(由内核作为将来到来的事件存储在一些kqueue、epoll、...结构；与其他IO操作一起)主循环可以做其他事情，并最终检查这些IO和等待是否发生了什么。|196422|因此，换句话说:程序永远不会(允许)卡住，休眠调用永远不会执行。它们的职责是由内核(编写一些东西，等待网络上的某些东西，等待时间过去)或另一个线程或进程来完成的。-+Node进程在每个事件循环周期中检查内核是否在对操作系统的唯一阻塞调用中完成了这些职责中的至少一个。当所有非阻塞操作都完成时，就达到了这一点。|196423|清除？:-)|196424|我不知道诺德。但是c.query从何而来呢？|196425|entityMap^0|L|9|1I|6|1R|8|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|X|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|Y|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|Z|8|@]|D|@]|E|$]]|$1|N|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|O|$]]

Okay, most things should be clear so far... the tricky part is the SQL: if it is not in reality running in another thread or process in it’s entirety, the SQL-execution has to be broken down into individual steps (by an SQL processor made for asynchronous execution!), where the non-blocking ones are executed, and the blocking ones (e.g. the sleep) actually can be transferred to the kernel (as an alarm interrupt/event) and put on the event list for the main loop.

That means, e.g. the interpretation of the SQL, etc. is done immediately, but during the wait (stored as an event to come in the future by the kernel in some kqueue, epoll, ... structure; together with the other IO operations) the main loop can do other things and eventually check if something happened of those IOs and waits.

So, to rephrase it again: the program is never (allowed to get) stuck, sleeping calls are never executed. Their duty is done by the kernel (write something, wait for something to come over the network, waiting for time to elapse) or another thread or process. – The Node process checks if at least one of those duties is finished by the kernel in the only blocking call to the OS once in each event-loop-cycle. That point is reached, when everything non-blocking is done.

Clear? :-)

I don’t know Node. But where does the c.query come from?

blocks|key|2827575|text|函数c.query()有两个参数|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2827576|c.query("Fetch+Data",+"Post-Processing+of+Data")|code-block|syntax|javascript|2827577|本例中的"Fetch+Data“操作是一个DB-Query，现在这可以由Node.js通过派生一个工作线程并将执行DB-Query的任务交给它来处理。(请记住，Node.js可以在内部创建线程)。这使得函数能够立即返回，没有任何延迟|2827578|第二个参数“数据的后处理”是一个回调函数，节点框架注册此回调，并由事件循环调用。|2827579|因此，语句c.query+(paramenter1,+parameter2)将立即返回，使节点能够满足另一个请求。|offset|length|style|CODE|2827580|附言:我刚刚开始了解node，实际上我想把这篇文章作为评论写给@Philip，但因为没有足够的名誉点，所以我把它写成了答案。|2827581|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/14795145/how-the-single-threaded-non-blocking-io-model-works-in-node-js#comment29713499_14797359^0|0|0|0|0|5|X|0|V|7|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|11|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|12|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|13|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|14|8|@$M|15|N|16|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|17|8|@]|9|@$M|18|N|19|1|1A]]|A|$]]|$1|S|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

The function c.query() has two argument

<pre><code>c.query("Fetch Data", "Post-Processing of Data")
</code></pre>

The operation "Fetch Data" in this case is a DB-Query, now this may be handled by Node.js by spawning off a worker thread and giving it this task of performing the DB-Query. (Remember Node.js can create thread internally). This enables the function to return instantaneously without any delay

The second argument "Post-Processing of Data" is a callback function, the node framework registers this callback and is called by the event loop.

Thus the statement <code>c.query (paramenter1, parameter2)</code> will return instantaneously, enabling node to cater for another request.

P.S: I have just started to understand node, actually I wanted to write this as comment to <a href="https://stackoverflow.com/questions/14795145/how-the-single-threaded-non-blocking-io-model-works-in-node-js#comment29713499_14797359">@Philip</a> but since didn't have enough reputation points so wrote it as an answer.

blocks|key|200971|text|Node.js基于事件循环编程模型。事件循环在单线程中运行，重复等待事件，然后运行订阅这些事件的任何事件处理程序。例如，事件可以是|type|unstyled|depth|inlineStyleRanges|entityRanges|data|200972|200973|计时器等待已完成|unordered-list-item|200974|下一块数据已准备好写入此文件|200975|有一个新的HTTP请求正在向我们发送|200976|200977|所有这些都在单线程中运行，没有任何JavaScript代码是并行执行的。只要这些事件处理程序很小，并且等待更多的事件本身，一切都会很好地工作。这允许单个Node.js进程同时处理多个请求。|200978|(在引擎盖下有一点魔力，因为事件的起源。其中一些涉及并行运行的低级工作线程。)|200979|在这个SQL例子中，在进行数据库查询和在回调中获得结果之间有很多事情(事件)发生。在此期间，事件循环不断地向应用程序注入生命，并一次一个小事件地推进其他请求。因此，同时处理多个请求。|offset|length|style|BOLD|200980|200981|blockquote|200982|200983|📷|atomic|200984|根据："Event+loop+from+10,000ft+-+core+concept+behind+Node.js"。|200985|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/7c0ba0ca65f913b9ca38d03187e762c7.svg|imageAlt|1|LINK|MUTABLE|url|http://bytearcher.com/articles/event-loop-10-000ft/^0|0|0|0|0|0|0|0|0|A|C|0|0|0|0|0|1|0|0|3|1K|1|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1J|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1K|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|1L|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1N|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1O|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1P|8|@$Q|1Q|R|1R|S|T]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|V|3|-4|5|W|7|1T|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|10|7|1V|8|@]|9|@$Q|1W|R|1X|1|1Y]]|A|$]]|$1|11|3|12|5|6|7|1Z|8|@]|9|@$Q|20|R|21|1|22]]|A|$]]|$1|13|3|-4|5|6|7|23|8|@]|9|@]|A|$]]]|14|$15|$5|16|17|18|A|$19|1A|1B|-4]]|1C|$5|1D|17|1E|A|$1F|1G]]]]

Node.js is based on the event loop programming model. The event loop runs in single thread and repeatedly waits for events and then runs any event handlers subscribed to those events. Events can be for example

<ul>
<li>timer wait is complete</li>
<li>next chunk of data is ready to be written to this file</li>
<li>theres a fresh new HTTP request coming our way</li>
</ul>

All of this runs in single thread and no JavaScript code is ever executed in parallel. As long as these event handlers are small and wait for yet more events themselves everything works out nicely. This allows multiple request to be handled concurrently by a single Node.js process.

(There's a little bit magic under the hood as where the events originate. Some of it involve low level worker threads running in parallel.)

In this SQL case, there's a lot of things (events) happening between making the database query and getting its results in the callback. During that time the event loop keeps pumping life into the application and advancing other requests one tiny event at a time. Therefore multiple requests are being served concurrently.

<blockquote>
 <img src="https://bytearcher.com/articles/event-loop-10-000ft/event-loop.svg" alt="event loop high level view">
</blockquote>

According to: <a href="http://bytearcher.com/articles/event-loop-10-000ft/" rel="nofollow noreferrer">"Event loop from 10,000ft - core concept behind Node.js"</a>.

blocks|key|2827733|text|Node.js在幕后使用libuv。libuv+has+a+thread+pool+(默认为4)。因此，Node.js+确实使用线程来实现并发。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2827734|然而，，你的代码在一个线程上运行(即，Node.js函数的所有回调都将在同一个线程上调用，即所谓的循环-线程或事件-循环)。当人们说"Node.js在单线程上运行“时，他们实际上是在说”Node.js的回调在单线程上运行“。|2827735|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/libuv/libuv|1|http://docs.libuv.org/en/v1.x/threadpool.html^0|1O|6|C|5|0|O|H|1|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@$9|U|A|V|1|W]|$9|X|A|Y|1|Z]]|E|$]]|$1|F|3|G|5|6|7|10|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|11|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]|P|$5|K|L|M|E|$N|Q]]]]

Node.js uses <a href="https://github.com/libuv/libuv" rel="noreferrer">libuv</a> behind the scenes. libuv <a href="http://docs.libuv.org/en/v1.x/threadpool.html" rel="noreferrer">has a thread pool</a> (of size 4 by default). Therefore Node.js does use threads to achieve concurrency.

However, your code runs on a single thread (i.e., all of the callbacks of Node.js functions will be called on the same thread, the so called loop-thread or event-loop). When people say "Node.js runs on a single thread" they are really saying "the callbacks of Node.js run on a single thread".

blocks|key|3040629|text|event+loop允许Node.js执行非阻塞I/O操作--尽管JavaScript是单线程的--只要有可能，就把操作卸载到系统内核。把event+loop想象成经理。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3040630|3040631|新请求被发送到队列中，并由synchronous+event+demultiplexer监视。如您所见，每个操作处理程序也已注册。|unordered-list-item|3040632|3040633|​|3040634|📷|atomic|3040635|3040636|3040637|，然后将这些请求同步发送到线程池(工作池)以供执行。JavaScript不能执行异步I/O操作。在浏览器环境中，浏览器处理异步操作。在节点环境中，异步操作由libuv使用C%2B%2B处理。线程池的默认大小是4，但是可以在启动时通过将UV_THREADPOOL_SIZE环境变量设置为任何值(最大值是128)来更改它。线程池大小为4意味着一次可以执行4个请求，如果事件多路分解器有5个请求，4个将被传递到线程池，而第5个将处于等待状态。一旦执行了每个请求，结果就会返回给`+`event+demultiplexer.|3040638|3040639|3040640|3040641|3040642|3040643|当一组I/O操作完成时，事件多路分解器会将一组相应的事件推入事件队列。|3040644|3040645|3040646|3040647|3040648|处理程序是回调函数。现在事件循环关注着事件队列，如果有准备好的东西，它会被推送到堆栈来执行回调。记住，回调最终会在堆栈上执行。请注意，一些回调在其他回调上具有优先级，事件循环确实根据它们的优先级选择回调。|3040649|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/80631cddacf12799e9654d79916bc025.png|imageAlt|1|https://ask.qcloudimg.com/http-save/yehe-900000/ed188021cf2386e7eb14ee7f5eaaa414.png|2|https://ask.qcloudimg.com/http-save/yehe-900000/01475273b63e55f70aaa9b5a2016b936.png^0|0|A|1X|A|0|0|D|V|0|0|0|0|1|0|0|0|0|26|5|2D|3|35|I|0|0|0|0|1|1|0|0|0|0|0|0|0|1|2|0|0|0^^$0|@$1|2|3|4|5|6|7|1J|8|@$9|1K|A|1L|B|C]|$9|1M|A|1N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|1O|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|1P|8|@$9|1Q|A|1R|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1S|8|@]|D|@]|E|$]]|$1|K|3|L|5|6|7|1T|8|@]|D|@]|E|$]]|$1|M|3|N|5|O|7|1U|8|@]|D|@$9|1V|A|1W|1|1X]]|E|$]]|$1|P|3|L|5|6|7|1Y|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|1Z|8|@]|D|@]|E|$]]|$1|R|3|S|5|I|7|20|8|@$9|21|A|22|B|C]|$9|23|A|24|B|C]|$9|25|A|26|B|C]]|D|@]|E|$]]|$1|T|3|-4|5|6|7|27|8|@]|D|@]|E|$]]|$1|U|3|L|5|6|7|28|8|@]|D|@]|E|$]]|$1|V|3|N|5|O|7|29|8|@]|D|@$9|2A|A|2B|1|2C]]|E|$]]|$1|W|3|L|5|6|7|2D|8|@]|D|@]|E|$]]|$1|X|3|-4|5|6|7|2E|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|I|7|2F|8|@]|D|@]|E|$]]|$1|10|3|-4|5|6|7|2G|8|@]|D|@]|E|$]]|$1|11|3|L|5|6|7|2H|8|@]|D|@]|E|$]]|$1|12|3|N|5|O|7|2I|8|@]|D|@$9|2J|A|2K|1|2L]]|E|$]]|$1|13|3|L|5|6|7|2M|8|@]|D|@]|E|$]]|$1|14|3|15|5|6|7|2N|8|@]|D|@]|E|$]]|$1|16|3|-4|5|6|7|2O|8|@]|D|@]|E|$]]]|17|$18|$5|19|1A|1B|E|$1C|1D|1E|-4]]|1F|$5|19|1A|1B|E|$1C|1G|1E|-4]]|1H|$5|19|1A|1B|E|$1C|1I|1E|-4]]]]

The <code>event loop</code> is what allows Node.js to perform non-blocking I/O operations — despite the fact that JavaScript is single-threaded — by offloading operations to the system kernel whenever possible. Think of <code>event loop</code> as the manager.
<ul>
<li>New requests are sent into a queue and watched by the <code>synchronous event demultiplexer</code>. As you see each operations handler is also registered.</li>
</ul>
<a href="https://i.stack.imgur.com/EgloV.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/EgloV.png" alt="enter image description here" /></a>
<ul>
<li>Then those requests are sent to the thread pool (Worker Pool) synchronously to be executed. JavaScript cannot perform asynchronous I/O operations. In browser environment, browser handles the async operations. In node environment, async operations are handled by the <code>libuv</code> by using <code>C++</code>. Thread's pool default size is 4, but it can be changed at startup time by setting the <code>UV_THREADPOOL_SIZE</code> environment variable to any value (maximum is 128). thread pool size 4 means 4 requests can get executed at a time, if event demultiplexer has 5 requsts, 4 would be passed to thread pool and 5th would be waiting. Once each request gets executed, result is returned to the `event demultiplexer.</li>
</ul>
<a href="https://i.stack.imgur.com/WtWHm.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/WtWHm.png" alt="enter image description here" /></a>
<ul>
<li>When a set of I/O operations completes, the Event Demultiplexer pushes a set of corresponding events into the Event Queue.</li>
</ul>
<a href="https://i.stack.imgur.com/S8fGU.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/S8fGU.png" alt="enter image description here" /></a>
handler is the callback. Now event loop keeps an eye on the event queue, if there is something ready, it is pushed to stack to execute the callback. Remember eventually callbacks get executed on stack. Note that some callbacks has priorities on other, the event loop does pick the callbacks based on their priorities.

I'm not a Node programmer, but I'm interested in how the single threaded non blocking IO model works.
After I read the article <a href="http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/" rel="noreferrer">understanding-the-node-js-event-loop</a>, I'm really confused about it.
It gave an example for the model:

<pre><code>c.query(
 'SELECT SLEEP(20);',
 function (err, results, fields) {
 if (err) {
 throw err;
 }
 res.writeHead(200, {'Content-Type': 'text/html'});
 res.end('&lt;html&gt;&lt;head&gt;&lt;title&gt;Hello&lt;/title&gt;&lt;/head&gt;&lt;body&gt;&lt;h1&gt;Return from async DB query&lt;/h1&gt;&lt;/body&gt;&lt;/html&gt;');
 c.end();
 }
);
</code></pre>

Que: When there are two request A(comes first) and B since there is only a single thread, the server-side program will handle the request A firstly: doing SQL querying is asleep statement standing for I/O wait. And The program is stucked at the <code>I/O</code> waiting, and cannot execute the code which renders the web page behind. Will the program switch to request B during the waiting? In my opinion, because of the single thread model, there is no way to switch one request from another. But the title of the example code says that everything runs in parallel except your code. 

<blockquote>
 (P.S I'm not sure if I misunderstand the code or not since I have
 never used Node.)How Node switch A to B during the waiting? And can
 you explain the single threaded non blocking IO model of Node in a
 simple way? I would appreciate it if you could help me. :)
</blockquote>

How the single threaded non blocking IO model works in Node.js

数据结构

文件系统

数据库

服务器

Windows

Unix

我不是Node程序员，但我对单线程非阻塞IO模型是如何工作的很感兴趣。在我读了这篇文章后，我真的对它感到困惑。它给出了一个模型的例子：c.query(   'SELECT SLEEP(20);',   function (err, results, fields) {     if (err) {       thro...

问单线程非阻塞IO模型在Node.js中的工作方式
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问单线程非阻塞IO模型在Node.js中的工作方式EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问单线程非阻塞IO模型在Node.js中的工作方式
EN