Nginx的火速蔓延与其并发性处理优势

单线程服务器设计原理
服务器君一共花费了215.338 ms进行了5次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

Nginx是俄罗斯人编写的十分轻量级的HTTP服务器。Nginx,它的发音为“engine X”, 是一个高性能的HTTP和反向代理服务器,同时也是一个IMAP/POP3/SMTP 代理服务器.Nginx是由俄罗斯人 Igor Sysoev为俄罗斯访问量第二的 Rambler.ru站点开发的,它已经在该站点运行超过两年半了。Igor Sysoev在建立的项目时,使用基于BSD许可。

Nginx以事件驱动的方式编写,所以有非常好的性能,同时也是一个非常高效的反向代理、负载平衡。其拥有匹配 Lighttpd的性能,同时还没有Lighttpd的内存泄漏问题,而且Lighttpd的mod_proxy也有一些问题并且很久没有更新。

Nginx做为HTTP服务器,有以下几项基本特性:

  • 处理静态文件,索引文件以及自动索引,打开文件描述符缓冲。
  • 无缓存的反向代理加速,简单的负载均衡和容错。
  • FastCGI,简单的负载均衡和容错。
  • 模块化的结构。包括gzipping, byte ranges, chunked responses,以及 SSI-filter等filter。如果由FastCGI或其它代理服务器处理单页中存在的多个SSI,则这项处理可以并行运行,而不需要相互等待。
  • 支持SSL 和 TLSSNI。

Nginx专为性能优化而开发,性能是其最重要的考量,实现上非常注重效率 。它支持内核Poll模型,能经受高负载的考验,有报告表明能支持高达 50,000个并发连接数。

Nginx现在正在以光的速度蔓延开来,它以其稳定性和高性能等众多优点迅速扩大市场,大家都知道,Nginx是以单线程为基础的,那么他怎么能在并发性上取得优势的呢?会不会因为网络阻塞而导致主线程阻塞呢?下面就相关问题作一些概念性的阐述。

问题的根本在于人们对于计算机处理性能还没有足够的认识,以及普通的服务器架构简化的处理,做过大型的成熟服务器的人可能都知道,解决一个系统瓶颈比优化 1000个算法还重要,这也就是木桶效应,一个桶能盛水的多少决定于最短的那一块板,我们之所以在一般的服务器端应用软件中采用一个连接一个线程甚至阻塞在一个线程上的做法,并不是这个方法是最优秀的,设计者没有更好的方法,而是因为这种套路是最简单的,在概念上以及操作上都比较容易让人理解,并且容错性也强,但是对于性能要求极高的服务器比如dns或者负载均衡等等,要求处理速度极快,并且能有较高的并发性,这种简单的线程池加连接池的做法就不能解决问 题了,比如一个index页面请求,他会包含几十个附属资源文件,如果cilent网络比较慢,那么就会较长时间的阻塞这几十个连接,用户稍微一多服务器就受不了,因为线程的开销是很大的,如果不能得到迅速释放,将会给服务器带来灾难性的后果,对于公网服务,这种之后会尤为明显,很显然,让服务器为客户端的网速买单是愚蠢的做法。

那么既然多线程都会存在这样的问题,单线程怎么会逃脱的掉呢?解决问题的关键在于异步IO,windows上有IOCP(完成端口,对于一部IO包装的比较 多,内部实现时用cpu个数的线程进行事件处理,他会通知你你给定的异步读写已经完成了),linux上有epool(一个纯事件通知接口,他会通知你可以读或者可以写了),如果将所有的请求简化为阻塞操作和非阻塞操作问题就简单了,所有需要阻塞请求的部分全部由epool触发相应事件,非阻塞(处理耗时很短)部分用主线程一直执行,直到遇到阻塞部分就停止,交由阻塞部分监听异步完成事件,这样就构成了事件驱动模型。

这里比较容易迷惑人的地方是很多人认为函数的处理会阻塞主线程,其实还是上面说的木桶效应,他是不是那块最短的木板,这是需要由测试和经验来决定的,事实是它的处理时间占用很短,做100万次for循环说不定比局域网经过一次网络访问的时间还要短,理解了这点就不难理解了,如果说你的服务器每秒钟能处理1 万个请求,那么在处理功能函数上(比如解析协议,操作、输出等等)顶多也就占用0.1-0.3秒,剩下的时间都是耗时在了网络阻塞上,耗时在了事件发生上了,既然如此,把操作部分独立分出来用多线程执行又有什么意义呢?对于公网就更不用说了,网络等IO阻塞才是影响服务器的主要因素,是那块短了的板。

对于网络的IO,IOCP 、epool等事件通知机制就解决了这个问题,性能上由于是阻塞的,所以还不如直接accept等快,但是对于网络延时很严重的情况下性能反而显得更好, 因为他们可以处理大量的连接而不使性能下降很厉害,如果值直接阻塞能连接处理1000个的话,epool等就可以同时处理3-5万个,所以实际的应用价值 要大得多。

剩下的部分就是处理事件发生后的事情上面,我前面的文章已经作了说明,在此不再重复,nginx 、lighttpd等都是基于这类模型开发的,有兴趣的可以研究一下它的代码。

本文地址:http://www.nowamagic.net/librarys/veda/detail/880,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/880

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《编程之美:微软技术面试心得》 《编程之美》小组 (作者)

《编程之美:微软技术面试心得》是一本让人着迷的书!阅读起来。有些题目的内容会引起强烈的共鸣,尤其是那些自己非常熟悉并且又深知解答的题目;也有一些题目让我异常惊诧,原来除了我所知道的解答思路之外,还有更好的解答以及更深层次的原因。还有一些题目是从来没想到过的。阅读过程是一次愉快的享受,也是脑细胞持续活跃的过程。

更多计算机宝库...