Node.js® is a JavaScript runtime built on Chrome’s V8 JavaScript engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient.

Here’s a look at some of the features of Node:

Node.js® is a JavaScript Runtime built on Chrome’s V8 JavaScript engine.

When we learn something, first we have to know what it is used for. When I heard about Node, I thought nodeJS was just a framework, and when I heard about Node, I thought it was just javascript on the server side, but is that really the case? Let’s take a look at the above passage. Node.js is a javascript Runtime built on top of Chrome’s V8 engine, which is similar to the Java Runtime Environment (JRE) in my understanding. It provides the API environment, the runtime environment, so that our JS can run on the server side, and also provides the API that can operate on the file system, network and so on. This is a breakthrough that makes the front-end engineers very excited.

Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient.

The following sentence illustrates several features of Node:

  • event-driven
  • Non-blocking I/O model
  • Single threading (not mentioned, but I think it’s a feature too)

Before besides the above several features, let’s take a look, in my way of learning will often see some people say that the Node in the treatment of high concurrency, I/O intensive service is an advantage, so my question is what’s I/O intensive, search data, corresponding with the I/O intensive is CPU intensive, we can take a look at the difference between the two.

  • I/O intensive: If a program spends most of its time doing FILE I/O operations, database operations, network operations, access operations, etc., then it is an I/O intensive service.
  • CPU intensive: If a program spends all its time computing, decompressing, compressing, etc., and requires CPU to perform operations, then it is a CPU intensive service.

Ok we finish see the difference between the two, we also can understand, why the Node suited for web development, you think of when we were in web development, we are operating, read static resource, network operation, the database to add and delete, we can find web scenario I/O operation is the most time-consuming operation. Now the SPEED of CPU we execute instructions is very fast, but we carry out I/O operation is still very time-consuming. We can see that the Web is typically an I/O intensive service, so why do we say Node is perfect for web scenarios? We’ll talk about it later.

Let’s take a look at the situation of high concurrency. In the book “Simple NodeJS”, we can see Teacher Piao Ling’s opinion on the service model, which I think is very revealing. Let’s take a look:

  1. Stone Age: Synchronization in a long time ago, our servers are synchronous, service only one request at a time, such as a hotel, we hired a cook a waiter, we are now only a cook, so now we can only receive a guest order, such as a guest on ready we can continue the following a guest order, We all know that this kind of efficiency can’t work, so here’s the evolution.

  2. Bronze Age: Replication process We can replicate processes, each process serving one request, so that we can serve multiple requests, but the dream is beautiful, the ideal is full. At this time, what we can think of is to hire more cooks, which can also solve the problem of multiple guests. However, we thought for a moment, to hire so many cooks, who will pay the salaries? It is too expensive. This is also a disadvantage of copying processes. Copying processes is very expensive, and we have to copy the state in the process, and there are many same states in the process, which is wasteful. So what do we do?

  3. Silver age: multi-threaded we think from the view of the above, we also slow operation is read operation, do not need a bad cook, the cook, as a result we have fired chef, chef money please several small cook, so that we can cook for cooking, so after we received the order, will give these a few small do cook. However, we have a limited number of cooks for each waiter. We can imagine that ordering food is a very fast operation. The waiter may start to play after ordering food and wait for the cook to serve it, which causes a waste of CPU. Thread context switch and other issues can not do well to meet the needs.

  4. The golden Age: Event-driven To address high concurrency, event-driven service models like Node and Nginx are event-driven, using single threads to avoid unnecessary memory overhead and context switching. Take a look at the example above, in fact, we hire a waiter, line up to call, and then receive the next customer, do not wait for the customer’s food is ready to serve the next customer, wait for the cook to cook the food is ready to tell the waiter, and then call, the customer come to pick up OK.

Single thread

Borrow a figure of the teacher, in fact this picture we can see very clearly that our JS is single-threaded, so it is in the node, the client N request, after we received, is it will take to operate directly on the back of the thread pool to operation, using a single thread can avoid the consumption of memory, and context switching. At the same time, we use event-driven to notify the main thread as an event when subsequent thread I/O operations are complete, and then return the result. At this point, some people are just as confused as I am about nodeJS being single threaded. If NodeJS only works on a single thread, how can it accomplish highly concurrent Web services? We can say that the single thread of NodeJS is for the main process, while asynchronous operations, I/O operations and so on are scheduled by multiple threads at the bottom of the operating system. The single thread of NodeJS is only responsible for scheduling, like a waiter in a restaurant who only takes orders and cooks the food in the background. Nodejs is single-threaded, so how to use multi-core cpus today? There’s no need to worry. Node takes this into account, and NodeJS has its own module to operate on.

event-driven

So what is event-driven? In fact, when we do front-end development, we often deal with events, like Ajax, where we make a request, we listen for the event, and when it’s successful, we execute a callback. In fact, this is also a feature of Node, just like the node receives the request, node receives the request, the corresponding I/O operation to the operating system, and then listens for the event, when the I/O operation is complete, triggers the event to perform the callback to retrieve the data.

Non-blocking I/O

Blocking I/O is when a user sends a file read operation, the process blocks until all the data to be read is ready to be returned to the user. What about non-blocking I/O? When the user initiates a file read operation, the function returns immediately, does not wait, and the process continues to execute. When the read operation is complete, the main process goes back to fetch the data. How does the program know that the data to be read is ready? The simplest method is polling, which is also mentioned in Several ways in Teacher Piao Ling’s book.

Today, I learned about Nodejs briefly. If there is something wrong with nodeJS, please advise me.