最近花了一些时间来总结nginx常用的技能知识点，通过一些常用的实际案例来将nginx的众多小知识点串联起来。
首先是进入nginx目录进行脚本启动，准备初始化环境：
[root@idea-centos nginx]# cd ./sbin/ [root@idea-centos sbin]# ll total 3528 -rwxr-xr-x. 1 root root 3611160 Dec 26 16:43 nginx [root@idea-centos sbin]# ps -ef|grep nginx root 7270 7194 0 10:42 pts/1 00:00:00 grep --color=auto nginx [root@idea-centos sbin]# ./nginx [root@idea-centos sbin]# ps -ef|grep nginx root 7272 1 0 10:42 ? 00:00:00 nginx: master process ./nginx nobody 7273 7272 0 10:42 ? 00:00:00 nginx: master process ./nginx root 7275 7194 0 10:42 pts/1 00:00:00 grep --color=auto nginx
启动成功之后，通过curl可以进行访问测试
首先通过 ip add来查看地址信息（本人使用的是虚拟机）：
[root@idea-centos sbin]# ip add 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0c:29:ea:63:63 brd ff:ff:ff:ff:ff:ff inet 192.168.43.235/24 brd 192.168.43.255 scope global noprefixroute dynamic ens33 valid_lft 2922sec preferred_lft 2922sec inet6 2409:8955:3048:50d5:e7e8:636d:bdf1:7033/64 scope global noprefixroute dynamic valid_lft 2964sec preferred_lft 2964sec inet6 fe80::8a65:608b:505e:fe4/64 scope link noprefixroute valid_lft forever preferred_lft forever
然后通过curl在本虚拟机上边进行测试：
[root@idea-centos sbin]# curl http://192.168.43.235/ <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
如果访问失败，请先查看防火墙是否开启，如果开启了，可以先进行关闭，方便展开后续的demo练习：
[root@idea-centos sbin]# firewall-cmd --state running [root@idea-centos sbin]# systemctl stop firewalld.service [root@idea-centos sbin]# firewall-cmd --state not running
访问成功之后，会看到nginx的首页：
nginx常用的基础命令总结
#默认方式启动： ./sbin/nginx #指定配置文件启动 ./sbing/nginx -c /tmp/nginx.conf #指定nginx程序目录启动 ./sbin/nginx -p /usr/local/nginx/ #快速停止 ./sbin/nginx -s stop #优雅停止 (会等当前的请求先处理完再杀死) ./sbin/nginx -s quit # 热装载配置文件 ./sbin/nginx -s reload # 重新打开日志文件 ./sbin/nginx -s reopen # 检测配置是否正确 ./sbin/nginx -t
启动nginx之后，可以通过日志来查看进程的相关信息
[root@idea-centos nginx]# ./sbin/nginx [root@idea-centos nginx]# ps -ef|grep nginx root 11059 1 0 16:34 ? 00:00:00 nginx: master process ./sbin/nginx nobody 11060 11059 0 16:34 ? 00:00:00 nginx: worker process root 11062 8193 0 16:34 pts/1 00:00:00 grep --color=auto nginx
master process 主要是负责日志的更新，热装载 主进程
worker process 工作进程 处理客户端的连接，处理请求
nginx的日志
在nginx的log文件夹底下，我们在重新访问服务器之后，相应的access日志就会增加新的属性内容。
这里面的日志寻找，实际上是根据对象句柄来进行查找指定的文件。
关于nginx处理机制的理解
nginx里的高性能主要归咎于其相应特有的io多路复用。每当有请求发送过来的时候，请求的都会被放入到一个select队列里面，专门存储客户端的http链接信息，然后通过一个专门的选择器来处理轮询，监听客户端是否有发送请求的数据（一直轮询，直到有数据发送过来的时候才会发生堵塞），一旦当接收到发送的数据时，selector就会做出指定的处理。
当我们启动了nginx之后，会有两类型进程出现，分别是master进程和worker进程，而客户端发送的请求通常只是和master进程进行通信，master进程负责接收这些请求，然后分发给不同的worker进程进行处理。
其实本质上，worker进程是从master进程这边fork出来的，在master的进程里面，需要先建立好被监听的socket之后，再fork出多个worker进程，多个worker进程（多核cpu环境下）会争抢accept_mutex互斥锁，抢锁成功的进程就会注册相应的事件对任务进行处理。这种独立进程处理事件的好处在于避免了原本的加锁开销，同时当进程中出现了bug异常的时候，不会影响其他的进程，降低了风险。
nginx处理高并发的方式又是如何的呢？当采用多个worker来处理请求的时候，每个worker里面都只有一个主线程，但是这样处理并发数非常有限，那当并发数量大的时候，是否又需要创建成千上万的线程来实现请求的处理呢？
nginx的设计高明之处就在于了这一点上了，它的机制有点类似于linux里面的epoll这样的系统调度。处理的响应线程（暂命名为A）只有一个，当请求过来的事件处理完毕的时候，会主动通知A , 不会对堵塞的请求等待操作。这样的设计避免了A主动去轮询和等待事件处理的所带来的事件消耗。
相比于传统的apache服务器，每一个连接，apache就会创建一个进程，每个进程内单线程，apache最多能创建256个进程。对于一个负载相对较高的网站来说，256的进程，也就是256个线程，因为线程处理请求时，是同步阻塞模式，接收请求之后，会一直等待该请求读取程序文件（IO）（同步），执行业务逻辑，返回客户端，所有操作完成之后才能处理下一个请求（阻塞）如果服务器已经达到256的极限，那么接下去的访问就需要排队这也就是为什么某些服务器负载不高的原因了。
小结
- 每个worker进程都是单线程的模式
- 每个io链接都是基于异步非堵塞的模型建立的。
- worker进程的数目结合服务器的cpu数量来进行设置，可以达到调优的效果
