Nginx的工作原理
nginx在启动后，会有一个master进程和多个worker进程。master进程主要用来管理worker进程，包含：接收来自外界的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。而基本的网络事件，则是放在worker进程中来处理了。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致，这里面的原因与nginx的进程模型以及事件处理模型是分不开的。nginx的进程模型，可以由下图来表示：
在nginx启动后，如果我们要操作nginx，要怎么做呢？从上文中我们可以看到，master来管理worker进程，所以我们只需要与master进程通信就行了。master进程会接收来自外界发来的信号，再根据信号做不同的事情。所以我们要控制nginx，只需要通过kill向master进程发送信号就行了。比如kill -HUP pid，则是告诉nginx，从容地重启nginx，我们一般用这个信号来重启nginx，或重新加载配置，因为是从容地重启，因此服务是不中断的。master进程在接收到HUP信号后是怎么做的呢？首先master进程在接到信号后，会先重新加载配置文件，然后再启动新的worker进程，并向所有老的worker进程发送信号，告诉他们可以光荣退休了。新的worker在启动后，就开始接收新的请求，而老的worker在收到来自master的信号后，就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出。当然，直接给master进程发送信号，这是比较老的操作方式，nginx在0.8版本之后，引入了一系列命令行参数，来方便我们管理。比如，./nginx -s reload，就是来重启nginx，./nginx -s stop，就是来停止nginx的运行。如何做到的呢？我们还是拿reload来说，我们看到，执行命令时，我们是启动一个新的nginx进程，而新的nginx进程在解析到reload参数后，就知道我们的目的是控制nginx来重新加载配置文件了，它会向master进程发送信号，然后接下来的动作，就和我们直接向master进程发送信号一样了。
现在，我们知道了当我们在操作nginx的时候，nginx内部做了些什么事情，那么，worker进程又是如何处理请求的呢？我们前面有提到，worker进程之间是平等的，每个进程，处理请求的机会也是一样的。当我们提供80端口的http服务时，一个连接请求过来，每个进程都有可能处理这个连接，怎么做到的呢？首先，每个worker进程都是从master进程fork过来，在master进程里面，先建立好需要listen的socket（listenfd）之后，然后再fork出多个worker进程。所有worker进程的listenfd会在新连接到来时变得可读，为保证只有一个进程处理该连接，所有worker进程在注册listenfd读事件前抢accept_mutex，抢到互斥锁的那个进程注册listenfd读事件，在读事件里调用accept接受该连接。当一个worker进程在accept这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。我们可以看到，一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。
转自 http://tengine.taobao.org/book/chapter_02.html
Nginx安装
1.在线安装
$sudo apt-get install nginx
ubuntu安装Nginx之后的文件结构为：
所有的配置文件都在/etc/nginx下，并且每个虚拟主机已经安排在了/etc/nginx/sites-available下
启动程序文件在/usr/sbin/nginx
日志放在了/var/log/nginx中，分别是access.log和error.log
并已经在/etc/init.d/下创建了启动脚本nginx
默认的虚拟主机的目录设置在了/usr/share/nginx/www
启动使用$sudo /etc/init.d/nginx start。
2.源代码安装
为了方便后面的配置，还是使用源代码编译的方式安装，
nginx主要有三种版本：
Mainline version
Stable version
Legacy versions
一般来说，线上通常使用稳定版本。目前最新的稳定版本是nginx-1.8.0，
下载nginx-1.8.0.tar.gz，解压到合适的目录。
nginx依赖以下模块：
gzip模块需要 zlib 库
rewrite模块需要 pcre 库
ssl 功能需要openssl库
如果缺失上述模块，编译时会出错：
the HTTP rewrite module requires the PCRE library.
1.安装pcre
获取pcre编译安装包，在http://www.pcre.org/上可以获取当前最新的版本
解压缩pcre-xx.tar.gz包。
进入解压缩目录，执行./configure。
中间提示错误，
configure: error: You need a C++ compiler for C++ support.
解决sudo apt-get install build-essential。
make & make install
2.安装openssl
获取openssl编译安装包，在http://www.openssl.org/source/上可以获取当前最新的版本。
解压缩openssl-0.9.8zg.tar.gz包。
进入解压缩目录，执行./config。
make & make install
3.安装zlib
获取zlib编译安装包，在http://www.zlib.net/上可以获取当前最新的版本。
解压缩zlib-1.2.8.tar.gz包。
进入解压缩目录，执行./configure。
make & make install
接下来安装Nginx，
./configuremake
$make install
安装成功之后，nginx放置在/usr/local/nginx目录下，主要的配置文件为conf目录下的nginx.conf，
nginx的启动文件在sbin目录下的nginx文件。
若安装时找不到上述依赖模块，使用--with-openssl=<openssl_dir>、--with-pcre=<pcre_dir>、--with-zlib=<zlib_dir>指定依赖的模块目录。如已安装过，此处的路径为安装目录；若未安装，则此路径为编译安装包路径，nginx将执行模块的默认编译安装。
启动nginx之后，浏览器中输入http://localhost可以验证是否安装启动成功。
nginx与apache的区别
apache在处理用户请求时采用的是进程，若采用prefork的mpms机制，apache在每个时刻都要保持8个空闲的子进程，当用户请求过多时，开启的进程较多，占用内存大，效率与nginx相比较低，每秒最多的并发连接请求最多不超过3000个。但是apache有个优点就是非常稳定，当一个进程死掉时，不会影响其他的用户。而nginx在处理用户请求时采用的是线程，而线程是共享内存的，nginx只需要开启少量进程，多个线程就可以共享进程的内存，占用内存小，nginx采用的是epoll机制（事件主动通知机制）每秒最多的并发连接请求理论可以达到50000个。但是nginx的缺点是，稳定性差，当一个进程死掉时，会影响到多个用户的使用。
为什么Nginx的性能要比Apache高很多？
这得益于Nginx使用了最新的epoll（Linux 2.6内核）和kqueue（freebsd）网络I/O模型，而Apache则使用的是传统的select模型。
目前Linux下能够承受高并发访问的Squid、Memcached都采用的是epoll网络I/O模型。
处理大量的连接的读写，Apache所采用的select网络I/O模型非常低效。
下面用一个比喻来解析Apache采用的select模型和Nginx采用的epoll模型进行之间的区别：
假设你在大学读书，住的宿舍楼有很多间房间，你的朋友要来找你。
select版宿管大妈就会带着你的朋友挨个房间去找，直到找到你为止。
而epoll版宿管大妈会先记下每位同学的房间号，你的朋友来时，只需告诉你的朋友你住在哪个房间即可，不用亲自带着你的朋友满大楼找人。
如果来了10000个人，都要找自己住这栋楼的同学时，select版和epoll版宿管大妈，谁的效率更高，不言自明。
