Nginx多域名配置以及负载均衡

nginx绑定多个域名可又把多个域名规则写一个配置文件里，也可又分别建立多个域名配置文件，我一般为了管理方便，每个域名建一个文件，有些同类域名也可又写在一个总的配置文件里。

     一、每个域名一个文件的写法
    首先打开nginx域名配置文件存放目录：/usr/local/nginx/conf/servers ，如要绑定域名www.server110.com 则在此目录建一个文件：www.server110.com.conf 然后在此文件中写规则，如：
server 
{ 
listen       80; 
server_name www.server110.com;             #绑定域名 
index index.htm index.html index.php;      #默认文件 
root /home/www/server110.com;               #网站根目录
include location.conf;                            #调用其他规则，也可去除
}
然后重起nginx服务器，域名就绑定成功了
nginx服务器重起命令：/etc/init.d/nginx restart

    二、一个文件多个域名的写法
    一个文件添加多个域名的规则也是一样，只要把上面单个域名重复写下来就ok了，如：
server 
{ 
listen       80; 
server_name www.server110.com;             #绑定域名 
index index.htm index.html index.php;      #默认文件 
root /home/www/server110.com;               #网站根目录
include location.conf;                            #调用其他规则，也可去除
}
 
server 
{ 
listen       80; 
server_name msn.server110.com;             #绑定域名 
index index.htm index.html index.php;      #默认文件 
root /home/www/msn.server110.com;        #网站根目录
include location.conf;                            #调用其他规则，也可去除
}
 

    三、不带www的域名加301跳转
    如果不带www的域名要加301跳转，那也是和绑定域名一样，先绑定不带www的域名，只是不用写网站目录，而是进行301跳转，如：
 
server
{
listen 80;
server_name server110.com;
rewrite ^/(.*) http://www.server110.com/$1 permanent;
}
 
    四、添加404网页
    添加404网页，都可又直接在里面添加，如：
 
server 
{ 
listen       80; 
server_name www.server110.com;             #绑定域名 
index index.htm index.html index.php;      #默认文件 
root /home/www/server110.com;               #网站根目录
include location.conf;                            #调用其他规则，也可去除
error_page 404  /404.html; 
}
 
最后还有一个方法需要注意，可能有需要禁止IP直接访问80端口或者禁止非本站的域名绑定我们的IP，这样的话应该
如下处理，放到最前一个server上面即可：
 
    server{
       listen   80 default;
       server_name      _;
        return 403;
     }

    学会上面四种规则方法，基本就可以自己独立解决nginx 多域名配置问题了

设置负载均衡 

模块官方介绍： 
http://wiki.nginx.org/HttpUpstreamModule 
http://www.howtocn.org/nginx:Nginx模块参考手册中文版
说说upstream里的server指令： 
server 后面可以是域名格式，也可以是socket格式[ip:port]，后面还可以带参数。参数有下面几个： 
weight = NUMBER - 设置服务器的权重值，默认为1. 值越大，分配的请求越多。只适用于轮询这种LB策略。 
max_fails = NUMBER - 在fail_timeout设置的时间内,尝试连接服务器失败的次数.默认为1,0表示关闭检查.错误类型在proxy_next_upstream or fastcgi_next_upstream中定义,(除了404错误不计入max_fails). 
fail_timeout = TIME - the time during which must occur *max_fails* number of unsuccessful attempts at communication with the server that would cause the server to be considered inoperative, and also the time for which the server will be considered inoperative (before another attempt is made). If not set the time is 10 seconds. fail_timeout has nothing to do with upstream response time, use proxy_connect_timeout and proxy_read_timeout for controlling this. 
down - marks server as permanently offline, to be used with the directive ip_hash. 
backup - (0.6.7 or later) only uses this server if the non-backup servers are all down or busy (cannot be used with the directive ip_hash) 
nginx负载均衡的策略： 

1.轮询（默认方式） 
对于一级后端服务器群，形成一个环队列的形式，对于每个到达的请求按时间顺序顺次分配给这些后端服务器。在前端调度器与后端服务器之间采用“心跳”方式进行状态检查，如果发现后端服务器宕机，则将其删除。 
    这种方式为默认配置，优点是简洁，但缺点是无法进行最优化调度，有可能有的请求需要耗时较久，这样会带来一定的不平衡。 
    它的例子：在http区域里添加： 
upstream lb { 
        server 10.10.57.122:80; 
        server 10.10.57.123:80; 
} 
在你的某个server里增加： 
location / { 
              proxy_pass http://lb; 
        } 

2. 加权轮询 
    这是一种对上述方式的改进，引入权值的概念，能够解决后端服务器性能不均的情况。 
    例如这样一个配置： 
    upstream lb { 
         server 10.10.57.122:80 weight=5; 
         server 10.10.57.123:80 weight=10; 
    } 
ps：以上轮询负载均衡策略，我个人认为对于动态网站应用，这几乎就是形同摆设，没有人会采用。但一种情况例外：服务器端的session采用共享机制，如存储在数据库或者memcached内存里等。 

3. ip_hash(基于ip的hash分配策略) 
     这是一种非轮询式方式，对于每个到达的请求，直接通过其请求IP进行哈希的映射，通过映射结果获得那一台后端服务器要处理这个请求，这种方式有一个明显的好处是能够保证session的唯一性。 
    它的配置例子： 
upstream lb { 
        ip_hash; 
        server 10.10.57.122:80; 
        server 10.10.57.123:80; 
} 
在你的某个server里增加： 
location / { 
              proxy_pass http://lb; 
        } 
    
This directive causes requests to be distributed between upstreams based on the IP-address of the client. 
The key for the hash is the class-C network address of the client. This method guarantees that the client request will always be transferred to the same server. But if this server is considered inoperative, then the request of this client will be transferred to another server. This gives a high probability clients will always connect to the same server. 
It is not possible to combine ip_hash and weight methods for connection distribution. If one of the servers must be removed for some time, you must mark that server as *down*. 
由这段英文解说知道，客户端只要来自同一网段的ip的request都会转发到相同的后端服务器上。这里的所谓的class-C network这里作者并没有很详细地解释，我只能说，写这句话的人不懂网络。我个人的理解是：以ip地址的点分十进制格式的前3个字节进行hash。 
其实这不是真正意义上的ip address hash，而只是network address hash。真正的ip address hash方式有不？其实可以通过下面介绍的url_hash来实现。关键指令：hash $remote_addr; 
不过这里有个前提，$remote_addr必须是client的real ip address。 
为什么这里能够实现真正意义上的ip address hash？很简单，就是这里整个ip address被当作一个字符串来对待，故只要ip地址（key）不同，hash必然也是不同的。 

4. url_hash(基于URL的哈希方式) 
    这种方式与IP的哈希方式类似，是对客户机请求的URL进行哈希操作，这样的方式有一个明显的好处是，能够便于内容缓存的实现，对于经常性的资源访问，采用这样的方式会获得非常好的质量。它目前不是nginx自带的功能，需要安装补丁方可使用。本指令的详细说明和安装见：(文章后面有附带详细安装实例) 
http://wiki.nginx.org/HttpUpstreamRequestHashModule 
    它的配置方式为： 
   
upstream lb { 
         server 10.10.57.122:80; 
         server 10.10.57.123:80; 
         hash $request_uri; 
    } 
如果将这里的$request_uri换成$remote_addr便可实现上面我所说的真正基于ip地址的策略。 

5. 基于服务响应式 
   这种方式是根据服务器端的动态响应，对每一个请求进行分配。 这种方式能够自动根据当前的后端实际负载来优化。 
   它的配置方式： 
upstream lb { 
         server 10.10.57.122:80; 
         server 10.10.57.123:80; 
         fair; 
    } 
这个没怎么测试，只是配起来用了下，机器差不多的话感觉就是轮询。 
=============================== 
cd nginx-0.7.67; 
patch -p0 < ../nginx_upstream_hash-0.3.1/nginx.patch 
configure时： 
./configure --prefix=/app/nginx -user=nobody -group=nobody \ 
--add-module=../nginx_upstream_hash-0.3.1/ \ 
--add-module=../gnosek-nginx-upstream-fair-2131c73/