Nginx进程模型分析
在介绍Nginx的进程模型以前咱们先来给你们解释下一些常见的名词，这能辅助咱们更好的了解Nginx的进程模型。做为Web服务器，设计的初衷就是为了可以处理更多的客户端的请求，通常来讲，完成并行处理请求工做有三种方式能够选择，多进程、多线程、异步方式。nginx
多进程方式
服务器每接收到一个客户端请求，就会由主进程生成一个子进程出来和该请求创建链接进行交互，直到链接断开之后子进程也就结束了
优势在于各个子进程之间相互独立，各个客户端请求之间相互不受干扰。
缺点是生成一个子进程须要进行内存复制、在资源和时间上会产生必定的额外开销。若是请求比较多的时候，会对系统资源形成必定的压力web
多线程方式
多线程方式和多进程方式很类似，服务器每接收到一个客户端请求时，会产生一个线程与该客户端进行交互。而产生一个线程的开销比进程小不少，因此多线程的方式在必定程度上减轻了web服务器对系统资源的要求。
缺点是多线程之间存在内存共享、彼此间存在相互影响的状况json
异步方式
异步方式和前面说的两种方式彻底不同，关于异步这块，还有几个概念同步、异步； 阻塞、非阻塞，在这里一块儿作一个讲解
关于同步和异步，咱们很好理解。同步机制是指发送方发送请求后，须要等待接收方返回响应后，才能发送下一个请求，而异步机制，发送方发送请求后，不等待接收方响应这个请求，就继续发送下个请求。服务器
阻塞和非阻塞，主要指socket读写数据的阻塞和非阻塞方式。Socket的本质其实也是IO操做。每个TCP Socket的内核中都有一个发送缓冲区和接收缓冲区。对与阻塞模式来讲，若是接收缓冲区为空，那么socket的read方法的线程就会阻塞，直到有数据进入接收缓冲区。而对于写数据到socket中而言，若是待发送的数据长度大于发送缓冲区的空余长度，那么write方法会进入阻塞。
网络
乍一看这四个概念的解释会瞬间感到头大，也常常讲同步异步等同于阻塞非阻塞，其实，区分他们很是简单。多线程
同步异步与阻塞非阻塞的主要区别是针对对象不一样。异步
同步异步是针对调用者来讲的，调用者发起一个请求后，一直干等被调用者的反馈就是同步，没必要等去作别的事就是异步。socket
阻塞非阻塞是针对被调用者来讲的，被调用者收到一个请求后，作完请求任务后才给出反馈就是阻塞，收到请求直接给出反馈再去作任务就是非阻塞。线程
而对于非阻塞模式来讲，经过事件触发的方式来达到目的。咱们能够认为NIO底层中存在一个I/O调度线程，它不断的扫描每一个Socket的缓冲区，当发现写入缓冲区为空的时候，它会产生一个Socket可写事件，此时程序就能够把数据写入到Socket中。若是一次写不完，就等待下一次的可写事件通知；反之，当发现缓冲区里有数据的时候，它会产生一个Socket可读事件，程序收到这个通知事件就能够从Socket读取数据了。
那么基于这些概念又引除了四个概念： 同步阻塞、同步非阻塞、异步阻塞、异步非阻塞设计
**同步阻塞：**发送方向接收方发送请求后，一直等待接收方响应；接收方在处理请求时进行的IO操做若是不能立刻获得结果，就一直等待结果返回才响应发送方。期间一直处于阻塞状态；
**同步非阻塞：**发送方向接收方发送请求后，一直等待响应，接收方在进行IO操做的时候，能够不须要等待直接去作其余事，而由于尚未得到结果，发送方仍然处于等待状态。接收方得到io的操做完成后，把结果响应给发送方，接收方才进入下一次请求过程
**异步阻塞：**发送方向接收方发送请求后，不用等待响应，能够接着进行其余操做。接收方处理请求时进行的IO操做若是不能马上得到结果，就一直等待返回结果后向发送方响应
**异步非阻塞：**发送方发送请求后，不用等待响应，能够继续作其余事情。接收方处理请求时进行的IO操做若是不能立刻获得结果，也不等待，而是去作其余事情。当io操做完成后，把结果通知给接收方，接收方再响应给发送方
Nginx服务器的请求处理过程
Nginx结合了多进程机制和异步机制对外提供服务
Nginx服务启动后，会产生一个主进程和多个工做进程。
master进程主要用来管理worker进程，包含：接收来自外界的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常状况下)，会自动从新启动新的worker进程
而基本的网络事件，则是放在worker进程中来处理了。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的求，worker进程的个数是能够设置的，通常咱们会设置与机器cpu核数一致
Master进程的做用是？
读取并验证配置文件nginx.conf；管理worker进程；
Worker进程的做用是？
每个Worker进程都维护一个线程（避免线程切换），处理链接和请求；注意Worker进程的个数由配置文件决定，通常和CPU个数相关（有利于进程切换），配置几个就有几个Worker进程。
热部署
master来管理worker进程，因此咱们只须要与master进程通讯就好了。master进程会接收来自外界发来的信号，再根据信号作不一样的事情,好比咱们前面经常使用的
./sbin/nginx -c conf/nginx.conf -s reload
执行这个命令时，master收到这个信号之后先启动一个新的Nginx进程，而新的Nginx进程在解析到reload参数后，就知道是要控制Nginx来从新加载配置文件，它会向master进程发送信号，而后master会从新加载配置文件，在启动新的worker进程，并向全部老的worker进程发送信号，告诉他们能够退休了，新的worker启动以后就能够以新的配置文件接收新的请求了 – 热部署的原理
worker进程是如何处理请求？
咱们基本上知道了在操做nginx时，nginx内部所作的事情，那么worker进程是如何处理请求的呢？ 在Nginx中，全部的worker进程都是平等的，每一个进程处理每一个请求的机会是同样的。当咱们提供80端口的http服务时，一个链接请求过来，每一个进程均可能处理这个链接。
worker进程是从master进程fork过来的，而在master进程中，会先创建好须要listen的socket，而后fork出多个worker进程，当有新链接请求过来时work进程能够去处理，为了不惊群效应，worker进程在处理请求以前先要去抢占accept_mutex，也就是互斥锁，当得到锁成功之后，就能够去解析处理这个请求。请求处理完之后再返回给客户端。
进程模型的处理方式带来的一些好处就是：进程之间是独立的，也就是一个worker进程出现异常退出，其余worker进程是不会受到影响的；此外，独立进程也会避免一些不须要的锁操做，这样子会提升处理效率，而且开发调试也更容易。
worker进程会竞争监听客户端的链接请求：这种方式可能会带来一个问题，就是可能全部的请求都被一个worker进程给竞争获取了，致使其余进程都比较空闲，而某一个进程会处于忙碌的状态，这种状态可能还会致使没法及时响应链接而丢弃discard掉本有能力处理的请求。这种不公平的现象，是须要避免的，尤为是在高可靠web服务器环境下。
针对这种现象，Nginx采用了一个是否打开accept_mutex选项的值，ngx_accept_disabled标识控制一个worker进程是否须要去竞争获取accept_mutex选项，进而获取accept事件
ngx_accept_disabled值：nginx单进程的全部链接总数的八分之一，减去剩下的空闲链接数量，获得的这个ngx_accept_disabled。
当ngx_accept_disabled大于0时，不会去尝试获取accept_mutex锁，而且将ngx_accept_disabled减1，因而，每次执行到此处时，都会去减1，直到小于0。不去获取accept_mutex锁，就是等于让出获取链接的机会，很显然能够看出，当空闲链接越少时，ngx_accept_disable越大，因而让出的机会就越多，这样其它进程获取锁的机会也就越大。不去accept，本身的链接就控制下来了，其它进程的链接池就会获得利用，这样，nginx就控制了多进程间链接的平衡了。
好了~本文先介绍到这里，有问题的欢迎留言交流 ~