话不多说，先上图
Master-Worker模式
1、Nginx 在启动后，会有一个 master 进程和多个相互独立的 worker 进程。
2、接收来自外界的信号，向各worker进程发送信号，每个进程都有可能来处理这个连接。
3、Master进程能监控Worker进程的运行状态，当 worker 进程退出后(异常情况下)，会自动启动新的 worker 进程。
accept_mutex
由于所有子进程都继承了父进程的 sockfd，那么当连接进来时，所有子进程都将收到通知并“争着”与它建立连接，这就叫“惊群现象”。大量的进程被激活又挂起，只有一个进程可以accept() 到这个连接，这当然会消耗系统资源。Nginx 提供了一个 accept_mutex 这个东西，这是一个加在accept上的一把共享锁。即每个 worker 进程在执行 accept 之前都需要先获取锁，获取不到就放弃执行 accept()。有了这把锁之后，同一时刻，就只会有一个进程去 accpet()，这样就不会有惊群问题了。
当一个 worker 进程在 accept() 这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，完成一个完整的请求。一个请求，完全由 worker 进程来处理，而且只能在一个 worker 进程中处理。
用进程而不用线程的好处
1、节省锁带来的开销。每个 worker 进程都是独立的进程，不共享资源，不需要加锁。同时在编程以及问题查上时，也会方便很多。
2、独立进程，减少风险。采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master 进程则很快重新启动新的 worker 进程。当然，worker 进程的也能发生意外退出。
IO多路复用
对于Nginx来讲，一个进程只有一个主线程，那么它是怎么实现高并发的呢
采用了IO多路复用的原理，通过异步非阻塞的事件处理机制，epoll模型，实现了轻量级和高并发。 关于IO多路复用和epoll模型的详细解读，可以移步到我的这篇文章 => IO多路复用的三种机制Select，Poll，Epoll
nginx是如何具体实现的呢，简单来说：每进来一个request，会有一个worker进程去处理。但不是全程的处理，处理到什么程度呢？处理到可能发生阻塞的地方，比如向上游（后端）服务器转发request，并等待请求返回。那么，这个处理的worker不会这么傻等着，他会在发送完请求后，注册一个事件：“如果upstream返回了，告诉我一声，我再接着干”。于是他就休息去了。此时，如果再有request 进来，他就可以很快再按这种方式处理。而一旦上游服务器返回了，就会触发这个事件，worker才会来接手，这个request才会接着往下走。由于web server的工作性质决定了每个request的大部份生命都是在网络传输中，实际上花费在server机器上的时间片不多，这就是几个进程就能解决高并发的秘密所在。