NodeJS is a popular server-side JS platform in recent years. On the one hand, it benefits from its excellent performance in dealing with high concurrency in the back-end. On the other hand, powerful code and project management applications such as NPM, Grunt and Express on NodeJS platform have almost redefined the working mode and process of the front-end.
Concept:
Nodejs is a Chrome V8 based JAVASCRIPT environment that allows javascript to run on the server side. Nodejs uses an event-driven, non-blocking I/O model, making it lightweight and efficient. Nodejs package manager NPM is the largest open source ecosystem in the world.
Nodejs is a server-side JS platform.
Powerful code and project management such as NPM Grunt Express is applied to nodeJS.
NodeJS’s success is a sign of its power, but isn’t NodeJS the right platform for all situations?
The answer, of course, is no, and the Internet is full of opinions. Let’s take a look at NodeJS in principle.
Before moving on to NodeJS, let’s take a look at how traditional server-side processing platforms, notably Apache, handle concurrency.
1. Apache’s multi-threaded high concurrency mode
Apache is the most popular Web server software in the world. It is popular among server technology selectors because of its support for multi-threaded concurrency. However, Apache has gradually exposed its disadvantage in some large WEB applications: blocking.
That some students will be strange, Apache is not multi-threaded processing concurrency, why will there be blocking?
To understand this we first need to understand the concept of threads
1.1 What is a thread?
We quote the official explanation: the minimum CPU unit that a thread can run independently, concurrently in the same process, sharing the memory address space of that process (note this feature).
We can see the thread under the same process is to share the same file and memory (memory address space), so you can imagine, when different threads need to occupy the same variable, based on the principle of first come first serve, first to the thread in operation, later, the thread can only be waiting queue sequence is added to the block. So this is what causes the thread to block.
Thus, while a process can support multiple threads that appear to be executing simultaneously, they are not synchronized with each other. Multiple threads in a process share the same memory address space, which means they can access the same variables and objects, and they allocate objects from the same heap. This makes it easier for threads to share information, though, because programmers must be careful that they do not interfere with other threads in the same process. Now that we understand the pitfalls of multi-threaded parallelism, we can better understand the power of NodeJS. Because NodeJS is asynchronous single threaded!
2. Asynchronous I/O principle of NodeJS
Let’s look at some Apache database request code:
See? Just two words: asynchronous callback. The second argument to query is a callback function. The process does not wait for the result to return when it reaches db.query, but continues to execute the following statement until it enters the event loop. The event is sent to the event queue when the database execution result is returned, and the previous callback function is not called until the thread enters the event loop. The more technical term is asynchronous I/O. Just a single thread.
So why is NodeJS single threaded, but asynchronous? Let’s start with the previous image, which is the Event Queue
See, NodeJS is basically an event loop. Each piece of NodeJS logic is written in the callback function, and the callback function is executed asynchronously after the return!
At this point, you can’t help but wonder if NodeJS would fly if all its processing were asynchronous. Wrong wrong wrong! Of course not. Don’t forget, NodeJS implements this on a single-threaded basis. That’s right, single thread! One thread carries all operations! You can imagine, NodeJS in the wind, in the face of 100000 concurrent force, OK, no problem, come up to the enemy a throw to the city, on a back to town. The city is full of soldiers, and can absorb these enemies well. But if up a similar to Zhang Fei Zhao Yun such a character, the old Node heart a miserable, and Zhang Fei war 300 rounds, beat him disabled, and then thrown into the city. The next 100,000 will have to wait 300 rounds…
So what does that mean? NodeJS does not block, but blocks do not occur in the process of subsequent callbacks, but in the calculation and processing of the logic by NodeJS itself. We already know that NodeJS is incredibly powerful for distribution, loiterating events for asynchronous callbacks. But how can a thin single thread support millions of logic + concurrent operations if you run into complex logic operations when looping events? NodeJS can hand over all of its I/O, network communication and other time-consuming operations to worker Threads for callback, so it’s very fast. But the NORMAL operation of the CPU, it can only resist itself. At this point, you have a pretty good idea of NodeJS features. So the applicable scene is just around the corner ~!
3. Application scenarios of NodeJS
NodeJS is good at handling concurrency, but weak at computing and logic, so if we move all the complex logical operations to the front end (client) and NodeJS only needs to provide asynchronous I/O, we can achieve high performance handling of high concurrency. There are many cases, such as: RESTFUL API, real-time chat, client logic strong single-page APP, specific examples such as: localized online music application, localized online search application, localized online APP and so on. By the way Apache, suppressed so much, to a sweet date. Apache because of its multi-threaded high concurrency shared memory address space characteristics, that means that if the server is powerful enough, the processor is high enough core, Apache will work very well, so it is suitable for (concurrent) asynchronous processing relatively less, background computing, complex background business logic applications.