您现在的位置是：首页 > 后台技术 > LinuxLinux
linux安装nginx(图文)
第十三双眼睛2021-10-12【Linux】人已围观
简介nginx学习记录
安装nginx，有两种方法，第一，通过操作系统的包管理器进行安装，第二，在官方网站下载源码，自己编译安装，我这里选择下载软件包，自己编译安装的方式
首先在https://nginx.org/en/download.html 下载所需的软件包
然后将它上传到服务器上。在这里我特意建立一个文件夹，用来存放自己安装的各种软件 /software，就将安装包上传到这里。
然后执行如下命令 tar -xf nginx-1.14.2.tar.gz
解压完成后，我们看到了如下目录：
执行如下命令，我们可以知道在安装nginx时，我们可以使用的配置项
./configure --help
接下来，我们需要安装一下依赖的包，执行如下的命令即可
yum install -y gcc-c++
yum install -y pcre pcre-devel
yum install -y zlib zlib-devel
yum -y install pcre pcre-devel zlib zlib-devel openssl openssl-devel
然后，我们建立一个专门安装我们自己的软件的一个目录/apps
执行如下命令指定nginx的安装目录
./configure --prefix=/apps/nginx
执行如下命令进行编译
make
执行如下命令进行安装
make install
到了这里，我们的nginx就已经安装完毕了，现在我们启动一下，
执行如下命令进入启动脚本的所在位置
cd /apps/nginx/sbin
可以看到如下文件
nginx nginx.old
执行如下命令，就可以启动nginx
./nginx 启动命令
上面的默认启动，也可以加载指定的配置文件进行启动，命令如下：
./nginx -c nginx.conf
./nginx nginx.conf -t 可以测试配置文件是否正确，这里只是测试，不管配置文件是否正确，都不会启动服务器
./nginx -s stop 停止命令
./nginx -s quit 与stop信号的作用类似，quit信号作用也是用于停止nginx服务，quit信号和stop信号的区别在于，nignx进程收到stop信号以后会立即停止服务，而收到quit信号后，不会再接收新的请求，但是会先处理完已经接受的链接请求，处理完这些请求之后再停止服务，这种停止方式被称之为”优雅的停止”。
上面的直接关闭，下面的命令是优雅的关闭
kill -QUIT 主进程号 当这样停止的时候，不会接受新的请求，但是之前的请求会响应
kill -TERM 主进程号 当这样停止的时候，之前的请求也会终止响应
kill -9 nginx 强制结束进程，当没有办法用上述两个命令停止的时候，再用这个。
./nginx -s reload 重启命令 reload信号的作用就是在不停止服务的情况下重载配置文件，比如，nginx正在正常的提供服务，此时，管理员修改了nginx.conf文件中的配置指令，管理员希望新的配置立刻生效，但是又不希望重启nginx服务，此时就可以使用”nginx -s reload”命令重载配置文件，以便在不重启nginx的情况下载入新的配置，同时避免了因重启而造成的服务中断
./nginx -s reopen 利用reopen信号可以使nignx进程重新打开日志文件，以便实现日志分割的效果
./nginx -v 显示版本号
./nginx -V 会显示详细信息
在浏览器中输入ip
能看到下图，就说明已经成功启动了
上面，我们已经成功的安装了nginx服务器，我们知道，有两种方式安装nginx，分别是yum安装方式和编译源码安装方式。
但是通过这两种方式安装的nginx，目录结构不一样。
我们先看编译安装的方式
conf文件夹中存放着配置文件
html文件夹用来存放网页
log文件夹是用来存放日志
sbin文件夹中存放着启动用的命令文件
而通过yum安装方式安装的nginx，对应的启动文件已经拷贝到了usr/bin目录中，而且此目录已经加入到了环境变量中，所以，我们可以在任意位置执行nginx命令来启动
nginx服务器
编译安装后，配置文件放置在了安装目录的conf文件夹中
但是yum安装后，配置文件则放置在了/etc/nginx文件夹中
通过编译安装的方式安装nginx以后，默认的”server块”直接配置到了nginx.conf文件中，而通过官方yum源安装nginx后，默认的”server块”会配置在”/etc/nginx/conf.d/default.conf”文件中，换句话说就是，如果你通过官方yum源安装了nginx，那么你在/etc/nginx/nginx.conf文件中无法找到默认提供的server块，只能在/etc/nginx/conf.d/default.conf文件中找到默认的server块，这是为什么呢？其实，我们从/etc/nginx/nginx.conf文件中就能找到答案，打开/etc/nginx/nginx.conf文件，查看默认的http块的配置，你会在http块中发现如下配置指令 include /etc/nginx/conf.d/*.conf;
通过前文我们已经知道，在nginx中，我们可以通过location块与root指令结合的方式，将”url”与”服务器路径”建立起对应关系，location块负责匹配url，root指令负责将匹配到的url与服务器中某个具体目录对应起来，其实，除了root指令，还有另一个指令也能实现类似的功能，它就是alias指令，root指令和alias指令都能将url和服务器路径进行对应，但是，它们之间又存在一些区别：
root指令会将location块的”url路径”带入到”root指令路径”中，将带入后的路径作为”最终路径”，使用”最终路径”与url建立对应关系
alias指令则直接将location块的”url路径”与”alias指令路径”建立对应关系。
访问日志
当我们访问nginx服务时，nginx会记录日志，nginx日志分两种，一种是访问日志，一种是错误日志，访问日志记录在”access.log”文件中，错误日志记录在”error.log”文件中，这篇文章我们只关注访问日志的使用，也就是”access.log”。
如果你安装nginx的方式为编译安装，访问日志会放在安装路径的logs文件夹中，如果是通过yum安装的方式安装nginx，访问日志的路径就是/var/log/nginx/access.log
我们也可以自定义访问日志的位置，通过一条指令即可：
access_log /opt/access.log;
通过指令log_format 可以控制访问日志都记录哪些内容，以下的这些变量分别表示，如下内容
$remote_addr变量：记录了客户端的IP地址（普通情况下）。
$remote_user变量：当nginx开启了用户认证功能后，此变量记录了客户端使用了哪个用户进行了认证。
$time_local变量：记录了当前日志条目的时间。
$request变量：记录了当前http请求的方法、url和http协议版本。
$status变量：记录了当前http请求的响应状态，即响应的状态码，比如200、404等响应码，都记录在此变量中。
$body_bytes_sent变量：记录了nginx响应客户端请求时，发送到客户端的字节数，不包含响应头的大小。
$http_referer变量：记录了当前请求是从哪个页面过来的，比如你点了A页面中的超链接才产生了这个请求，那么此变量中就记录了A页面的url。
$http_user_agent变量：记录了客户端的软件信息，比如，浏览器的名称和版本号。
这些变量并非一定会有对应的值，如果变量没有对应的值，那么日志中会使用 “-” 进行占位。
log_format 指令只能配置在http块中
access_log 指令可以配置在如下地方：
http, server, location, if in location, limit_except
进程
当你启动nginx以后，使用ps命令查看nginx进程，会发现nginx进程不只有一个，默认情况下，你会看到至少两个nginx进程
当我启动nginx以后，有两个nginx进程，一个master进程，一个worker进程，其中master进程用来管理worker进程，worker进程才是真正来干活的进程。
除了管理worker进程，还会来读取配置文件，判断配置文件语法。在nginx中，master进程正常来说只能有一个，而worker进程可以有多个。具体数量可以用指令
worker_processes 来配置，worker_processes指令只能在main区域中使用
通常情况下，worker_processes的值通常不会大于服务器中cpu的核心数量，换句话说就是，worker进程的数量通常与服务器有多少cpu核心有关，比如，nginx所在主机拥有4核cpu，那么worker_processes的值通常不会大于4，这样做的原因是为了尽量让每个worker进程都有一个cpu可以使用，尽量避免了多个worker进程抢占同一个cpu的情况，当然，你想要的在4核的机器上将worker_processes的值设置为8，也是完全可行的。除了某个具体的数字，我们也可以将worker_processes的值设置为”auto”，如下：worker_processes auto
当worker_processes的值为auto时，nginx会自动检测当前主机的cpu核心数量，并启动对应数量的worker进程
同时，为了避免cpu在切换进程时产生性能损耗，我们也可以将worker进程与cpu核心进行”绑定”，当worker进程与cpu核心绑定以后，worker进程可以更好的专注的使用某个cpu核心上的缓存，从而减少因为cpu切换不同worker进程而带来的缓存失效，如果想要让worker进程与某个cpu核心绑定，则需要借助另外一个配置指令，它就是”worker_cpu_affinity”指令
要想知道该指令如何使用，就要了解一个概念，那就是cpu掩码，比如，当前机器上一共有4个cpu核心，那么我们就用4个0表示这4个核，也就是说，我们可以使用如下字符表示这4个核：
0001表示第一个核，0010表示第二个核，0100表示第三个核，1000表示第四个核
假如当前主机一共有两个cpu核心，我想要启动两个worker进程，并且将这两个worker进程分别绑定到两个核心上，那么我就可以通过如下两条配置指令完成上述设置
worker_processes 2;
worker_cpu_affinity 01 10；
worker_cpu_affinity 也只能在 main区域使用
编译安装nginx后，默认情况下worker进程是以”nobody”用户的身份运行的，如果我们想要指定worker进程的运行用户，则可以使用”user”指令，比如，指定worker进程以nginx用户的身份运行，配置如下：
user nginx
user指令也是只能在main区域使用
日志切割
nginx会将访问日志写入到access.log日志文件中，天长日久，access.log文件就会越来越大，如果访问量巨大，并不用多长时间，access.log文件的体积就会变得非常大，对于我们的管理工作来说，这是不利的，首先，当我们打开一个非常大的日志文件时，就会比较慢，而且，从一个非常大的日志中找到某个时间段的日志也会比较慢，所以，我们最好将日志按天分割开，比如，每天一个文件
通过编译的方式安装nginx后，默认没有日志分割的功能
通过yum源的方式安装nginx后，默认会对nginx日志进行切割
为nginx实现日志切割的方法通常有两种，第一种方法是编写脚本实现日志切割，第二种方法是使用系统自带的日志滚动软件”logrotate”完成日志切割，但是无论选择哪种方法，其实都是殊途同归，在本质上都是一样的
我们借助reopen信号，就能为nginx实现日志滚动的效果
其实，除了能够使用”nginx -s”命令发送信号，我们也可以借助”kill”命令向nginx进程发送信号，你肯定经常使用kill命令，当你想要强制停掉进程的时候，会使用”kill -9 pid”向进程发送”SIGKILL”信号，除了”-9″代表的”SIGKILL”信号，我们也可以借助kill命令向进程发送一些别的信号。我们需要借助kill命令，向nginx主进程发送一个名为”USR1″的信号，在程序中，”USR1″信号的作用是可以自定义的，也就是说，当程序捕捉到”USR1″信号的时候进行什么操作，取决于编程时的设定，不同的程序采取的操作可能不同，而在nginx中，”USR1″信号可以帮助我们重新打开日志，换句话说就是，”nginx -s reopen”命令的作用和”kill -USR1 NginxPid”的作用是一样的，”NginxPid”指的是nginx的master进程的进程号，所以，在编写nginx日志滚动脚本时，你可以使用这两个命令中的任何一个，以便nginx可以重新打开日志文件
如果你使用了yum源的方式安装了nginx，你会发现在安装完nginx后默认就有日志滚动的功能，这是因为通过yum源安装nginx后，默认会安装一个日志滚动的配置文件，这个配置文件就是”/etc/logrotate.d/nginx”，可以看出，这是一个logrotate配置文件，也就是说，nginx借助这个配置文件，使用logrotate完成了日志分割的操作，通常情况下，centos系统默认自带logrotate，logrotate是一个日志管理工具，此处讨论的重点也不是logrotate，重点是nginx怎样通过logrotate完成日志滚动的，所以，打开”/etc/logrotate.d/nginx”配置文件，你会从中找到如下一行命令 kill -USR1 `cat /var/run/nginx.pid`
信号
我们已经知道，当我们需要让nginx重新打开日志文件时，需要使用kill命令向nginx的master进程发送USR1信号，或者执行”nginx -s reopen”命令，它们的效果是完全一样的，那么你可能会问，”nginx -s”命令除了能够使用reopen，不是还能够使用reload、stop和quit么，那么reload、stop、quit有没有完全等效的信号呢？还真有，这些信号的对应关系如下：
reopen对应USR1信号
reload对应HUP信号
stop对应TERM信号或者INT信号
quit对应QUIT信号
通过上述对应关系我们可以推断出，”nginx -s reload”命令与”kill -HUP NginxMasterPid”命令的作用是一样的
之前说过，master进程是负责管理worker进程的，其实，当我们向master进程发送信号时，master进程就会根据捕捉到的信号来管理worker进程，那么，我们都能向master进程发送哪些信号呢？我们能向master进程发送如下信号：
TERM或者INT：表示立即停止nginx
QUIT：表示优雅的停止nginx
HUP：重载配置文件
USR1：重新打开日志文件
USR2：热升级nginx程序
WINCH：优雅的关闭相应的worker进程
其实，不仅master进程可以直接接收信号，work进程也可以直接接收信号，但是通常情况下，我们不应该手动的向worker进程直接发送信号，而是应该通过master进程来管理他们，虽然我们不应该向work进程发送信号，但是此处还是列出worker进程可以接收到的信号，以便了解它们，worker进程可以接收的信号如下：
TERM信号或INT信号
QUIT信号
USR1信号
WINCH信号
如果因为某些原因，worker进程意外终止了，master进程会创建一个新的worker进程，以保证有对应的worker进程可以使用，当子进程worker进程终止时，会向master父进程发送CHLD信号，当master进程收到CHLD信号以后，就会知道对应的worker进程退出了，此时，master进程会创建一个新的worker进程
热升级
所谓的热升级也叫做热部署，或者平滑升级，也就是说，在不停止nginx服务的情况下，完成nginx的升级工作。
这里有一个注意点，就是使用这种方法有一个前提，前提就是你在启动nginx时使用的是nginx二进制文件的绝对路径，而不是直接在命令行中输入”nginx”的方式启动的nginx服务
最重要的一步，备份
1、下载新版本的nginx，根据老版本的编译选项，对新版本完成编译的步骤，只对新版本进行编译操作，不执行安装操作，换句话说就是，只执行make命令，不执行make install命令，完成编译操作后，即可获取到我们需要的新版本的二进制文件，之后，我们需要根据实际情况判断哪些文件需要被替换
2、确定已经备份老版本的nginx二进制文件，以防万一，用编译好的新版本的nginx二进制文件替换老版本的nginx二进制文件，此时老版本的nginx仍然在内存中正常运行，所以不用担心，我们替换的只是硬盘中的二进制文件，做好备份即可
3、对nginx的master进程（正在运行的老版本的master进程）发送USR2信号，老版本的master进程收到信号后，会通过新版本的二进制文件启动新版本的master进程，新版本的master进程会启动新版本的worker进程，此时新老版本的nginx进程同时存在
4、向老版本的master进程发送WINCH信号，以便先优雅的停止老版本的worker进程，新的请求会被新版本的worker进程处理，此时老的master进程仍然存在，留下老的master进程是为了以防万一，以便随时回滚，此时老版本的master进程、新版本的master进程和新版本的worker进程同时存在，升级过程暂且完毕
5、如果升级后万一出现问题，则可以随时进行回滚，由于老版本的master进程并未停止，所以我们可以向老的master进程发送HUP信号，即可通过老版本的master进程重新生成老版本的worker进程，当老版本的worker进程重新被拉起后，即可向新版本的master进程发送QUIT信号，以便优雅的关闭新版本的nginx进程，回滚操作完毕
首先在https://nginx.org/en/download.html 下载所需的软件包
然后将它上传到服务器上。在这里我特意建立一个文件夹，用来存放自己安装的各种软件 /software，就将安装包上传到这里。
然后执行如下命令 tar -xf nginx-1.14.2.tar.gz
解压完成后，我们看到了如下目录：
执行如下命令，我们可以知道在安装nginx时，我们可以使用的配置项
./configure --help
接下来，我们需要安装一下依赖的包，执行如下的命令即可
yum install -y gcc-c++
yum install -y pcre pcre-devel
yum install -y zlib zlib-devel
yum -y install pcre pcre-devel zlib zlib-devel openssl openssl-devel
然后，我们建立一个专门安装我们自己的软件的一个目录/apps
执行如下命令指定nginx的安装目录
./configure --prefix=/apps/nginx
执行如下命令进行编译
make
执行如下命令进行安装
make install
到了这里，我们的nginx就已经安装完毕了，现在我们启动一下，
执行如下命令进入启动脚本的所在位置
cd /apps/nginx/sbin
可以看到如下文件
nginx nginx.old
执行如下命令，就可以启动nginx
./nginx 启动命令
上面的默认启动，也可以加载指定的配置文件进行启动，命令如下：
./nginx -c nginx.conf
./nginx nginx.conf -t 可以测试配置文件是否正确，这里只是测试，不管配置文件是否正确，都不会启动服务器
./nginx -s stop 停止命令
./nginx -s quit 与stop信号的作用类似，quit信号作用也是用于停止nginx服务，quit信号和stop信号的区别在于，nignx进程收到stop信号以后会立即停止服务，而收到quit信号后，不会再接收新的请求，但是会先处理完已经接受的链接请求，处理完这些请求之后再停止服务，这种停止方式被称之为”优雅的停止”。
上面的直接关闭，下面的命令是优雅的关闭
kill -QUIT 主进程号 当这样停止的时候，不会接受新的请求，但是之前的请求会响应
kill -TERM 主进程号 当这样停止的时候，之前的请求也会终止响应
kill -9 nginx 强制结束进程，当没有办法用上述两个命令停止的时候，再用这个。
./nginx -s reload 重启命令 reload信号的作用就是在不停止服务的情况下重载配置文件，比如，nginx正在正常的提供服务，此时，管理员修改了nginx.conf文件中的配置指令，管理员希望新的配置立刻生效，但是又不希望重启nginx服务，此时就可以使用”nginx -s reload”命令重载配置文件，以便在不重启nginx的情况下载入新的配置，同时避免了因重启而造成的服务中断
./nginx -s reopen 利用reopen信号可以使nignx进程重新打开日志文件，以便实现日志分割的效果
./nginx -v 显示版本号
./nginx -V 会显示详细信息
在浏览器中输入ip
能看到下图，就说明已经成功启动了
上面，我们已经成功的安装了nginx服务器，我们知道，有两种方式安装nginx，分别是yum安装方式和编译源码安装方式。
但是通过这两种方式安装的nginx，目录结构不一样。
我们先看编译安装的方式
conf文件夹中存放着配置文件
html文件夹用来存放网页
log文件夹是用来存放日志
sbin文件夹中存放着启动用的命令文件
而通过yum安装方式安装的nginx，对应的启动文件已经拷贝到了usr/bin目录中，而且此目录已经加入到了环境变量中，所以，我们可以在任意位置执行nginx命令来启动
nginx服务器
编译安装后，配置文件放置在了安装目录的conf文件夹中
但是yum安装后，配置文件则放置在了/etc/nginx文件夹中
通过编译安装的方式安装nginx以后，默认的”server块”直接配置到了nginx.conf文件中，而通过官方yum源安装nginx后，默认的”server块”会配置在”/etc/nginx/conf.d/default.conf”文件中，换句话说就是，如果你通过官方yum源安装了nginx，那么你在/etc/nginx/nginx.conf文件中无法找到默认提供的server块，只能在/etc/nginx/conf.d/default.conf文件中找到默认的server块，这是为什么呢？其实，我们从/etc/nginx/nginx.conf文件中就能找到答案，打开/etc/nginx/nginx.conf文件，查看默认的http块的配置，你会在http块中发现如下配置指令 include /etc/nginx/conf.d/*.conf;
通过前文我们已经知道，在nginx中，我们可以通过location块与root指令结合的方式，将”url”与”服务器路径”建立起对应关系，location块负责匹配url，root指令负责将匹配到的url与服务器中某个具体目录对应起来，其实，除了root指令，还有另一个指令也能实现类似的功能，它就是alias指令，root指令和alias指令都能将url和服务器路径进行对应，但是，它们之间又存在一些区别：
root指令会将location块的”url路径”带入到”root指令路径”中，将带入后的路径作为”最终路径”，使用”最终路径”与url建立对应关系
alias指令则直接将location块的”url路径”与”alias指令路径”建立对应关系。
访问日志
当我们访问nginx服务时，nginx会记录日志，nginx日志分两种，一种是访问日志，一种是错误日志，访问日志记录在”access.log”文件中，错误日志记录在”error.log”文件中，这篇文章我们只关注访问日志的使用，也就是”access.log”。
如果你安装nginx的方式为编译安装，访问日志会放在安装路径的logs文件夹中，如果是通过yum安装的方式安装nginx，访问日志的路径就是/var/log/nginx/access.log
我们也可以自定义访问日志的位置，通过一条指令即可：
access_log /opt/access.log;
通过指令log_format 可以控制访问日志都记录哪些内容，以下的这些变量分别表示，如下内容
$remote_addr变量：记录了客户端的IP地址（普通情况下）。
$remote_user变量：当nginx开启了用户认证功能后，此变量记录了客户端使用了哪个用户进行了认证。
$time_local变量：记录了当前日志条目的时间。
$request变量：记录了当前http请求的方法、url和http协议版本。
$status变量：记录了当前http请求的响应状态，即响应的状态码，比如200、404等响应码，都记录在此变量中。
$body_bytes_sent变量：记录了nginx响应客户端请求时，发送到客户端的字节数，不包含响应头的大小。
$http_referer变量：记录了当前请求是从哪个页面过来的，比如你点了A页面中的超链接才产生了这个请求，那么此变量中就记录了A页面的url。
$http_user_agent变量：记录了客户端的软件信息，比如，浏览器的名称和版本号。
这些变量并非一定会有对应的值，如果变量没有对应的值，那么日志中会使用 “-” 进行占位。
log_format 指令只能配置在http块中
access_log 指令可以配置在如下地方：
http, server, location, if in location, limit_except
进程
当你启动nginx以后，使用ps命令查看nginx进程，会发现nginx进程不只有一个，默认情况下，你会看到至少两个nginx进程
当我启动nginx以后，有两个nginx进程，一个master进程，一个worker进程，其中master进程用来管理worker进程，worker进程才是真正来干活的进程。
除了管理worker进程，还会来读取配置文件，判断配置文件语法。在nginx中，master进程正常来说只能有一个，而worker进程可以有多个。具体数量可以用指令
worker_processes 来配置，worker_processes指令只能在main区域中使用
通常情况下，worker_processes的值通常不会大于服务器中cpu的核心数量，换句话说就是，worker进程的数量通常与服务器有多少cpu核心有关，比如，nginx所在主机拥有4核cpu，那么worker_processes的值通常不会大于4，这样做的原因是为了尽量让每个worker进程都有一个cpu可以使用，尽量避免了多个worker进程抢占同一个cpu的情况，当然，你想要的在4核的机器上将worker_processes的值设置为8，也是完全可行的。除了某个具体的数字，我们也可以将worker_processes的值设置为”auto”，如下：worker_processes auto
当worker_processes的值为auto时，nginx会自动检测当前主机的cpu核心数量，并启动对应数量的worker进程
同时，为了避免cpu在切换进程时产生性能损耗，我们也可以将worker进程与cpu核心进行”绑定”，当worker进程与cpu核心绑定以后，worker进程可以更好的专注的使用某个cpu核心上的缓存，从而减少因为cpu切换不同worker进程而带来的缓存失效，如果想要让worker进程与某个cpu核心绑定，则需要借助另外一个配置指令，它就是”worker_cpu_affinity”指令
要想知道该指令如何使用，就要了解一个概念，那就是cpu掩码，比如，当前机器上一共有4个cpu核心，那么我们就用4个0表示这4个核，也就是说，我们可以使用如下字符表示这4个核：
0001表示第一个核，0010表示第二个核，0100表示第三个核，1000表示第四个核
假如当前主机一共有两个cpu核心，我想要启动两个worker进程，并且将这两个worker进程分别绑定到两个核心上，那么我就可以通过如下两条配置指令完成上述设置
worker_processes 2;
worker_cpu_affinity 01 10；
worker_cpu_affinity 也只能在 main区域使用
编译安装nginx后，默认情况下worker进程是以”nobody”用户的身份运行的，如果我们想要指定worker进程的运行用户，则可以使用”user”指令，比如，指定worker进程以nginx用户的身份运行，配置如下：
user nginx
user指令也是只能在main区域使用
日志切割
nginx会将访问日志写入到access.log日志文件中，天长日久，access.log文件就会越来越大，如果访问量巨大，并不用多长时间，access.log文件的体积就会变得非常大，对于我们的管理工作来说，这是不利的，首先，当我们打开一个非常大的日志文件时，就会比较慢，而且，从一个非常大的日志中找到某个时间段的日志也会比较慢，所以，我们最好将日志按天分割开，比如，每天一个文件
通过编译的方式安装nginx后，默认没有日志分割的功能
通过yum源的方式安装nginx后，默认会对nginx日志进行切割
为nginx实现日志切割的方法通常有两种，第一种方法是编写脚本实现日志切割，第二种方法是使用系统自带的日志滚动软件”logrotate”完成日志切割，但是无论选择哪种方法，其实都是殊途同归，在本质上都是一样的
我们借助reopen信号，就能为nginx实现日志滚动的效果
其实，除了能够使用”nginx -s”命令发送信号，我们也可以借助”kill”命令向nginx进程发送信号，你肯定经常使用kill命令，当你想要强制停掉进程的时候，会使用”kill -9 pid”向进程发送”SIGKILL”信号，除了”-9″代表的”SIGKILL”信号，我们也可以借助kill命令向进程发送一些别的信号。我们需要借助kill命令，向nginx主进程发送一个名为”USR1″的信号，在程序中，”USR1″信号的作用是可以自定义的，也就是说，当程序捕捉到”USR1″信号的时候进行什么操作，取决于编程时的设定，不同的程序采取的操作可能不同，而在nginx中，”USR1″信号可以帮助我们重新打开日志，换句话说就是，”nginx -s reopen”命令的作用和”kill -USR1 NginxPid”的作用是一样的，”NginxPid”指的是nginx的master进程的进程号，所以，在编写nginx日志滚动脚本时，你可以使用这两个命令中的任何一个，以便nginx可以重新打开日志文件
如果你使用了yum源的方式安装了nginx，你会发现在安装完nginx后默认就有日志滚动的功能，这是因为通过yum源安装nginx后，默认会安装一个日志滚动的配置文件，这个配置文件就是”/etc/logrotate.d/nginx”，可以看出，这是一个logrotate配置文件，也就是说，nginx借助这个配置文件，使用logrotate完成了日志分割的操作，通常情况下，centos系统默认自带logrotate，logrotate是一个日志管理工具，此处讨论的重点也不是logrotate，重点是nginx怎样通过logrotate完成日志滚动的，所以，打开”/etc/logrotate.d/nginx”配置文件，你会从中找到如下一行命令 kill -USR1 `cat /var/run/nginx.pid`
信号
我们已经知道，当我们需要让nginx重新打开日志文件时，需要使用kill命令向nginx的master进程发送USR1信号，或者执行”nginx -s reopen”命令，它们的效果是完全一样的，那么你可能会问，”nginx -s”命令除了能够使用reopen，不是还能够使用reload、stop和quit么，那么reload、stop、quit有没有完全等效的信号呢？还真有，这些信号的对应关系如下：
reopen对应USR1信号
reload对应HUP信号
stop对应TERM信号或者INT信号
quit对应QUIT信号
通过上述对应关系我们可以推断出，”nginx -s reload”命令与”kill -HUP NginxMasterPid”命令的作用是一样的
之前说过，master进程是负责管理worker进程的，其实，当我们向master进程发送信号时，master进程就会根据捕捉到的信号来管理worker进程，那么，我们都能向master进程发送哪些信号呢？我们能向master进程发送如下信号：
TERM或者INT：表示立即停止nginx
QUIT：表示优雅的停止nginx
HUP：重载配置文件
USR1：重新打开日志文件
USR2：热升级nginx程序
WINCH：优雅的关闭相应的worker进程
其实，不仅master进程可以直接接收信号，work进程也可以直接接收信号，但是通常情况下，我们不应该手动的向worker进程直接发送信号，而是应该通过master进程来管理他们，虽然我们不应该向work进程发送信号，但是此处还是列出worker进程可以接收到的信号，以便了解它们，worker进程可以接收的信号如下：
TERM信号或INT信号
QUIT信号
USR1信号
WINCH信号
如果因为某些原因，worker进程意外终止了，master进程会创建一个新的worker进程，以保证有对应的worker进程可以使用，当子进程worker进程终止时，会向master父进程发送CHLD信号，当master进程收到CHLD信号以后，就会知道对应的worker进程退出了，此时，master进程会创建一个新的worker进程
热升级
所谓的热升级也叫做热部署，或者平滑升级，也就是说，在不停止nginx服务的情况下，完成nginx的升级工作。
这里有一个注意点，就是使用这种方法有一个前提，前提就是你在启动nginx时使用的是nginx二进制文件的绝对路径，而不是直接在命令行中输入”nginx”的方式启动的nginx服务
最重要的一步，备份
1、下载新版本的nginx，根据老版本的编译选项，对新版本完成编译的步骤，只对新版本进行编译操作，不执行安装操作，换句话说就是，只执行make命令，不执行make install命令，完成编译操作后，即可获取到我们需要的新版本的二进制文件，之后，我们需要根据实际情况判断哪些文件需要被替换
2、确定已经备份老版本的nginx二进制文件，以防万一，用编译好的新版本的nginx二进制文件替换老版本的nginx二进制文件，此时老版本的nginx仍然在内存中正常运行，所以不用担心，我们替换的只是硬盘中的二进制文件，做好备份即可
3、对nginx的master进程（正在运行的老版本的master进程）发送USR2信号，老版本的master进程收到信号后，会通过新版本的二进制文件启动新版本的master进程，新版本的master进程会启动新版本的worker进程，此时新老版本的nginx进程同时存在
4、向老版本的master进程发送WINCH信号，以便先优雅的停止老版本的worker进程，新的请求会被新版本的worker进程处理，此时老的master进程仍然存在，留下老的master进程是为了以防万一，以便随时回滚，此时老版本的master进程、新版本的master进程和新版本的worker进程同时存在，升级过程暂且完毕
5、如果升级后万一出现问题，则可以随时进行回滚，由于老版本的master进程并未停止，所以我们可以向老的master进程发送HUP信号，即可通过老版本的master进程重新生成老版本的worker进程，当老版本的worker进程重新被拉起后，即可向新版本的master进程发送QUIT信号，以便优雅的关闭新版本的nginx进程，回滚操作完毕
Tags：nginx
很赞哦！ ()
上一篇：Linux搭建svn服务
