共计 2619 个字符，预计需要花费 7 分钟才能阅读完成。
===== 实现并行处理申请的三种形式 =====
1、多过程形式（apache）
服务器接管到一个客户端，主过程生成一个子过程和客户端建设连贯，进行交互。连贯断开，子过程完结
长处：设计实现简略，子过程之间互相独立，解决申请过程中彼此不受烦扰。某个子过程产生问题时，不容易影响到其余过程，保障了服务的稳定性。退出时，占用资源会被零碎回收，也不会留下任何垃圾。
毛病：操作系统产生一个子过程，须要进行内存复制等操作，资源和工夫上会产生额定开销。web 服务器接管到大量申请时，会对系统资源造成压力，导致系统性能降落
2、多线程形式（IIS）
服务器接管到一个客户端时，会由服务器主过程派生一个线程进去和该客户端进行交互
长处：操作系统产生线程的开销远远小于产生一个过程的开销，很大水平上加重了 Web 服务器对系统资源的要求。应用线程进行任务调度，开发方面遵行肯定规范，相对来说比拟标准和有利于合作
毛病：多个线程位于同一个过程，能够拜访同样的内存空间，彼此之间相互影响。同时，开发过程中不可避免的要由开发者本人对内存进行治理，减少了出错的危险，积小成多，可能最终对整个服务器产生重大影响。
3、异步形式（Nginx：异步非阻塞）
同步和异步时形容通信模式的概念
同步：发送方发送申请后，须要期待接管方发回响应后，才接着发送下个申请
异步：发送方发送申请后，不期待接管方发回响应，持续发送下个申请
阻塞和非阻塞时形容过程解决调用的形式，网络通信中，次要指网络套接字 Socket 的阻塞和非阻塞形式，而 Socket 的理论就是 I / O 操作
阻塞：调用后果返回前，之前线程从运行状态被挂起，等到调用后果返回后，才进入就绪状态，获取 CPU 继续执行（接管方）
非阻塞：调用后果不能立即返回，以后线程也不会被挂起，立刻返回执行下一个调用。（接管方）
=====nginx 如何解决申请 =====
worker_process(异步非阻塞)master process worker_process(异步非阻塞)
worker_process(异步非阻塞)
工作过程接管到客户端申请后，调用 I / O 进行解决，如果不能立刻失去后果，就去解决其余申请。客户端在此期间也无需期待响应，能够去解决其余事件。当 I / O 调用返回后果时，就会告诉此工作过程。该工作过程失去告诉，临时挂起以后解决的事务，去响应客户端的申请。
=====nginx 事件处理机制 =====
I/ O 调用把本人的状态告诉给工作过程的两种形式：
1、工作过程在进行其余工作的过程中隔一段时间就去检查一下 I / O 运行状态，如果实现就去响应客户端，如果未实现，就持续正在进行的工作
2、I/ O 调用在实现后被动告诉工作过程。select/poll/epoll/kqueque 等这样的零碎调用就是用来反对这种形式。这些零碎调用，也常被称为事件驱动模型。
=====nginx 事件驱动模型 =====
Nginx 服务器响应和解决 Web 申请的过程，就是基于事件驱动模型的，蕴含事件收集器，事件发送器，事件处理器等三局部根本单元。重点介绍一下事件处理器，咱们在编写服务器解决模型程序时，基于事件驱动模型，指标对象中的事件处理器能够有以下几种实现办法：
1、事件发送器每传递过去一个申请，指标对象就创立一个新的过程，调用事件处理器来解决该申请。
--实现起来简略，但创立新的过程开销比拟大，导致服务器性能差
2、事件发送器每传递过去一个申请，指标对象就创立一个新的线程，调用事件处理器来解决该申请。
--波及到线程同步，可能会面临死锁、同步等一系列问题，编码比较复杂
3、事件发送器每传递过去一个申请，指标对象就将其放入一个待处理事件列表，应用非阻塞 I / O 形式调用事件处理器来解决该申请
--编码和逻辑都比后面两种简单，但大多网络服务器都采纳此形式，逐步造成了所谓的“事件驱动解决库”。事件驱动解决库又被称为多路 IO 复用办法，最常见是以下三种：select 模型，poll 模型，epoll 模型。另外，还反对其余模型。
select 库
Linux 和 Windows 平台都反对的根本事件驱动模型库。创立关注事件的描述符汇合。对一个描述符关注读事件、写事件以及异样事件，要创立三类事件描述符汇合。调用底层提供的 select() 函数，等待时间产生（select 的阻塞与是否设置非阻塞 I / O 没有关系），轮询所有事件描述符汇合中的每一个事件描述符，查看是否有相应事件产生，如果有，就进行解决
poll 库
Linux 平台的根本事件驱动模型，Windows 不反对。与 select 库根本工作形式雷同，都是创立一个关注事件的描述符汇合，再去期待这些事件产生，如何再轮询描述符汇合，查看有没有工夫产生，有就解决。
区别在于，select 库创立了 3 个描述符汇合，须要别离轮询这 3 个汇合。poll 库只须要创立一个汇合，每个描述符对应的构造上别离设置读、写、异样事件。最初轮询的时候，能够同时查看这 3 种事件是否产生，是 select 库的优化实现
epoll 库
Nginx 服务器反对的高性能事件驱动库之一，公认的十分优良事件驱动模型，和 poll，select 有很大的不同。
以上的两个库，在描述符表多的利用中，效率显得比拟低下。好的做法是，把描述符列表的治理交给内核负责，一旦有某种事件产生，内核把产生事件的描述符列表告诉给过程，防止轮询整个描述符列表，epoll 库就是这种模型。
epoll 库通过相干调用告诉内核创立一个有 N 个描述符的事件列表；而后，给这些描述符设置所关注的事件，并把它增加到内核事件列表中去，在具体的编码过程中也能够通过相干调用对事件列表中的描述符进行批改和删除。实现设置后，epoll 库就开始期待内核告诉事件产生。某一事件产生后，内核将产生事件的描述符列表上报给 epoll 库。失去事件列表的 epoll 库，就能够进行事件处理了。
=====nginx 服务器架构 =====
nginx 服务器的构造大抵分为主过程、工作过程、后端服务器和缓存等局部。
nginx 服务器的三大类过程：主过程、工作过程、缓存索引重建及治理过程
服务启动后，产生一个 master process，主过程执行一系列工作后产生一个或者多个 worker processes。
主过程次要进行 nginx 配置文件解析、数据结构初始化、模块配置和注册、信号处理、网络监听生成、工作过程生成和治理等工作。
工作过程次要进行过程初始化、模块调用和申请解决等工作，是 nginx 服务器提供服务的主体