ngnix的配置方式

常规ngnix的配置：

upstream servers.com{

　　server 127.0.0.1:18080;

　　server 127.0.0.1:28080;

}

location / {

　　proxy_pass http://servers.com;

}

location 语法规则：

location [=|~|~*|^~] /uri/ { … }

= 开头表示精确匹配

^~ 开头表示uri以某个常规字符串开头，理解为匹配 url路径即可。nginx不对url做编码，因此请求为/static/20%/aa，可以被规则^~ /static/ /aa匹配到（注意是空格）。

~ 开头表示区分大小写的正则匹配

~*  开头表示不区分大小写的正则匹配

!~和!~*分别为区分大小写不匹配及不区分大小写不匹配 的正则

/ 通用匹配，任何请求都会匹配到。

实例：

      location = / {
          #规则A
      }
      location = /login {
          #规则B
      }
      location ^~ /static/ {
          #规则C
      }
      location ~ .(gif|jpg|png|js|css)$ {
          #规则D
      }
      location ~* .png$ {
          #规则E
      }
      location !~ .xhtml$ {
          #规则F
      }
      location !~* .xhtml$ {
          #规则G
      }
      location / {
          #规则H
      }


1. 访问根目录/，比如http://localhost/将匹配规则A

2. 访问 http://localhost/login 将匹配规则B，http://localhost/register则匹配规则H

3. 访问 http://localhost/static/a.html 将匹配规则C

4. 访问 http://localhost/a.gif,http://localhost/b.jpg 将匹配规则D和规则E，但是规则D顺序优先，规则E不起作用，而http://localhost/static/c.png则优先匹配到规则C

5. 访问 http://localhost/a.PNG 则匹配规则E，而不会匹配规则D，因为规则E不区分大小写。

6. 访问 http://localhost/a.xhtml 不会匹配规则F和规则G，http://localhost/a.XHTML不会匹配规则G，因为不区分大小写。规则F，规则G属于排除法，符合匹配规则但是不会匹配到，所以想想看实际应用中哪里会用到。

7. 访问 http://localhost/category/id/1111 则最终匹配到规则H，因为以上规则都不匹配，这个时候应该是nginx转发请求给后端应用服务器，比如FastCGI（PHP），tomcat（jsp），nginx作为方向代理服务器存在。

upstream的分配方式

upstream中server指令语法如下：

        server address [parameters]

        关键字server必选。

        address也必选，可以是主机名、域名、ip或unix socket，也可以指定端口号。

        parameters是可选参数，可以是如下参数：

        down：表示当前server已停用

        backup：表示当前server是备用服务器，只有其它非backup后端服务器都挂掉了或者很忙才会分配到请求。

1、轮询    

轮询是upstream的默认分配方式，即每个请求按照时间顺序轮流分配到不同的后端服务器，如果某个后端服务器down掉后，能自动剔除。
        upstream backend {
            server 192.168.1.101:8888;
            server 192.168.1.102:8888;
            server 192.168.1.103:8888;
        }

2、weight

轮询的加强版，即可以指定轮询比率，weight和访问几率成正比，主要应用于后端服务器异质的场景下。
        upstream backend {
            server 192.168.1.101 weight=1;
            server 192.168.1.102 weight=2;
            server 192.168.1.103 weight=3;
        }

weight：表示当前server负载权重，权重越大被请求几率越大。默认是1.

3、ip_hash

每个请求按照访问ip（即Nginx的前置服务器或者客户端IP）的hash结果分配，这样每个访客会固定访问一个后端服务器，可以解决session一致问题。
        upstream backend {
            ip_hash;
            server 192.168.1.101:7777;
            server 192.168.1.102:8888;
            server 192.168.1.103:9999;
        }

4、fair

fair顾名思义，公平地按照后端服务器的响应时间（rt）来分配请求，响应时间短即rt小的后端服务器优先分配请求。
        upstream backend {
            server 192.168.1.101;
            server 192.168.1.102;
            server 192.168.1.103;
            fair;
        }

5、url_hash

与ip_hash类似，但是按照访问url的hash结果来分配请求，使得每个url定向到同一个后端服务器，主要应用于后端服务器为缓存时的场景下。
        upstream backend {
            server 192.168.1.101;
            server 192.168.1.102;
            server 192.168.1.103;
            hash $request_uri;
            hash_method crc32;
        }

upstream中server指令语法如下：        server address [parameters]        关键字server必选。        address也必选，可以是主机名、域名、ip或unix socket，也可以指定端口号。        parameters是可选参数，可以是如下参数：        down：表示当前server已停用        backup：表示当前server是备用服务器，只有其它非backup后端服务器都挂掉了或者很忙才会分配到请求。