nginx简介
Nginx (“engine x”) 是一个高性能的HTTP和 反向代理 服务器,也是一个 IMAP/POP3/SMTP 服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的,第一个公开版本0.1.0发布于2004年10月4日。其将源代码以类BSD许可证的形式发布,因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。2011年6月1日,nginx 1.0.4发布。
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,并在一个BSD-like 协议下发行。由俄罗斯的程序设计师Igor Sysoev所开发,供俄国大型的入口网站及搜索引擎Rambler(俄文:Рамблер)使用。其特点是占有内存少,并发能力强,事实上nginx的并发能力确实在同类型的网页服务器中表现较好,中国大陆使用nginx网站用户有:淘宝、百度、新浪、网易、腾讯等。
nginx应用场景
1、http服务器。Nginx是一个http服务可以独立提供http服务。可以做网页静态服务器。
2、虚拟主机。可以实现在一台服务器虚拟出多个网站,例如个人网站使用的虚拟机。
3、反向代理,负载均衡。当网站的访问量达到一定程度后,单台服务器不能满足用户的请求时,需要用多台服务器集群可以使用nginx做反向代理。并且堕胎服务器可以平均分担负载,不会应为某台服务器负载高宕机而某台服务器闲置的情况。
nginx七层load balance结构图:
nginx的主要特点
- 高并发连接: 官方称单节点支持5万并发连接数,实际生产环境能够承受2-3万并发。
- 内存消耗少: 在3万并发连接下,开启10个nginx进程仅消耗150M内存 (15M*10=150M)
- 配置简单
- 成本低廉: 开源免费
- 支持rewrite重写规则: 能够根据域名、url的不同,将http请求分发到后端不同的应用服务器节点上
- 内置健康检查功能: 如果后端的某台应用节点挂了,请求不会再转发给这个节点,不影响线上功能
- 节省带宽: 支持gzip压缩
- 反向代理: 支持分布式部署环境,消除单点故障,支持7 * 24小时不停机发布 # nginx原理(Unix I/O模型简介)
阻塞(blocking) 非阻塞(nonblocking ) 同步(synchronous ) 阻塞I/O(blocking I/O)I/O多路复用 非阻塞I/O(nonblocking I/O)信号驱动 异步(asynchronous ) 异步I/O ## 基本概念 I/O涉及的对象: 应用程序进程(简称进程) 操作系统内核(简称内核) I/O经历的过程(以读操作为例): 等待数据准备(简称准备过程) 将数据从内核拷贝到进程(简称拷贝过程) 阻塞:进程在准备过程中阻塞地等待 非阻塞:进程在准备过程中不会阻塞 同步:进程在拷贝过程中需要阻塞等待 异步:进程在拷贝过程中不需要阻塞等待 ## 同步阻塞I/O ### 阻塞I/O 最常见也是默认情况下我们会使用的,进程发起read操作后,进程阻塞等待数据准备就绪,进程阻塞等待内核将数据拷贝到进程中。 ### I/O多路复用 所谓的select、epoll,又叫事件驱动I/O。在java中叫nio,进程发起一个或多个socket的read请求后:用select/epoll方法阻塞等待数据就绪,一旦有至少一个就绪,进程阻塞等待内核拷贝数据到进程中。处理单个连接并不比阻塞I/O快。好处在于可以提高并发性,一个线程可同时处理多个连接。 ## 同步非阻塞I/O ### 非阻塞I/O 进程发起read操作后
- 进程无需阻塞等待数据准备就绪,若未就绪立即返回err
- 进程过一段时间后再次发起read操作,询问是否准备就绪
- 若已经准备就绪,则进程阻塞等待内核将数据拷贝到进程中 ### 信号驱动I/O 进程发起read操作时,注册信号handler
- 进程无需阻塞等待数据准备就绪
- 数据就绪后内核通过信号通知进程,并调用进程注册的信号handler
- 进程阻塞等待数据拷贝 ### 异步非阻塞I/O 进程发起read操作,将socket和接收数据的buffer传递给内核后:
- 无需阻塞等待数据准备就绪
- 数据就绪后也无需阻塞等待内核拷贝数据
- 内核拷贝数据完成后发送信号通知进程数据已经可用
nginx 如何保证强大的并发能力
nginx使用epoll(linux2.6内核)和kqueue(freebsd)网络模型,而apache使用传统的select模型
epoll 与 select都是 I/O 多路复用
epoll是当前在Linux下开发大规模并发网络程序的热门选择。
select模型与epoll模型的对比
select模型的缺点
- 最大并发数限制,因为一个进程所打开的FD(文件描述符)是有限制的,由FD_SETSIZE设置,默认值是1024/2048,因此Select模型的最大并发数就被相应限制了。自己改改这个FD_SETSIZE?想法虽好,可是先看看下面吧…
- 效率问题,select每次调用都会线性扫描全部的FD集合,这样效率就会呈现线性下降,把FD_SETSIZE改大的后果就是,大家都慢慢来,什么?都超时了。
- 内核/用户空间 内存拷贝问题,如何让内核把FD消息通知给用户空间呢?在这个问题上select采取了内存拷贝方法。
注:从上面看,select和epoll都需要在返回后,通过遍历文件描述符来获取就绪的socket。事实上,同时连接的大量客户端在同一时刻只有很少处于就绪状态,因此随着监视的文件数量增长,其效率也会呈现线性下降。
epoll 模型的优点:
- 相对于select和poll来说,epoll更加灵活,没有描述符限制(它所支持的FD上限是最大可以打开文件的数目,这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右,具体数目可以cat/proc/sys/fs/file-max察看)。epoll使用一个文件描述符管理多个描述符,将用户关系的文件描述符的事件存放到内核的一个事件表中,这样在用户空间和内核空间的copy只需一次。
- IO的效率不会随着监视fd的数量的增长而下降。epoll不同于select和poll轮询的方式,而是通过每个fd定义的回调函数来实现的。只有就绪的fd才会执行回调函数。
- 内存拷贝,Epoll在这点上使用了“共享内存”,这个内存拷贝也省略了。 注:Epoll不仅会告诉应用程序有I/O事件到来,还会告诉应用程序相关的信息,根据这些信息应用程序就能直接定位到事件,而不必遍历整个FD集合 # nginx配置实例 ## 反向代理
user nobody nobody; worker_processes 2; // 与CPU数目一致 error_log /var/log/nginx/nginx_error.log crit; // 错误日志 pid /usr/local/nginx/nginx.pid events { use epoll; // 使用epoll模型 worker_connections 1024; } http{ upstream WB { // 负载均衡配置,可以配置多个 ip_hash; // 设置负载均衡策略为ip_hash,会根据请求来源ip做hash,同一个C类地址网段hash值相同 server 192.168.4.1:8080; // 反向代理到后台应用服务器节点上 server 192.168.4.2:8080; } server { location / { proxy_connect_timeout 3; proxy_send_timeout 30; proxy_read_timeout 30; proxy_pass http://WB/; // 配置所有请求都会分发到 WB 这个负载均衡器上 expires 1d; } }
https
server { listen 443; ssl on; ssl_certificate /usr/local/nginx/server.crt; ssl_certificate_key /usr/local/nginx/server.key; error_page 497 https://$host$uri?$args; }
缓存静态化文件
server { location ~* \.(gif|jpg|jpeg|png|css|js|ico|html)$ { root /usr/local/nginx/html/; expires 3d; } }
参考:nginx.org/