NGINX工作模型

一、两种工作模式

1、SINGLE模式，该模型只有一个工作进程，不适合在生产环境中使用

2、MASTER－WORKER模式，该模型由一个MASTER进程和N个WORKER进程构成，生产环境中主要使用该模型

MASTER进程：负责接收外部请求，以及分发工作给WORKER时程

WORKER进程：负责完成真正的劳动工作

二、事件模型

Nginx支持如下处理连接的方法(I/O复用方法)，这些方法可以通过use指令指定。

select – 标准方法。 如果当前平台没有更有效的方法，它是编译时默认的方法。你可以使用配置参数 –with-select_module 和 –without-select_module 来启用或禁用这个模块。

poll – 标准方法。 如果当前平台没有更有效的方法，它是编译时默认的方法。你可以使用配置参数 –with-poll_module 和 –without-poll_module 来启用或禁用这个模块。

kqueue – 高效的方法，使用于 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用双处理器的MacOS X系统使用kqueue可能会造成内核崩溃。

epoll – 高效的方法，使用于Linux内核2.6版本及以后的系统。在某些发行版本中，如SuSE 8.2, 有让2.4版本的内核支持epoll的补丁。

rtsig – 可执行的实时信号，使用于Linux内核版本2.2.19以后的系统。默认情况下整个系统中不能出现大于1024个POSIX实时(排队)信号。这种情况对于高负载的服务器来说是低效的；所以有必要通过调节内核参数 /proc/sys/kernel/rtsig-max 来增加队列的大小。

可是从Linux内核版本2.6.6-mm2开始， 这个参数就不再使用了，并且对于每个进程有一个独立的信号队列，这个队列的大小可以用 RLIMIT_SIGPENDING 参数调节。当这个队列过于拥塞，nginx就放弃它并且开始使用 poll 方法来处理连接直到恢复正常。

/dev/poll – 高效的方法，使用于 Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+.

eventport – 高效的方法，使用于 Solaris 10. 为了防止出现内核崩溃的问题， 有必要安装这个安全补丁。　　

在linux下面，只有epoll是高效的方法。　　

三、Epoll VS Select

epoll和select事件模型是在NGINX中被应用的比较广的两种模型，在2.6内核后，epoll基本上完全取代了select模型

Epoll是Linux内核为处理大批量句柄而作了改进的poll。要使用epoll只需要这三个系统调用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。

 工作模式单进程最大文件数IO效率MMAPEPOLL通过epoll_ctl()注册一个文件描述符，一旦某个文件描述符就绪时
内核会采用类似call back的回调机制，迅速激活这个文件描述符，epoll_wait()便会得到通知
通俗理解，基于响应的理论上讲无限大
跟系统内存有关
可以cat /proc/sys/fs/file-max查看不随FD数目增加而线性下降支持SELECT进程只有在调用一定的方法后，内核才会对所有监视的文件描述符进行扫描
通俗理解，基于轮询的默认2048
由系统FD_SETSIZE设置随FD数目增加而线性下降不支持