【无标题】

Nginx负载均衡配置记录
本次主要是做一个记录，由于最近一直在负责新测试环境的服务部署，想尝试一下利用nginx做负载均衡。
一、配置过程。

#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

pid        /usr/local/nginx/logs/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    upstream webservers{
      		server  192.168.169.130:8081;
      		server  192.168.169.130:8082;
		    server  192.168.169.130:8083;
	}

    server {
        listen       9600;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

       # location / {
            #root   html;
            #index  index.html index.htm;
       #}

        location / {
		    #转发到负载服务上
		    proxy_pass http://webservers;
        }

        # location /test/api2 {
		#     #转发到负载服务上
		#     proxy_pass http://webservers;
        # }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
        #    proxy_pass   http://127.0.0.1;
        #}

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #    root           html;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #    deny  all;
        #}
    }


    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {
    #    listen       8000;
    #    listen       somename:8080;
    #    server_name  somename  alias  another.alias;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}


    # HTTPS server
    #
    #server {
    #    listen       443 ssl;
    #    server_name  localhost;

    #    ssl_certificate      cert.pem;
    #    ssl_certificate_key  cert.key;

    #    ssl_session_cache    shared:SSL:1m;
    #    ssl_session_timeout  5m;

    #    ssl_ciphers  HIGH:!aNULL:!MD5;
    #    ssl_prefer_server_ciphers  on;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}

}

1、配置upstream，在http{}里 新增 upstream 指向你启动的那三个后端服务。webservers 可以起一个自己容易辨识的名字，这里仅作演示。

upstream webservers{
	server  192.168.169.130:8081;
	server  192.168.169.130:8082;
	server  192.168.169.130:8083;
}

2、在 server{} 里添加一个location，并且配置 proxy_pass，（注意不要有同名的 比如已经有一个 location / 了，你再添加重启Nginx就会报错）

location / {
	#转发到负载服务上
	proxy_pass http://webservers;
}

二、说明。

默认情况下，直接按照上面的配置后，如果后端有多个服务，采用的是轮询策略；

weight 多台机器，可以配置权重值，权重高的服务将会优先被访问
down 某个服务配置down之后，这台服务将不会被访问
backup 配置了这个参数后，除非其他的服务都挂掉了，否则这台服务将不会被访问到

1、ip_hash
每个请求按访问IP的hash结果进行分配，这样每个访客就可以固定访问一个后端服务，一定程度上可以解决session问题；

upstream webservers {<!--{cke_protected}{C}%3C!%2D%2D%20%2D%2D%3E--> ip_hash; server 192.168.169.130:8081; server 192.168.169.130:8082; server 192.168.169.130:8083;}

2、weight
weight代表权重，默认为1，权重越高，被分配的客户端请求就会越多

upstream webservers{
     server  192.168.9.134:8081 weight=8;
     server  192.168.9.134:8082 weight=2;
  }

3、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的将会被优先分配

upstream webservers{
        server 192.168.9.134:8081;
        server 192.168.9.134:8082;
        fair;
}

4、url_hash
按访问URL的hash结果分配。这样相同的url会被分配到同一个节点，主要为了提高缓存命中率。比如，为了提高访问性能，服务端有大量数据或者资源文件需要被缓存。使用这种策略，可以节省缓存空间，提高缓存命中率

upstream webservers{
    hash &request_uri;
    server 192.168.9.134:8081;
    server 192.168.9.134:8082;
}

5、least_conn
按节点连接数分配，把请求优先分配给连接数少的节点。该策略主要为了解决，各个节点请求处理时间长短不一造成某些节点超负荷的情况。

upstream webservers{
    least_conn;
    server 192.168.9.134:8081;
    server 192.168.9.134:8082;
}

同时，各自配置策略在实际使用的时候也不是孤立的，比如最小连接数可以搭配权重数一起使用