为何nginx很快？
第一我们要知道，Nginx 采纳的是多进程（单线程） & 多路IO复用模型。使用了 I/O 多路复用技术的 Nginx，就成了”并发事件驱动“的效劳器。
（引荐教程：nginx教程）
多进程的工作模式
Nginx 在启动后，会有一个 master 进程和多个彼此独立的 worker 进程。master 接收来自外界的信号，向各 worker 进程发送信号，每个进程都有大概来处置这个连接。master 进程能监控 worker 进程的运转状态，当 worker 进程退出后(非常状况下)，会主动启动新的 worker 进程。
留意 worker 进程数，一样会设定成机器 cpu 核数。由于更多的 worker 数，只会致使进程彼此竞争 cpu ，从而带来不必要的上下文切换。
使用多进程模式，不仅能提高并发率，并且进程之间彼此独立，一个 worker 进程挂了不会影响到其他 worker 进程。
惊群现象
主进程（master 进程）第一通过 socket() 来创立一个 sock 文件描写符用来监听，然后fork生成子进程（workers 进程），子进程将继承父进程的 sockfd（socket 文件描写符），之后子进程 accept() 后将创立已连接描写符（connected descriptor），然后通过已连接描写符来与客户端通讯。
那么，由于所有子进程都继承了父进程的 sockfd，那么当连接进来时，所有子进程都将收到通知并“争着”与它创立连接，这就叫“惊群现象”。大量的进程被激活又挂起，只要一个进程可以accept() 到这个连接，这当然会耗损系统资源。
Nginx对惊群现象的处置
Nginx 供给了一个 accept_mutex 这个东西，这是一个加在accept上的一把同享锁。即每个 worker 进程在施行 accept 此前都需要先猎取锁，猎取不到就舍弃施行 accept()。有了这把锁之后，统一时刻，就只会有一个进程去 accpet()，这样就不会有惊群问题了。 accept_mutex 是一个可控选项，我们可以显示地关掉，默许是翻开的。
Nginx进程详解
Nginx在启动后，会有一个master进程和多个worker进程。
master进程
主要用来治理worker进程，包括：
接收来自外界的信号向各worker进程发送信号监控worker进程的运转状态，当worker进程退出后(非常状况下)，会主动从新启动新的worker进程
master进程充当整个进程组与会员的交互接口，同时对进程停止监护。它不需要处置网络事件，不负责业务的施行，只会通过治理worker进程来实现重新启动效劳、平滑升级、改换日志文件、配置文件实时生效等功效。
我们要操纵nginx，只需要通过 kill 向master进程发送信号就行了。比方kill -HUP pid 是告诉nginx沉着地重新启动nginx。我们一样用这个信号来重新启动nginx，或从新加载配置，由于是沉着地重新启动，因此效劳是不中止的。master进程在接收到HUP信号后是如何做的呢？
第一master进程在接到信号后，会先从新加载配置文件然后再启动新的worker进程并向所有老的worker进程发送信号，告诉他们可以光荣退休了新的worker在启动后，就开端接收新的恳求，
老的worker在收到来自master的信号后，就不再接收新的恳求，并且在当前进程中的所有未处置完的恳求处置完成后，再退出。
当然，直接给master进程发送信号，这是比力老的操纵方式，nginx在0.8版本之后，引入了一系列命令行参数，来利便我们治理。比方 ./nginx -s reload 就是来重新启动nginx，./nginx -s stop 就是来休止nginx的运转。怎样做到的呢？我们还是拿reload 来说，我们看到，施行命令时，我们是启动一个新的nginx进程，而新的nginx进程在解析到reload参数后，就知道我们的目的是操纵nginx来从新加载配置文件了，它会向master进程发送信号，然后接下来的动作，就和我们直接向master进程发送信号一样了。
worker进程
而根本的网络事件，则是放在worker进程中来处置了。多个worker进程之间是对等的，他们平等竞争来自客户端的恳求，各进程互相之间是独立的。一个恳求只大概在一个worker进程中处置，一个worker进程不成能处置其它进程的恳求。worker进程的个数是可以设定的，一样我们会设定与机器cpu核数一致，这里面的缘由与nginx的进程模型乃至事件处置模型是分不开的。
worker进程之间是对等的，每个进程处置恳求的时机也是一样的。当我们供给80端口的http效劳时，一个连接恳求过来，每个进程都有大概处置这个连接，如何做到的呢？第一，每个worker进程都是从master进程fork过来，在master进程里面，先创立好需要listen的socket（listenfd）之后，然后再fork出多个worker进程。所有worker进程的listenfd会在新连接到来时变得可读，为包管只要一个进程处置该连接，所有worker进程在注册listenfd读事件前抢accept_mutex，抢到互斥锁的阿谁进程注册listenfd读事件，在读事件里调取accept接受该连接。当一个worker进程在accept这个连接之后，就开端读取恳求，解析恳求，处置恳求，发生数据后，再返回给客户端，最后才断开连接，这样一个完全的恳求就是这样的了。我们可以看到，一个恳求，完全由worker进程来处置，并且只在一个worker进程中处置。
worker进程工作流程
当一个 worker 进程在 accept() 这个连接之后，就开端读取恳求，解析恳求，处置恳求，发生数据后，再返回给客户端，最后才断开连接，一个完全的恳求。一个恳求完全由 worker 进程来处置，并且只能在一个 worker 进程中处置。
这样做带来的好处：
节约锁带来的开销。每个 worker 进程都是独立的进程，不同享资源，不需要加锁。同时在编程乃至问题查上时，也会利便许多。独立进程，减少风险。采纳独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，效劳不会中止，master 进程则很快从新启动新的 worker 进程。当然，worker 进程的也能发生不测退出。
多进程模型每个进程/线程只能处置一路IO，那么 Nginx是怎样处置多路IO呢？
假如不使用 IO 多路复用，那么在一个进程中，同时只能处置一个恳求，比方施行 accept()，假如没有连接过来，那么程序会堵塞在这里，直到有一个连接过来，才能连续向下施行。
而多路复用，同意我们只在事件发生时才将操纵返回给程序，而其他时候内核都挂起进程，随时待命。
中心：Nginx采纳的 IO多路复用模型epoll
例子： Nginx 会注册一个事件：“假如来自一个新客户端的连接恳求到来了，再通知我”，此后只要连接恳求到来，效劳器才会施行 accept() 来接收恳求。又比方向上游效劳器（比方 PHP-FPM）转发恳求，并等候恳求返回时，这个处置的 worker 不会在这堵塞，它会在发送完恳求后，注册一个事件：“假如缓冲区接收到数据了，告诉我一声，我再将它读进来”，于是进程就余暇下来等候事件发生。
以上就是为什么nginx很快？的具体内容，更多请关注百分百源码网其它相关文章！
