Get technical dry goods and industry information for the first time!
☞ Free CSDN information to help service | Free group membership ☜
The reason why Nginx is famous is related to its internal precision design. Nginx adopts a highly modular design idea, and there are two main types of internal processes, the master process and the worker process. Among them, there is only one master process, and there can be multiple worker processes.
Among them, the master process is used to manage, monitor and control the main process of the worker process under it. This process is initiated by root. The reason is that the http service needs to enable port 80, and only root has the authority to enable port 80.
The worker process is the real working process and the process that really handles the request. The worker processes are all child processes of the master process. The worker process runs as an ordinary user, which can greatly increase the security of the program. Even if a process is hijacked, there will be no administrator privileges.
In the Worker process, the native functions are only the most basic web services. But because nginx is a highly modular application, there are one or more modules in each worker process. However, it should be noted that the loaded modules are not all loaded at once. Only when the process really needs the module will it be loaded by the worker process.
Modular thinking and object-oriented thinking are important ideas that promote the entire development of modern times.
Due to the highly modular mechanism of nginx, it has also achieved its characteristics of high efficiency and light weight.
As a reverse proxy and load balancing server, nginx must have the characteristics of high availability, so nginx supports hot deployment.
The hot deployment of nginx is closely related to its concurrency model. To put it bluntly, it is because of the master process. When ngnix is notified to reread the configuration file, the master process will judge the syntax error. If there is a syntax error, an error is returned and no loading is performed; if the configuration file has no syntax error, ngnix will not adjust the new configuration to all workers. Instead, do not change the worker that has established a connection, wait for the worker to end all requests, kill the worker that was originally started under the old configuration, and then create a new worker with the new configuration. The nginx -s reload I mentioned in yesterday's article "Nginx hot configuration, configuration effective immediately command nginx -s reload detailed explanation" is actually a hot deployment.
Nginx as a server, it is impossible for us to stop the service for configuration upgrades and software version upgrades. Therefore, the hot deployment of Nginx greatly facilitates our upgrade and maintenance of server software.
Let's look at an upgrade example of smoothly upgrading Nginx 1.11.10 from 1.10.3 to Nginx version.
First, we download the source code of the two versions of Nginx on the official website respectively, and then use make to compile, and then only install the 1.10.3 version of Nginx, the command is: make install. Version 1.11.10 can only be compiled.
Then we start Nginx, after starting, the effect is similar to the above picture.
Then we are using the cp command to back up the running nginx binary file of version 1.10.3.
Then, we copy and replace the compiled Nginx binary file of version 1.11.10 into the nginx directory.
Enter the above command, and then enter y. Then we use the kill -USR2 command.
Then check the process information.
Two master processes are found, and one of the old master processes is not listening on port 80. At this time, the old process is not accepting new requests, and the new requests are transferred to the new process.
At this time, we can send a signal to the old process, please shut down the old worker process gracefully.
Then, we check the process information again.
We found that the old master process is still there, and the worker process has exited. At this time, all new requests have been transitioned to the new worker process. The old master process does not monitor and process requests, it is only left for the convenience of version rollback.
Of course, if you feel that this display is unsightly and misleading, you can delete the old master process after the upgrade is complete. If you need to roll back, use the reload command to reload the old master process.