为什么80%的码农都做不了架构师？>>> 
nginx配置文件
location ~ .*\.(php|php5)?$
{
#fastcgi_pass unix:/tmp/php-cgi.sock;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi.conf;
}以上配置是处理.php结尾的文件，也就是php文件。意思是所有以.php为结尾的文件，都送到本机9000端口由php-cgi来处理。
Nginx的模块有三种角色：
* handlers 处理http请求并构造输出
* filters 处理handler产生的输出
* load-balancers 当有多于一个的后端服务器时，选择一台将http请求发送过去
一个handler有三种返回方式：正常；错误；放弃处理转由默认的handler来处理（典型地如处理静态文件的时候）。
如果handler的作用是把请求反向代理到后端服务器，那么就是刚才说的模块的第三种角色load-balancer了。load-balancer主 要是负责决定将请求发送给哪个后端服务器。Nginx目前支持两种load-balancer模块：round-robin（轮询，处理请求就像打扑克时 发牌那样）和IP hash（众多请求时，保证来自同一ip的请求被分发的同一个后端服务器）。
如果handler返回（译者注：就是http响应，即filter的输入）正确无误，那么fileter就被调用了。每个location配置里都可以 添加多个filter，所以说（比如）响应可以被压缩和分块。多个filter的执行顺序是编译时就确定了的。filter采用了经典的“接力链表 （CHAIN OF RESPONSIBILITY）”模式：一个filter被调用并处理，接下来调用下一个filter，直到最后一个filter被调用完成，Nginx 才真正完成响应流程。
最帅的部分是在 filter链中，每个filter不会等待之前的filter完全完工，它可以处理之前filter正在输出的内容，这有一点像Unix中的管道。 Filter的操作都基于buffers_，buffer通常情况下等于一个页的大小（4k),你也可以在nginx.conf里改变它的大小。这意味 着，比如说，模块可以在从后端服务器收到全部的响应之前，就开始压缩这个响应并流化(stream to)给客户端了。好牛逼啊~ 总结一下上面的内容，一个典型的周期应当是这样的：当nginx接收到一个客户端发送 HTTP request → Nginx基于location的配置选择一个合适的handler → (如果有) load-balancer选择一个后端服务器 → Handler处理请求并顺序将每一个响应buffer发送给第一个filter → 第一个filter讲输出交给第二个filter → 第二个给第三个 → 第三个给第四个 → 以此类推 → 最终响应发送给客户端
这里如果是请求的php文件，location就会把请求送到本机9000端口由php-cgi来处理并构造输出buffer，再把buffer发送给第一个filter，一直传递到最后一个filter,最终响应发送给客户端。