nginx

events {
    #nginx使用连接互斥锁进行顺序的accept（）系统调用，防止惊群现象发生，默认为on（on时顺序调用防止惊群，大流量高并发不推荐）  惊群解释当设置为off时，一个请求从客户端过来，会导致nginx唤醒所有的进程，但只有一个会work进程能够获取到这个链接，其他空闲的work进程重新进入休眠（其他唤醒的空闲的work是无用功）
    #Apache动辄就会启动成百上千的进程，如果发生惊群问题的话，影响相对较大；但是对Nginx而言，一般来说，worker_processes会设置成CPU个数，所以最多也就几十个，即便发生惊群问题的话，影响相对也较小。
    #另：高版本的Linux中，accept不存在惊群问题，不过epoll_wait等操作还有
    
    比喻：
    /*
        假设你养了一百只小鸡，现在你有一粒粮食，那么有两种喂食方法：
        你把这粒粮食直接扔到小鸡中间，一百只小鸡一起上来抢，最终只有一只小鸡能得手，其它九十九只小鸡只能铩羽而归。这就相当于关闭了accept_mutex。
        你主动抓一只小鸡过来，把这粒粮食塞到它嘴里，其它九十九只小鸡对此浑然不知，该睡觉睡觉。这就相当于激活了accept_mutex。
        可以看到此场景下，激活accept_mutex相对更好一些，让我们修改一下问题的场景，我不再只有一粒粮食，而是一盆粮食(大流量高并发)，怎么办？

        此时如果仍然采用主动抓小鸡过来塞粮食的做法就太低效了，一盆粮食不知何年何月才能喂完，大家可以设想一下几十只小鸡排队等着喂食时那种翘首以盼的情景。此时更好的方法是把这盆粮食直接撒到小鸡中间，让它们自己去抢，虽然这可能会造成一定程度的混乱，但是整体的效率无疑大大增强了。
    */
    #高并发访问量大的网站请设置为off
    accept_mutex on; 
    
    #设置一个进程是否同时接受多个网络连接，默认为off  (on时告诉nginx收到一个新连接通知后接受尽可能多的连接)
    multi_accept on; 
    
    #如果一个进程没有互斥锁，它将至少在这个值的时间后被回收(即在accept_mutex 启用时其他空余进程不会被唤醒而是轮流处于进程等待 而accept_mutex_delay指定的时间就是这些worker进程的等待时间，等待时间一到则等待的进程将尝试获取互斥锁并开始接受新的连接)，默认是500ms  
    accept_mutex_delay 500ms;
    
    #指定只记录由某个客户端IP产生的debug信息
    debug_connection 192.168.0.1;
    
    ############
    #
    devpoll_changes
    
    #
    devpoll_events
   
    #
    kqueue_events
    
    #
    epoll_events
    ############    

    ##########################
    #
    rtsig_signo
   
    #
    rtsig_overflow_events
    
    #
    rtsig_overflow_test
    
    #
    rtsig_overflow_threshold
    ##########################


    #事件驱动模型，select|poll|kqueue|epoll|resig|/dev/poll|eventport
    use epoll; #用户复用客户端线程的轮训方法。
    
    #单个work进程允许的最大连接数，默认为512
    worker_connections 1024; 
}

 

查看Nginx的版本号：

 nginx -V

nginx安装目录sbin下（或者自己配置全局）
强制关闭

nginx： nginx -s stop

优雅关闭nginx（处理完请求后关机）：

nginx -s quit
或者：
ps -ef|grep nginx #查看进程
kill -HUP 进程id   #杀掉进程

重新加载配置文件：

nginx -s reload

重新打开日志文件

nginx -s reopen

配置文件的结构：由多个上下文模块以及main组成

不同模块指令关系：server继承main；location继承server；upstream既不会继承指令也不会被继承，它有自己的特殊指令，不需要在其他地方的应用

#main全局块
... 

events { #events块
    ...
}

http #http块
{
    #http全局块
    ... 

    #server块①
    server 
    { 
        #server全局块
        ... 
        #location块①
        location [PATTERN] #location块
        {
            ...
        }
        #location块②
        location [PATTERN] 
        {
            ...
        }
     }
    
    #server块②
    server
    {
        ...
    }

    #http全局块
    ... 
}        

说明：

1、main全局块：配置影响nginx全局的指令。一般有运行nginx服务器的用户组，nginx进程pid存放路径，日志存放路径，配置文件引入，允许生成worker process数等。

2、events块：配置影响nginx服务器或与用户的网络连接。有每个进程的最大连接数，选取哪种事件驱动模型处理连接请求，是否允许同时接受多个网路连接，开启多个网络连接序列化等。

3、http块：可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能和第三方模块的配置。如文件引入，mime-type定义，日志自定义，是否使用sendfile传输文件，连接超时时间，单连接请求数等。

4、server块：配置虚拟主机的相关参数，一个http中可以有多个server。

5、location块：配置请求的路由，以及各种页面的处理情况。

 

events

events {
    #设置网路连接序列化，防止惊群现象发生，默认为on  惊群解释当设置为off时，一个请求从客户端过来，会导致nginx唤醒所有的进程，但只有一个会work进程能够获取到这个链接，其他空闲的work进程重新进入休眠（其他唤醒的空闲的work是无用功）
    #Apache动辄就会启动成百上千的进程，如果发生惊群问题的话，影响相对较大；但是对Nginx而言，一般来说，worker_processes会设置成CPU个数，所以最多也就几十个，即便发生惊群问题的话，影响相对也较小。
    #另：高版本的Linux中，accept不存在惊群问题，不过epoll_wait等操作还有
    
    比喻：
    /*
        假设你养了一百只小鸡，现在你有一粒粮食，那么有两种喂食方法：
        你把这粒粮食直接扔到小鸡中间，一百只小鸡一起上来抢，最终只有一只小鸡能得手，其它九十九只小鸡只能铩羽而归。这就相当于关闭了accept_mutex。
        你主动抓一只小鸡过来，把这粒粮食塞到它嘴里，其它九十九只小鸡对此浑然不知，该睡觉睡觉。这就相当于激活了accept_mutex。
        可以看到此场景下，激活accept_mutex相对更好一些，让我们修改一下问题的场景，我不再只有一粒粮食，而是一盆粮食，怎么办？

        此时如果仍然采用主动抓小鸡过来塞粮食的做法就太低效了，一盆粮食不知何年何月才能喂完，大家可以设想一下几十只小鸡排队等着喂食时那种翘首以盼的情景。此时更好的方法是把这盆粮食直接撒到小鸡中间，让它们自己去抢，虽然这可能会造成一定程度的混乱，但是整体的效率无疑大大增强了。
    */
    #高并发访问量大的网站请设置为off(不要轻易用哦CPU占用会大幅提高，QPS严重恶化accept_mutex on时，QPS：3500，负载只有0.3  accept_mutex off时，QPS：2500，负载达到9.5，且CPU占用极高)
    accept_mutex on; 
    
    #设置一个进程是否同时接受多个网络连接，默认为off  (on时告诉nginx收到一个新连接通知后接受尽可能多的连接)
    multi_accept on; 
    
    #如果一个进程没有互斥锁，它将至少在这个值的时间后被回收，默认是500ms
    accept_mutex_delay 500;
    
    #指定只记录由某个客户端IP产生的debug信息
    debug_connection 192.168.0.1;
    
    ############
    #
    devpoll_changes
    
    #
    devpoll_events
   
    #
    kqueue_events
    
    #
    epoll_events
    ############    

    ##########################
    #
    rtsig_signo
   
    #
    rtsig_overflow_events
    
    #
    rtsig_overflow_test
    
    #
    rtsig_overflow_threshold
    ##########################


    #事件驱动模型，select|poll|kqueue|epoll|resig|/dev/poll|eventport
    use epoll; 
    
    #单个work进程允许的最大连接数，默认为512
    worker_connections 1024; 
}

 

http
server
location