NGINX是一个免费的，开源的，高性能的HTTP服务器和反向代理，以及IMAP / POP3代理服务器。NGINX以其高性能，稳定性，丰富的功能集，简单的配置和低资源消耗而闻名，也是为解决C10K问题而编写的服务器之一。本文主要介绍Nginx的架构及工作流程。
一、Nginx的架构如下图
1.nginx启动后会有一个master进程和多个worker进程（woeker进程数量可配置，一般设置与机器的核心数一致），master进程负责管理worker进程（接收外界信号，发送信号到各worker进程，监控worker进程的运行状态）。
2.基本的网络事件，由worker进程负责处理，各worker进程之间是对等和相互独立的，共同竞争来至客户端的请求。
3.nginx是基于多进程模式、事件驱动的异步非阻塞IO模型。
二、nginx多进程+异步非阻塞IO模型的优点
1.进程之间相互独立，一个进程异常，其他进程不会受到影响，能够继续服务，保证服务的稳定性。
2.独立进程之间资源隔离，避免了很多不必要的锁操作，提高程序处理效率。
3.避免了多线程模型下常见的上下文切换问题，虽然多进程模型会导致服务并发数降低，但异步非阻塞IO解决了这个问题。
三、多进程间如何协作
1.多进程工作可能会产生的‘惊群效应’问题
多进程工作模式如下图：
一个连接进来，每个worker进程都有可能处理这个连接，怎么做到的呢？首先每个worker进程都由master进程fork过来，在master进程里面，先建立好需要listen的socket之后，再fork出多个worker进程，这样每个worker进程都可以accept这个socket（注意：不是同一个socket,仅仅是每个进程获取的socket连接来源于同一个ip地址和端口），所以，一个请求进来后，所有accept在这个socket上的worker都会收到通知，但是只有一个worker成功接收到请求并处理，其他worker都会接收失败，这就是‘惊群效应’。
另外，这种工作模式也会引发另外一个问题，那就是‘worker间负载不均衡’！多个worker同时争抢请求任务，如果有的worker进程比较勤快，而且运气也比较好，那么其他进程可能就很少有干活机会，而这些勤快的进程却很忙碌，从而降低服务器的并发和性能。那么Nginx是怎么解决这两个问题的呢？
2.Nginx中worker间协作问题解决方案
将epoll产生的ngx_posted_accept_events(accept事件)放入accept队列，普通事件ngx_posted_events（read事件）放入posted队列，worker进程都从accept队列获取连接事件，从posted队列获取每个worker自己的事件进行处理。
a.在从accept队列获取连接事件时，需要先获取锁（accept_mutex锁），只有获取锁的进程可以从accept队列中取连接事件，从而避免了‘惊群效应’。
b.上述抢占锁的判断是根据worker进程负载阈值的判断值（处理的连接总数有没有达到总连接数<worker_connections>的7/8，没有达到时不会抢锁，直接取事件，达到时需要先拿到锁再获取事件），从而解决了worker间负载不均衡的问题。