"Turn" nginx in-depth detailed multi-process network model

"Turn from" http://blog.chinaunix.net/uid-22312037-id-3974068.html

First, the process model
Nginx for the vast number of code farmers love, in addition to its high performance, but also its elegant system architecture. Compared with memcached's classic multithreaded model, Nginx is a classic multi-process model. Nginx runs in the background in a daemon manner, and the background process contains a master process and multiple worker processes, such as:

Figure 1 Nginx Multi-process model

The master process is primarily used to manage worker processes, including the following 4 main features:
(1) Receiving signals from the outside world.
(2) Send a signal to each worker process.
(3) Monitor the running state of the woker process.
(4) When the Woker process exits (in exceptional cases), the new Woker process is restarted automatically.
Woker process is mainly used to deal with network events, each woker process is peer and independent, they are equally competitive from the client's request, a request can only be processed in a woker process, the number of Woker process is generally set to the number of machine CPU cores.

Second,Process Control
The control of Nginx process is mainly through the master process, there are two main ways:
(1) Send signal manually
As you can see from Figure 1, master receives the signal to manage the woker process, so you can send a signal through kill to the master process, such as the Kill-hup PID to notify Nginx to restart gracefully. The so-called quiet restart is uninterrupted service: After the master process receives the signal, it reloads the configuration, then starts the new process to receive the new request, and sends a signal to all the old processes that no longer receives the new request and exits automatically after all outstanding requests have been processed.
(2) automatic signal transmission
You can start a new process with command-line arguments to send a signal to the master process, such as./nginx-s Reload to start a new nginx process, The new process will send a signal to the master process after parsing to the reload parameter (the new process will automatically complete the action in the manual Send signal). Of course it can./nginx-s stop to stop Nginx.

third, network events
Nginx handles network events in an asynchronous, non-blocking manner, similar to Libevent, as follows:

Figure 2 Nginx Network events

The master process first builds the socket that needs to be listen, and then fork out multiple woker processes so that each work process can accept the socket. When a client connection arrives, all the accept work processes are notified, but only one process can accept the success and the others accept the failure. Nginx provides a shared lock Accept_mutex to ensure that only one work process is connected to the accept at the same time, thus solving the problem of surprise clusters. When a worker process accept the connection, it begins to read the request, parses the request, processes the request, generates the data, returns it to the client, and finally disconnects, so that a completed request is ended.

"Turn" nginx in-depth detailed multi-process network model