Nginx（二）基础命令，模块，进程概述以及alisa和root的区别
nginx基础命令
| -h 或 nginx -? | 查看nginx命令都有哪些可用的选项 |
|---|---|
| nginx -v | 使用"-v"选项(小写v)可以查看inginx的版本信息 |
| nginx -V | 使用"-V"选项(大写V)可以查看当前nginx的编译信息 |
| nginx -t | 使用"-t"选项或者"-T"选项可以测试nginx.conf配置文件中是否存在语法错误 |
| nginx -s | 向正在运行的nginx主进程发送信号，信号的可用值有stop, quit, reopen, reload时 |
nginx模块,配置指令,块之间的关系
1.在serevr里添加一个location
2.在/opt/demo下写发布页面，在上传一张图片：
测试：
访问/demo时默认就是刚才写的index.html里的内容
加上指定路径
3.优先级
在serevr中指定index的前提下，对某一个location添加自己的index,则会改掉某一个location的默认发布页面。也就是局域的index的优先级高于serevr中的index的优先级
通过上述示例，你肯定明白了一个道理，同一个配城指令,配置在不同的块中时，对应的"作用域"是不同的。
某些配置指令只能在http块中配i,某些配i指令只能在location块中配置，有些配置指令既能在server块中配置
又能在http块中配置，而有些配置指令只能在main区中进行配i。其实，刚才示例中的index指令就属于那种既能在location块中配置，又能在server块中配置，还能再http块中配置的指令，只不过，当index指令配在>不同的块中时，对应的作用域不同。
举一反三，有些指令既能配置在server块中，也能配置在http块中，当多个server存在相同的配置时，我们可以将这些完全相同的配置指令提取到上一级的http块中，以便多个server块共用这些配置t
，当然，如果你在某个server中单独配置了对应的配i指令，那么这个server仍然会以自己的配置为准。
其实，“配置指令"不仅和"块"有一定的关系，
“配f指令"和"模块"也有着非常紧密的对应关系，之前总结过，nginx是模块化的，不同的"模块"负责不同的"功能”，所以，当我们需要针对某个"功能"进行配时，就需要使用到对应的"配置指令”，从根本.上来说，每个"配指令"都属于某一个"模块"，-个"模块"中会有一个或多个"配指令"，当我们想要对相关模块或者功能进行设置时，就会使用到对应模块中的配置指令。
当然，作为用户，没有人天生就会使用nginx的这些配指令，也没有人能够记住所有模块、配f指令、块之间的关系，所以，我们可以通过官方的文档进行查询，那么此处，我们就来介绍一下怎样通过官网文档找到我们想要的答案
Nginx进程概述
当你启动nginx以后，使用ps命令查看nginx进程，会发现nginx进程不只有一-个，默认情况下，你会看到至少两个nginx进程如下：
此时发现nginx的用户是nobady，现在添加nginx用户
修改文件
总结：编译安装nginx后，|默认情况下worker进程是以"nobody"用户的身份运行的，如果我们想要指定worker进程的运行用户，则可以使用"user"指令，比如，指定worker进程以nginx用户的身份运行
当我启动nginx以后，有两个nginx进程，一个master进程，一个worker进程，这两个nginx进程都有各自的作用，见名知意，"worker"进程天生就是来"干活"的，真[正负责处理请求的进程就是你看到的"worker"进程，那么"master"进程有什么用呢? “master"进程其实是负责管理"worker"进程的，除了管理"worker"进程，master”
进程还负责读取配置文件、判断配置文件语法的工作，“master进程"也叫"主进程”，在nginx中， "master"进程只能有一个，而"worker"进程可以有多个，worker"进程的数量可以由管理员自己进行定义，那么怎么定义"worker"进程的数量呢?没错，我们只需要借助一条配置指令即可，这条配置指令就是"worker_ processes"指令
默认的nginx.conf配置l文件中有这样一条配置worker_ processes 1;
.上述配置的意思就是启动nginx后只有1个worker进程，你想要多少个worker进程，将worker_ processe指令的值设;成多少就好了，非常简单，worker_ processes指令只能在main区域中使用，通常情况下，worker_ processes的值通常不会大于服务器中cpu的核心数量,换句话说就是，worker进程的数量通常与服务器有多少cpu核心数量，比如，nginx所在主机拥有4核cpu,那么worker_ processes的值通常不会大于4，这样做的原因是为了尽量t让每个worker进程都有一个cpu可以使用，尽避免了多个worker进程抢占同一个cpu的情况,我们也可以将worker_ processes的值设置为"auto"当worker_ processes的值为auto时，nginx会自动检测当前主机的cpu核心数量， 并启动对应.数量的worker进程，比如，nginx检测到当前主机一共有4个cpu核心，那么nginx就会启动4个worker进程
示例：
添加8个
同时，为了避免cpu在切换进程时产生性能损耗，我们也可以将worker进程与cpu核心进行"绑定",当worker进程与cpu核心绑定以后，worker进程可以更好的专注的使用某个cpu核心上的缓存，从而减少因为cpu切换不同worker进程而带来的缓存失效，如果想要让worker进程与某个cpu核心绑定，则需要借助另外-个配量指令,它就是"worker_cpu_affinity"指令
想要搞明白怎样使用"worker_ cpu_ affinity"指令，最好先来了解一个概念，这个概念就是"cpu掩码",我们可以通过"cpu掩码"表示某个cpu核心，比如，当前机器上一共有4个cpu核心，那么我们就用4个0表示这4个核，也就是说，我们可以使用如下字符表示这4个核: 0000
| 0001 | 第一个核 |
|---|---|
| 0010 | 第二个核 |
| 0100 | 第三个核 |
| 1000 | 第四个核 |
规律就是，有几个核，就用几个0表示，如果想要使用某个核，就将对应位f的0改成1,位从右边开始
比如，如果有8个核，我就可以使用如下字符表示这8个核中的第二个核:00000010
示例：
配置指令root和alias的区别
在nginx中，我们可以通过location块与root指令结合的方式,将"url"与"服务器路径"建立起对应关系，location块负责匹配url，root指令负责将匹已到的url与服务器中某个具体目录对应起来,其实，除了root指令，还有另-个指令也能实现类似的功能，它就是alias指令，root指令和alias指令都能将urI和服务器路径进行对应，但是，它们之间又存在一些区别
location /demo {
root /opt/test;
}
location块匹配的url为"/demo",
root指令的路径为"/opt/test"
,那么，根据上述配置，当我们访问"/demo"这个urI时，实际上访问的到底是服务器中的哪个路径呢?答案是"/opt/test/demo"路径那么，我们来举一反三试试，配置上述location块后，当我们访问"/demo/test1/nginx.jpg"这个url时，我们访问的是哪个目录中的文件呢?你肯定已经想到了正确答案，答案就是"/opt/test/demo/test1/nginx.jpg"
location /demo1 {
alias /opt/test;
}
如你所见，alias指令对应的值也是一个路径，当alias指令与location块结合时，它们会怎样建立url与服务器路径的对应关系呢?答案如下:上例配表示，当我们访问"/demo1/nginx1.jpg"时，其实就是在访问服务器的"/opt/test/nginx1.jpg",也就是说当我们使用alias时，location的url是与alias的路径完全对等的
看到此处，root指令和alias指令的区别就很明显了。root指令会将location块的"url路径"带入到" root指令路
径"中，将带入后的路径作为"最终路径"，使用"最终路径"与urI建立对应关系。alias指令则直接将location块的"url路径"与" alias指令路径"建立对应关系
测试：