Nginx 如何优雅下线服务器 (nginx 下线服务器)
Introduction
Nginx is one of the most popular web servers, and it’s widely used by software developers, system administrators, and businesses worldwide. Nginx allows users to quickly and efficiently serve static and dynamic content, balance traffic between multiple servers, and implement security features to protect agnst potential attacks. However, one less talked about feature of Nginx is how it gracefully handles server shutdowns or reboots.
In this article, we will explore how Nginx handles server shutdowns and reboots and offer some best practices for gracefully shutting down your Nginx server. We will discuss different strategies for handling server shutdowns based on the specific situation.
Why Graceful Shutdown is Important?
Graceful shutdown is important for mntning the avlability of a high-performing web server. Whenever you take down or restart a server, you need to ensure that the downtime is as minimal as possible. This is especially important when you run a web application on your server. An abrupt shutdown will cause the server to stop accepting new requests immediately, potentially causing data loss and other problems. On the other hand, gracefully shutting down the server will give it time to complete any outstanding requests and ensure all data is written to the disk before the shutdown occurs.
How Nginx Handles Server Shutdowns?
When you need to take down an Nginx server, it’s essential to understand how the server handles server shutdowns. Nginx listens to the master process for signals such as SIGTERM or SIGQUIT that are sent during a shutdown. When the master process receives these signals, it starts a process of gracefully stopping all child worker processes.
Once all of the worker processes complete their current requests and become idle, they begin to close one by one. The master process will then terminate when all of the child processes have stopped completely. By default, the shutdown period for Nginx is set to ten seconds.
Nginx gracefully handles shutdowns by closing all connections before shutting down. This means that clients will not receive half-open connections, leading to retranissions and wasted bandwidth. Nginx will also write any data that needs to be persisted to the disk, ensuring there is no data loss due to a server crash.
How to Gracefully Shutdown Nginx?
Here are some best practices for gracefully shutting down Nginx:
1. Using Systemd
One of the most strghtforward approaches to gracefully shutting down Nginx is using the systemd init system. Systemd was introduced in CentOS 7, Fedora 15, and Arch Linux and acts as a central management system for running and controlling services.
To gracefully shut down Nginx using systemd, you run the following command:
sudo systemctl stop nginx
This command sends the SIGTERM signal to the master process and starts the graceful shutdown process for all worker processes.
2. Using Nginx Control Script
If your operating system doesn’t use systemd, you can use the Nginx control script to gracefully shut down Nginx. The script is typically found in the /etc/init.d/ directory, and it controls Nginx as a service.
To gracefully shut down Nginx using the control script, you run the following command:
sudo /etc/init.d/nginx stop
This command sends the SIGTERM signal to the master process and starts the graceful shutdown process for all worker processes.
3. Sending a Manual Signal
If you need more control over the shutdown process, you can send a manual signal to the master process. This approach is useful if you need to control how long a client connection remns open before the server closes it.
To gracefully shut down Nginx manually, you run the following command to find the PID of the Nginx master process:
ps -aux | grep nginx
Once you have the PID, you can send a SIGQUIT or SIGTERM signal to the master process using the kill command:
sudo kill -QUIT # Sends the SIGQUIT signal
or
sudo kill -TERM # Sends the SIGTERM signal
Conclusion
相关问题拓展阅读：
初识Nginx配置文件以及基本命令
配置文件名为 nginx.conf ，Linux放在目录： /usr/local/nginx/conf 、 /etc/nginx , 或 /usr/local/etc/nginx 中；Windows放在 安装目录\conf 中。 依据实际安装情况决定
nginx由配置闭码衫文件中指定的指令控制模块组成。 指令分为
简单指令
和
块指令
：
简单指令 由空格分隔的名称和参数组成，并以分号 ; 结尾；
块指令 具有与简单指令相同的结构，但是是以大括号 { 和 } 包围的一组附加指令。 如果块指令在大括号内部有其他指令，则称为上下文(例如： events ， http ， server 和 location )；
配置文件中放置在任何上下文之外的伪指令都被认为是主上下文。 events 和 http 指令驻留在主上下文中， server 在 http 中的，而 location 在 server 块中。一个配置文件一个 http ，一个及以上个 server ，一个 server 运行一个工作进程并代表一个虚拟服务器；
# 号所在的一行被视为注释；
几个顶级指令将适用于不同流量类型的指令组合在一起：
对于大多数指令，在子模告上下文中定义的上下文将继承父级中包含的伪指令的值，要覆盖从父进程继承的值，子上下文中需要包含该指令（即子上下文要显式声明）。
打开配置文件(如 /usr/local/nginx/conf/nginx.conf )，默认的配置文件已经包含了服务器块的几个示例，大部分是注释掉的。 现在注释掉所有这样的块，并启动一个新的服务器块：轿腔
每个 server 上下文都可以指定要监听的端口、server_name，当nginx决定哪个服务器处理请求后，它会根据服务器块内部定义的location指令的参数测试请求头中指定的URI， 比如如下配置，系统中创建 /data 目录及其子目录 /www ：
之一个 location 块指定与请求中的URI比较 / 前缀。 对于匹配请求，URI将被添加到 root 指令中指定的路径(即 /data/www )，形成本地文件系统中的请求文件路径。 如果有几个匹配的location块，nginx将选择具有最长前缀来匹配location块。 上面之一个 location 块提供最短的前缀长度为1，因此只有当所有其他location块不能提供匹配时，才会使用该块。第二个 location ,将是以 /images/ 的请求来匹配，位置 / 也匹配这样的请求，但具有较短前缀，也就是 /images/ 比 / 长。
这已经是一个在标准端口 80 上侦听并且可以在本地机器问的服务器 的工作配置，
端口 80 和 server_name localhost 可以省略，它们为默认值
。 响应以/images/开头的URI的请求，服务器将从 /data/images 目录发送文件。 例如，响应 请求，nginx将发送服务上的 /data/images/logo.png 文件。 如果文件不存在，nginx将发送一个指示 404 错误的响应。 不以 /images/ 开头的URI的请求将映射到 /data/www 目录。 例如，响应 请求时，nginx将发送 /data/www/about/example.html 文件。
反向代理应该是Nginx做的最多的一件事了，反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。简单来说就是真实的服务器不能直接被外部网络访问，所以需要一台代理服务器，而代理服务器能被外部网络访问的同时又跟真实服务器在同一个网络环境，当然也可能是同一台服务器，端口不同而已。
通过向nginx配置文件添加一个server块来定义代理服务器，其中包含以下内容：
这将是一个监听端口 8080 的简单服务器，并将所有请求映射到本地文件系统上的 /data/up1 目录。 请注意，root指令位于server块上下文中，当选择用于服务请求的 location 块不包含自己的 root 指令时，将使用此root指令。创建 /data/up1 目录然后可以将一个静态网页比如 index.html 文件放入其中，然后访问 即可访问该文件。
目前为止，还是配置的静态资源访问，并不是代理服务器，然后增加或修改现有 location 上下文，改为如下：
当用户访问 时，会返回 服务器的的资源。
location 上下文后面的参数，可以是正则表达式，如果是正则表达式，前面要加 ~ ，比如：
以上配置表示，nginx接收到所有以.gif，.jpg或.png结尾的URI，相应的请求将映射到/data/images目录。当nginx选择一个location块来提供请求时，它首先检查指定前缀的location指令，记住具有最长前缀的location，然后检查正则表达式。 如果与正则表达式匹配，nginx会选择此location，否则选择之前记住的那一个。
要找到更符合URI的位置，NGINX首先将URI与前缀字符串的位置进行比较。然后用正则表达式搜索位置。除非使用^~修饰符对正则表达式给予更高的优先级。在前缀字符串中，NGINX选择更具体的字符串(也就是最长和最完整的字符串)。 下面给出了选择处理请求的位置的确切逻辑：
测试所有URI的前缀字符串。 = (等号)修饰符定义了URI和前缀字符串完全匹配。如果找到完全匹配，则搜索停止。如果 ^~ (插入符号)修饰符预先添加最长匹配前缀字符串，则不会检查正则表达式。存储最长匹配的前缀字符串。根据正则表达式测试URI。断开之一个匹配的正则表达式并使用相应的位置。如果没有正则表达式匹配，则使用与存储的前缀字符串相对应的位置。
= 修饰符的典型用例是 / (正斜杠)的请求。 如果请求/是频繁的，则指定 = / 作为location指令的参数加速处理，因为搜索匹配在之一次比较之后停止。
要启动nginx，请运行可执行文件。 当nginx启动后，可以通过使用-s参数调用可执行文件来控制它。 使用以下语法：
信号(signal)的值可能是以下之一：
当主进程收到要重新加载配置的信号，它将检查新配置文件的语法有效性，并尝试应用其中提供的配置。 如果这是成功的，主进程将启动新的工作进程，并向旧的工作进程发送消息，请求它们关闭。 否则，主进程回滚更改，并继续使用旧配置。 老工作进程，接收关闭命令，停止接受新连接，并继续维护当前请求，直到所有这些请求得到维护。 之后，旧的工作进程退出。
两者在 location 中，指定一个路径，其中使用 alias 做如下配置：
若按照上述配置的话，则访问/img/目录里面的文件时，ningx会自动去/var/www/image/目录找文件
若按照这种配置的话，则访问/img/目录下的文件时，nginx会去/var/www/image/img/目录下找文件。alias是一个目录别名的定义，root则是最上层目录的定义，指的是 /var/www/image/img/ 。还有一个重要的区别是alias后面必须要 / 结束，否则会找不到文件，而root则可有可无。
另外对于index，含义如下
这样，当用户请求 / 地址时，Nginx 就会自动在 root 配置指令指定的文件系统目录下依次寻找 index.htm 和 index.html 这两个文件。如果 index.htm 文件存在，则直接发起“内部跳转”到 /index.htm 这个新的地址；而如果 index.htm 文件不存在，则继续检查 index.html 是否存在。如果存在，同样发起“内部跳转”到 /index.html ；如果 index.html 文件仍然不存在，则放弃处理权给 content 阶段的下一个模块。
参考地址1
参考地址2:B站
使用nginx反向代理，每秒钟都有数据吞吐，15分钟后，网页被断开，怎么办？
proxy_pass是代理指令
也就是说，浏览器请求发到Nginx后，Nginx把请求转发到目的服务器，然后在把目的服务器返回的内容再传回给浏扮耐览器
整个过程中浏览器与B都是不进行任何直接通讯的，所有大缺做通讯都是通过Nginx服务器间接通信，B可以处滚衡于与Nginx同一内网下，B都可以链接不了外网，只由Nginx（DMZ区）将请求发给B，B将结果再给Nginx
nginx 下线服务器的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于nginx 下线服务器,Nginx 如何优雅下线服务器,初识Nginx配置文件以及基本命令,使用nginx反向代理，每秒钟都有数据吞吐，15分钟后，网页被断开，怎么办？的信息别忘了在本站进行查找喔。
