1. 对常用I/O模型进行比较说明
五种常用I/O模型分别为：阻塞型、非阻塞型、复用型、信号驱动型、异步
1.1阻塞型 I/O 模型（blocking IO）：阻塞IO模型是最简单的I/O模型，用户线程在内核进行IO操作时被阻塞
优点：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源
缺点：每个连接需要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销较大，apache 的preforck使用的是这种模式。
1.2非阻塞型 I/O 模型 (nonblocking IO)
机制：用户线程发起IO请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起IO请求，直到数据到达后，才真正读取到数据，继续执行。
缺点：即 “轮询”机制存在两个问题：如果有大量文件描述符都要等，那么就得一个一个的read。这会带来大量的Context Switch（read是系统调用，每调用一次就得在用户态和核心态切换一次）。轮询的时间不好把握。这里是要猜多久之后数据才能到。等待时间设的太长，程序响应延迟就过大;设的太短，就会造成过于频繁的重试，干耗CPU而已，是比较浪费CPU的方式。
由于上述的机制和缺点因此一般很少直接使用这种模型，而是在其他IO模型中使用非阻塞IO这一特性。
1.3多路复用 I/O 型(I/O multiplexing)
I/O multiplexing 主要包括:select，poll，epoll三种系统调用，select/poll/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。
优点：可以基于一个阻塞对象，同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述符一个线程)，这样可以大大节省系统资源
缺点：当连接数较少时效率相比多线程+阻塞 I/O 模型效率较低，可能延迟更大，因为单个连接处理需要 2 次系统调用，占用时间会有增加
1.4信号驱动式 I/O 模型 (signal-driven IO)
机制：信号驱动I/O的意思就是进程现在不用傻等着，也不用去轮询。而是让内核在数据就绪时，发送信号通知进程。
优点：等待数据报到达期间进程不被阻塞。用户主程序可以继续执行，只要等待来自信号处理函数的通知。
缺点：信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知
1.5异步 I/O 模型 (asynchronous IO)
优点：异步 I/O 能够充分利用 DMA 特性，让 I/O 操作与计算重叠
缺点：要实现真正的异步 I/O，操作系统需要做大量的工作。目前 Windows 下通过 IOCP 实现了真正的异步 I/O，在 Linux 系统下，Linux 2.6才引入，目前 AIO 并不完善，因此在 Linux 下实现高并发网络编程时以 IO 复用模型模式+多线程任务的架构基本可以满足需求
Linux提供了AIO库函数实现异步，但是用的很少。目前有很多开源的异步IO库，例如libevent、libev、libuv。
五种 IO 对比
这五种 I/O 模型中，越往后，阻塞越少，理论上效率也是最优前四种属于同步 I/O，因为其中真正的 I/O操作(recvfrom)将阻塞进程/线程，只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配 
2. nginx中的模块分类及常见核心模块有哪些
Nginx是免费的、开源的、高性能的HTTP和反向代理服务器、邮件代理服务器以及TCP/UDP代理服务器，它具有以下特性：模块化设计，较好的扩展性；高可靠性；支持热部署，不停机更新配置文件，升级版本，更换日志文件；低内存消耗，10000个keep-alive连接模式下的非活动连接仅需2.5M内存；event-driven、aio、mmap和sendfile等。
Nginx模块分类
Nginx有多种模块，按功能划分包括以下五种：
2.1 核心模块
核心模块是Nginx服务器正常运行必不可少的模块，提供错误日志记录 、配置文件解析 、事件驱动机制 、进程管理等核心功能。
2.2 标准HTTP模块
标准HTTP模块提供HTTP协议解析相关的功能，比如： 端口配置 、 网页编码设置 、 HTTP响应头设置等。
2.3 可选HTTP模块
可选HTTP模块主要用于扩展标准的 HTTP 功能，让Nginx能处理一些特殊的服务，比如：Flash多媒体传输 、解析GeoIP请求、 网络传输压缩 、 安全协议SSL支持等。
2.4 邮件服务模块
邮件服务模块主要用于支持 Nginx 的邮件服务，包括对POP3协议、IMAP 协议和SMTP协议的支持。
2.5 Stream服务模块
Stream服务模块用于实现反向代理功能，包括TCP协议代理。
2.6 第三方模块
第三方模块是为了扩展Nginx服务器应用，完成开发者自定义功能，比如：Json支持、Lua支持等。
从Nginx模块图可以看出，常见的核心模块有ngx_core、ngx_errlog、ngx_conf、ngx_events、ngx_poll和ngx_regex。
3. 描述nginx中worker_processes、worker_cpu_affinity、worker_rlimit_nofile、worker_connections配置项的含义
Nginx配置文件由主配置文件（nginx.conf）、子配置文件（包括conf.d/*.conf）、协议（fastcgi、uwsgi、scgi 等）相关的配置文件和mime.types四部分组成，Nginx配置文件需遵循以下格式要求：
1、配置文件由指令与指令块构成； 2、每条指令以;分号结尾，指令与值之间以空格符号分隔； 3、可以将多条指令放在同一行，用分号分隔即可，但可读性差，不推荐此种方式； 4、指令块以{ }大括号将多条指令组织在一起,且可以嵌套指令块； 5、include语句允许组合多个配置文件以提升可维护性； 6、使用#符号添加注释，提高可读性； 7、使用$符号使用变量； 8、部分指令的参数支持正则表达式。
3.1 worker_processes
worker_processes记录启动Nginx工作进程的数量，一般设为和CPU核心数相同。例如笔者这边用于实验的CentOS8虚拟机是2核的，通过yum安装的Nginx服务在开启后，配置文件中worker_processes部分显示的是auto（部分版本可能会默认设为1），即默认与虚拟机CPU核数相同，查看进程部分，也是显示两个工作进程。 通常情况下，Nginx的进程数设为1已经够用，但如果涉及到ssl、gzip等比较消耗CPU的工作，可以适当调大worker_processes值来提高IO性能，一般为CPU核数的1-2倍。
3.2 worker_cpu_affinity
worker_cpu_affinity这一配置项可以将Nginx工作进程绑定到指定的CPU核心上。默认Nginx是不进行进程绑定的，绑定并不是意味着当前nginx进程独占以一核心CPU，但是可以保证此进程不会运行在其他核心上，这就极大减少了nginx的工作进程在不同的cpu核心上的来回跳转，减少了CPU对进程的资源分配与回收以及内存管理等，因此可以有效的提升nginx服务器的性能。
例如笔者在worker_processes值为auto的情况下查看工作进程绑定情况，虽是都在0号CPU上，但是是不稳定的，进程仍有可能跳转到其他CPU核心上，此时可以在配置文件中添加“worker_cpu_affinity”一行，后面跟上不同的CPU核心编号，则是按序将进程绑定的对应CPU核心上工作。
2.3 worker_rlimit_nofile
worker_rlimit_nofile这一配置项规定了所有worker进程能打开的文件数量上限，包括Nginx的所有连接（例如与代理服务器的连接等），而不仅仅是与客户端的连接，另一个考虑因素是实际的并发连接数不能超过系统级别的最大打开文件数的限制，最好与ulimit -n或者limits.conf的值保持一致。
系统中默认的最大打开文件数为1024，实际生产中基本是不够用的，可以根据需求改大，例如将Nginx服务的最大文件打开数改成65536，系统级别的改为100000，但此种方法只是临时调整最大打开文件数，重启后会失效。
如果想保证重启后不失效，还需修改PAM模块，在/etc/security/limits.conf添加相关信息。
2.4 worker_connections
worker_connections用于设置单个工作进程的最大并发连接数，作为web服务器的时候最大并发数为worker_connections * worker_processes，作为反向代理的时候为(worker_connections * worker_processes)/2。此外要注意的是，最大并发连接数不能超过worker_rlimit_nofile部分设置的上限值，生产中需根据实际对该部分以及worker_rlimit_nofile上限值或worker_processes值进行调整。