Do not miss passing through
Click the blue word to follow us
One: Nginx modular design
The highly modular design is the foundation of Nginx's architecture. The Nginx server is broken down into multiple modules. Each module is a functional module and is only responsible for its own functions. The modules strictly follow the principle of "high cohesion, low coupling".
Core module
The core module is an indispensable module for the normal operation of the Nginx server. It provides core functions such as error logging, configuration file analysis, event-driven mechanism, and process management.
Standard HTTP module
The standard HTTP module provides functions related to HTTP protocol analysis, such as: port configuration, web page encoding settings, HTTP response header settings, etc.
Optional HTTP module
The optional HTTP module is mainly used to extend standard HTTP functions, allowing Nginx to handle some special services, such as: Flash multimedia transmission, GeoIP request parsing, SSL support, etc.
Mail Service Module
The mail service module is mainly used to support Nginx mail service, including support for POP3 protocol, IMAP protocol and SMTP protocol.
Third-party module
The third-party module is to extend the Nginx server application and complete developer custom functions, such as Json support, Lua support, etc.
Two: Nginx request processing method
Nginx is a high-performance Web server that can handle a large number of concurrent requests at the same time. It combines multi-process mechanism and asynchronous mechanism. The asynchronous mechanism uses asynchronous non-blocking mode. Next, I will introduce Nginx's multi-threading mechanism and asynchronous non-blocking mechanism.
multi-Progress
Whenever the server receives a client. There is a server master process (master process) that generates a worker process to establish a connection with the client to interact, until the connection is disconnected, the child process is ended.
The advantage of using processes is that each process is independent of each other and does not need to be locked, which reduces the impact of using locks on performance, while reducing the complexity of programming and reducing development costs.
Secondly, the use of independent processes can prevent the processes from affecting each other. If a process exits abnormally, other processes work normally, and the master process will quickly start a new worker process to ensure that the service department is interrupted and the risk is reduced to lowest.
The disadvantage is that the operating system generates a child process that needs to perform operations such as memory copy, which will cause a certain amount of overhead in resources and time; when there are a large number of requests, the system performance will decrease.
Asynchronous non-blocking
Each worker process uses asynchronous non-blocking mode and can handle multiple client requests. When a worker process receives the client's request, it calls IO for processing. If the result cannot be obtained immediately, it will process other requests (that is, non-blocking); and the client does not need to wait for a response during this period and can process it. Other things (ie asynchronous); when the IO returns, the worker process will be notified; the process is notified and temporarily suspends the current transaction to respond to client requests.
Three: Nginx event-driven model
In Nginx's asynchronous non-blocking mechanism, the worker process processes other requests after calling IO. When the IO call returns, the worker process will be notified. For such system calls, the event-driven model of the Nginx server is mainly used to implement.
As shown in the figure above, Nginx's event-driven model consists of three basic units: event collector, event sender and event processor. Among them, the event collector is responsible for collecting various IO requests from the worker process, the event transmitter is responsible for sending IO events to the event processor, and the event processor is responsible for responding to various events.
The event sender puts each request into a list of pending events, and uses non-blocking I/O to call the "event handler" to process the request. The processing method is called "multi-channel IO multiplexing method", and the common ones include the following three: select model, poll model, and epoll model.
I specially sorted out the above technologies. There are many technologies that can not be explained clearly in a few sentences, so I just found some friends to record some videos. The answers to many questions are actually very simple, but the thinking and logic behind them are not simple. Knowing it is also knowing why.
Four: Nginx design architecture
The Nginx server uses the master/worker multi-process model. The process of multi-thread startup and execution is as follows: After the main program Master process is started, it receives and processes external signals through a for loop; the main process generates child processes through the fork() function, and each child process executes a for loop to realize Nginx server pairing Event reception and processing.
It is generally recommended that the number of worker processes be the same as the number of cpu cores, so that there are no large number of child process generation and management tasks, and the overhead of competing for CPU resources and process switching between processes is avoided. In addition, in order to make better use of multi-core features, Nginx provides a binding option for cpu affinity. We can bind a certain process to a certain core so that the cache will not be invalidated due to process switching.
For each request, there is one and only one worker process to process it. First of all, each worker process forks from the master process. In the master process, the socket (listenfd) that needs to be listened to is established first, and then forks out multiple worker processes. The listenfd of all worker processes will become readable when a new connection arrives. To ensure that only one process handles the connection, all worker processes grab the accept_mutex before registering the listenfd read event. The process that grabs the mutex lock registers the listenfd read event. Call accept in the read event to accept the connection.
When a worker process accepts the connection, it starts to read the request, parse the request, process the request, generate data, and then return it to the client, and finally disconnect, such a complete request is like this. We can see that a request is completely processed by the worker process and only processed in one worker process.
During the operation of the Nginx server, the main process and the worker process need process interaction. The interaction depends on the pipeline implemented by Socket.
Master-Worker interaction
This pipeline is different from ordinary pipelines. It is a one-way pipeline from the main process to the work process, including instructions from the main process to the work process, work process ID, etc.; at the same time, the main process communicates with the outside world through signals; each child process has The ability to receive signals and handle corresponding events.
worker-worker 交互
This interaction is basically the same as the Master-Worker interaction, but it will pass through the main process. The worker processes are isolated from each other, so when the worker process W1 needs to send an instruction to the worker process W2, first find the process ID of W2, and then write the correct instruction into the channel pointing to W2. W2 receives the signal and takes corresponding measures.
Five: Summary
Through this article, we have an overall understanding of the overall architecture of the Nginx server. Including its modular design, multi-process and asynchronous non-blocking request processing methods, event-driven model, etc. Through these theoretical knowledge, it will be very helpful for us to learn the source code of Nginx in the future; it is also recommended that everyone look at the source code of Nginx to better understand the design ideas of Nginx.
Previous wonderful recommendations
Summary of Tencent, Ali, Didi Backstage Interview Questions-(including answers)
Interview: The most comprehensive multi-threaded interview questions in history!
The latest Alibaba pushes Java back-end interview questions
JVM is difficult to learn? That's because you didn't read this article seriously
—END—
Follow the author's WeChat public account—"JAVA Rotten Pigskin"
Learn more about java back-end architecture knowledge and the latest interview book
Everything you order is pretty, I take it seriously
After reading this article, remember to give the author a thumbs up + watching it~~~ Everyone's support is the motivation for the author to continue publishing articles.