Nginx 负载均衡配置

• 配置实例
  • 测试环境
  • 部署策略
  • A服务器配置
  • B 服务器配置
• 负载均衡策略
  • 轮询
  • 最少连接
  • 权重
  • ip_hash
• 如何实现 session 共享：
  • 不使用session，换作cookie | token
  • 应用服务器自行实现共享
  • ip_hash

配置实例

测试环境

域名：api.test.com
服务器：Ubuntu 20.04.3 、 nginx/1.20.1

A服务器：172.21.181.19 （内网ip）

B服务器：172.21.181.1 （内网ip）

部署策略

用A服务器作为主服务器负责分发请求，A、B 服务器用来处理最终请求

A服务器配置

# 负载均衡配置
upstream apiServer{
    server  172.21.181.19:18081 weight=2;  # 对应应用服务器server_name 172.21.181.19 , 端口 18081
    server 172.21.181.1:18081 weight=1;
    server 172.21.181.2:18081  down;

   // weight 权重，值越大，则被访问的概率越大
   // down 表示当前服务器不参与负载均衡，也就是说不会被访问到
   // max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误
   // fail_timeout:max_fails 次失败后，暂停的时间。
   // backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。
}

# 负载均衡请求入口, 接收、分发请求

server
{

        listen 80; #  负载均衡入口 listen 对应外部访问的端口
        server_name api.test.com ; # 负载均衡入口server_name 对应外部访问的域名
        location / {
                proxy_pass   http://apiServer;
                proxy_set_header        Host    $host; # 这是必要设置，传递域名。
                proxy_set_header        X-Real-IP       $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;  # 即将后面变量赋值给前面字段，代理将此字段添加到http头部
        }

}

# A服务器自身也用来处理请求

server
    {
        listen 18081;
        server_name 172.21.181.19;
        index index.html index.htm index.php default.html default.htm default.php;
        root  /alidata/www/api/current/public;

        location / {
                if (!-e $request_filename) {
                    rewrite ^(.*)$ /index.php?s=/$1 last;
                    break;
                }
        }   

        #error_page   404   /404.html;

        # Deny access to PHP files in specific directory
        #location ~ /(wp-content|uploads|wp-includes|images)/.*\.php$ { deny all; }

        location ~ [^/]\.php(/|$)
        {
            try_files $uri =404;
            fastcgi_pass  unix:/tmp/php-cgi.sock;
            fastcgi_index index.php;
            include fastcgi.conf;
        }

        location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
        {
            expires      30d;
        }

        location ~ .*\.(js|css)?$
        {
            expires      12h;
        }

        location ~ /.well-known {
            allow all;
        }

        location ~ .*\.(sql)?$
        {
            return 404;
        }

        location ~ /\.
        {
            deny all;
        }

        access_log  /alidata/log/nginx/api.test.com.log main;
        error_log  /alidata/log/nginx/nginx_error.log;
    }

B 服务器配置

server
    {
        listen 18081;
        server_name api.test.com;
        index index.html index.htm index.php default.html default.htm default.php;
        root  /alidata/www/api/current/public;

        location / {
                if (!-e $request_filename) {
                    rewrite ^(.*)$ /index.php?s=/$1 last;
                    break;
                }
        }

        #error_page   404   /404.html;

        # Deny access to PHP files in specific directory
        #location ~ /(wp-content|uploads|wp-includes|images)/.*\.php$ { deny all; }

            location ~ [^/]\.php(/|$)
        {
            try_files $uri =404;
            fastcgi_pass  unix:/tmp/php-cgi.sock;
            fastcgi_index index.php;
            include fastcgi.conf;
        }

        location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
        {
            expires      30d;
        }

        location ~ .*\.(js|css)?$
        {
            expires      12h;
        }

        location ~ /.well-known {
            allow all;
        }
        location ~ .*\.(sql)?$
        {
            return 404;
        }

        location ~ /\.
        {
            deny all;
        }

        access_log  /alidata/log/nginx/api.test.com.log main;
        error_log  /alidata/log/nginx/nginx_error.log;
    }

重启2台服务器的 nginx 服务

做完上面的设置，简单的nginx负载均衡就算是配置完成了。可通过在A、B 服务器同路径下放不同内容，不断刷新请求会展示的内容的不同来验证负载均衡是否配置成功。

对于一台服务器即作为负载均衡的主服务器，又作为应用服务器时要注意不要将请求分发到了请求入口的server, 造成死循环,此时会导致报错“400 Bad Request Request Header Or Cookie Too Large”

负载均衡策略

轮询

这是默认的策略，把每个请求逐一分配到不同的server，如果分配到的server不可用，则分配到下一个，直到可用

upstream test.cc {
    server 192.168.8.143;
    server 192.168.8.144;
}

最少连接

把请求分配到连接数最少的server

upstream test.cc {
    least_conn;
    server 192.168.8.143;
    server 192.168.8.144;
}

权重

weight默认值为1，值越大则代表被访问的几率越大，如下配置，144的访问数量是143的2倍

upstream test.cc {
    server 192.168.8.143 weight=1;
    server 192.168.8.144 weight=2;
}

ip_hash

根据访问客户端ip的hash值分配，这样同一客户端的请求都会被分配到同一个server上，如果牵扯到服务器本地存储 session 的问题，用这个是最好的选择

upstream test.cc {
    ip_hash;
    server 192.168.8.143;
    server 192.168.8.144;
}

Nginx 支持多组的负载均衡,可以配置多个upstream 来服务于不同的Server.

如何实现 session 共享：

不使用session，换作cookie | token

能把session改成cookie，就能避开session的一些弊端，在从前看的一本J2EE的书上，也指明在集群系统中不能用session，否则惹出祸端来就不好办。

如果系统不复杂，就优先考虑能否将session去掉，改动起来非常麻烦的话，再用下面的办法。

还可以像jwt那样用token,通过解密token关联用户

应用服务器自行实现共享

asp.net可以用数据库或memcached来保存session，从而在asp.net本身建立了一个session集群，用这样的方式可以令 session保证稳定，即使某个节点有故障，session也不会丢失，适用于较为严格但请求量不高的场合。但是它的效率是不会很高的，不适用于对效率 要求高的场合。

以上两个办法都跟nginx没什么关系，下面来说说用nginx该如何处理：

ip_hash

nginx中的ip_hash技术能够将某个ip的请求定向到同一台后端，这样一来这个ip下的某个客户端和某个后端就能建立起稳固的session，ip_hash是在upstream配置中定义的：

upstream backend {
server 127.0.0.1:8080 ;
server 127.0.0.1:9090 ;
ip_hash;
}

ip_hash是容易理解的，但是因为仅仅能用ip这个因子来分配后端，因此ip_hash是有缺陷的，不能在一些情况下使用：

• nginx不是最前端的服务器。

ip_hash要求nginx一定是最前端的服务器，否则nginx得不到正确ip，就不能根据ip作hash。

譬如使用的是squid为最前端，那么nginx取ip时只能得到squid的服务器ip地址，用这个地址来作分流是肯定错乱的。

• nginx的后端还有其它方式的负载均衡。

假如nginx后端又有其它负载均衡，将请求又通过另外的方式分流了，那么某个客户端的请求肯定不能定位到同一台session应用服务器上。这么算起来，nginx后端只能直接指向应用服务器，

或者再搭一个squid，然后指向应用服务器。最好的办法是用location作一次分流，

将需要session的部分请求通过ip_hash分流，剩下的走其它后端去。

Nginx 负载均衡官方文档

引用链接

[1] Nginx 负载均衡官方文档: https://nginx.org/en/docs/stream/ngx_stream_upstream_module.html