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模型的缺点

1. 最大并发数限制，因为一个进程所打开的FD（文件描述符）是有限制的，由FD_SETSIZE设置，默认值是1024/2048，因此Select模型的最大并发数就被相应限制了。自己改改这个FD_SETSIZE？想法虽好，可是先看看下面吧…
2. 效率问题，select每次调用都会线性扫描全部的FD集合，这样效率就会呈现线性下降，把FD_SETSIZE改大的后果就是，大家都慢慢来，什么？都超时了。
3. 内核/用户空间 内存拷贝问题，如何让内核把FD消息通知给用户空间呢？在这个问题上select采取了内存拷贝方法。

注：从上面看，select和epoll都需要在返回后，通过遍历文件描述符来获取就绪的socket。事实上，同时连接的大量客户端在同一时刻只有很少处于就绪状态，因此随着监视的文件数量增长，其效率也会呈现线性下降。

epoll 模型的优点：

1. 相对于select和poll来说，epoll更加灵活，没有描述符限制(它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat/proc/sys/fs/file-max察看)。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。
2. IO的效率不会随着监视fd的数量的增长而下降。epoll不同于select和poll轮询的方式，而是通过每个fd定义的回调函数来实现的。只有就绪的fd才会执行回调函数。
3. 内存拷贝，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;
}
}

参考：http://nginx.org/