同步异步 ——Nginx与Apache

同步异步,阻塞非阻塞 和nginx的IO模型

同步与异步

同步和异步关注的是消息通讯机制 (synchronous communication/ asynchronous communication)。所谓同步，就是在发出一个*调用*时，在没有获得结果以前，该*调用*就不返回。可是一旦调用返回，就获得返回值了。换句话说，就是由*调用者*主动等待这个*调用*的结果。而异步则是相反，*调用*在发出以后，这个调用就直接返回了，因此没有返回结果。换句话说，当一个异步过程调用发出后，调用者不会马上获得结果。而是在*调用*发出后，*被调用者*经过状态、通知来通知调用者，或经过回调函数处理这个调用。

典型的异步编程模型好比Node.js

举个通俗的例子：你打电话问书店老板有没有《分布式系统》这本书，若是是同步通讯机制，书店老板会说，你稍等，"我查一下"，而后开始查啊查，等查好了（多是5秒，也多是一天）告诉你结果（返回结果）。而异步通讯机制，书店老板直接告诉你我查一下啊，查好了打电话给你，而后直接挂电话了（不返回结果）。而后查好了，他会主动打电话给你。在这里老板经过"回电"这种方式来回调。

阻塞与非阻塞

阻塞和非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态.阻塞调用是指调用结果返回以前，当前线程会被挂起。调用线程只有在获得结果以后才会返回。非阻塞调用指在不能马上获得结果以前，该调用不会阻塞当前线程。

仍是上面的例子，你打电话问书店老板有没有《分布式系统》这本书，你若是是阻塞式调用，你会一直把本身"挂起"，直到获得这本书有没有的结果，若是是非阻塞式调用，你无论老板有没有告诉你，你本身先一边去玩了， 固然你也要偶尔过几分钟check一下老板有没有返回结果。在这里阻塞与非阻塞与是否同步异步无关。跟老板经过什么方式回答你结果无关。

I/O模型

因为进程是不可直接访问外部设备的，因此只能调用内核去调用外部的设备(上下文切换)，而后外部设备好比磁盘，读出存储在设备自身的数据传送给内核缓冲区，内核缓冲区在copy数据到用户进程的缓冲区。在外部设备响应的给到用户进程过程当中，包含了两个阶段；因为数据响应方式的不一样，因此就有了不一样的I/O模型。

通常有五种I/O模型：

阻塞式I/O模型：

默认状况下，全部套接字都是阻塞的。进程挂起，内核等待外部IO响应，IO完成传送数据到kernel buffer，数据再从buffer复制到用户的进程空间

非阻塞式I/O：

在内核请求IO设备响应指令发出后，数据就开始准备，在此期间用户进程没有阻塞，也就是没有挂起，它一值在询问或者check数据有没有传送到kernel buffer中，忙等…。可是第二个阶段（数据从kernel buffer复制到用户进程空间）依然是阻塞的。但这种IO模型会大量的占用CPU的时间，效率很低效，不多使用。

I/O多路复用（select，poll，epoll...）：

在内核请求IO设备响应指令发出后，数据就开始准备，在此期间用户进程是阻塞的。数据从kernel buffer复制到用户进程的过程也是阻塞的。可是和阻塞I/O所不一样的是，它能够同时阻塞多个I/O操做，并且能够同时对多个读操做，多个写操做的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操做函数，也就是说一个线程能够响应多个请求。

信号驱动式I/O（事件驱动）

第一阶段是非阻塞的，当数据传送的kernel buffer后，直接用信号的方式通知线程，用的很少

异步I/O:

在整个操做（包括将数据从内核拷贝到用户空间）完成后才通知用户进程

整个的汇总

Nginx中的epoll，poll，select

这三种模式都是属于IO复用模型。

select，poll是主动查询，它们能够同时查询多个fd（文件句柄）的状态，另外select有fd个数的限制，poll没有限制。select和poll不一样的是，他们建立的事件描述符不一样，select建立读、写、异常三个集合，而poll在一个集合内设定三种描述，因为select和poll每一个循环都会检查事件的发生，而poll的事件比较少，性能上比select要好一些；

epoll是基于回调函数的，无轮询。若是当套接字比较多的时候，每次select()都要经过遍历FD_SETSIZE个Socket来完成调度，无论哪一个Socket是活跃的，都遍历一遍。这会浪费不少CPU时间。若是能给套接字注册某个回调函数，当他们活跃时，自动完成相关操做，那就避免了轮询，这正是epoll(Linux)、kqueue(FreeBSD)、/dev/poll(soloris)作的。举个经典例子，假设你在大学读书，住的宿舍楼有不少间房间，你的朋友要来找你。select版宿管大妈就会带着你的朋友挨个房间去找，直到找到你为止。而epoll版宿管大妈会先记下每位同窗的房间号，你的朋友来时，只需告诉你的朋友你住在哪一个房间便可，不用亲自带着你的朋友满大楼找人。若是来了10000我的，都要找本身住这栋楼的同窗时，select版和epoll版宿管大妈，谁的效率更高，不言自明。同理，在高并发服务器中，轮询I/O是最耗时间的操做之一，select、epoll、/dev/poll的性能谁的性能更高，一样十分明了。

web通常请求流程

1. 首先咱们客户端发送一个请求到Web服务器，请求首先是到网卡。

2. 网卡将请求交由内核空间的内核处理，其实就是拆包了，发现请求的是80端口。

3. 内核便将请求发给了在用户空间的Web服务器，Web服务器解包发现客户端请求的index.html页面、

4. Web服务器便进行系统调用将请求发给内核

5. 内核发如今请求的是一页面，便调用磁盘的驱动程序，链接磁盘

6. 内核经过驱动调用磁盘取得的页面文件

7. 内核将取得的页面文件保存在本身的缓存区域中便通知Web进程或线程来取相应的页面文件

8. Web服务器经过系统调用将内核缓存中的页面文件复制到进程缓存区域中

9. Web服务器取得页面文件来响应用户，再次经过系统调用将页面文件发给内核

10. 内核进程页面文件的封装并经过网卡发送出去

11. 当报文到达网卡时经过网络响应给客户端

 

Apache和nginx比较：

因为web服务器是一对多的关系，一般完成并行处理的方式有多进程、多线程、异步三种方式。

多进程：多进程就是每一个进程对应一个链接来处理请求，进程独立响应本身的请求，一个进程挂了，并不会影响到其余的请求；并且设计简单，不会产生内存泄漏等问题，所以进程比较稳定。可是进程在建立的时候通常是fork机制，会存在内存复制的问题，另外在高并发的状况下，上下文切换将很频繁，这样将消耗不少的性能和时间。早期的apache使用的prework模型就多进程方式，可是apache会预先建立几个进程，等待用户的响应，请求完毕，进程也不会结束。所以性能上有优化不少。

多线程：每一个线程响应一个请求，因为线程之间共享进程的数据，因此线程的开销较小，性能就会提升。因为线程管理须要程序本身申请和释放内存，因此当存在内存等问题时，可能会运行很长时间才会暴露问题，因此在必定程度上还不是很稳定。apache的worker模式就是这种方式

异步的方式：nginx的epoll，apache的event也支持，很少说了

Nginx的IO模型是基于事件驱动的，使得应用程序在多个IO句柄间快速切换，实现所谓的异步IO。事件驱动服务器，最适合作的就是IO密集型工做，如反向代理，它在客户端与WEB服务器之间起一个数据中转做用，纯粹是IO操做，自身并不涉及到复杂计算。反向代理用事件驱动来作，显然更好，一个工做进程就能够run了，没有进程、线程管理的开销，CPU、内存消耗都小。

Apache这类应用服务器，通常要跑具体的业务应用，如科学计算、图形图像等。它们极可能是CPU密集型的服务，事件驱动并不合适。例如一个计算耗时2秒，那么这2秒就是彻底阻塞的，什么event都没用。想一想MySQL若是改为事件驱动会怎么样，一个大型的join或sort就会阻塞住全部客户端。这个时候多进程或线程就体现出优点，每一个进程各干各的事，互不阻塞和干扰。固然，现代CPU愈来愈快，单个计算阻塞的时间可能很小，但只要有阻塞，事件编程就毫无优点。因此进程、线程这类技术，并不会消失，而是与事件机制相辅相成，长期存在。