Nginx负载均衡

共计 3072 个字符，预计需要花费 8 分钟才能阅读完成。

最近公司内部用的阿里云SLB实例感觉不够用，主要因为https实例在一个slb实例内只能创建10个，http实例好像是50个，目前这边主要都是https，随着项目的增多，slb实例费用就上去了，所以只好自建了。另一方面一些内网调用就不用创建内网SLB实例（内网实例也需要收费的-.-）

upstream

Syntax:	upstream name { ... }
Default:	—
Context:	http

定义一个上游服务器组，样例：

upstream backend {
    server backend1.example.com weight=5;
    server 127.0.0.1:8080       max_fails=3 fail_timeout=30s;
    server unix:/tmp/backend3;

    server backup1.example.com  backup;
}

upstream内使用server指令配置每个真实后端服务器

Syntax:	server address [parameters];
Default:	—
Context:	upstream

upstream块内的server指令中几个重要的参数

• weight=number：设置负载权重，默认值是1，nginx默认的负载算法是wrr
• max_conns=number：限制代理到上游服务器之间的连接数。默认值为0，即不限制
• max_fails=number：定义代理与上游服务器通信最大错误尝试次数。默认值为1，为0则禁用尝试计数
• fail_timeout=time：心跳检测间隔，代理尝试与上游服务器通信的时间，超过设定值判断为错误max_fails则计数+1。默认值为10s
• backup：定义为备用服务器，当其他上游服务器不可用时才会使用。注意该指令不能和hash/ip_hash/random算法一起使用
• down：下线上游服务器，即代理不分配流量至该服务器
• resolve：如果server指令接的是域名，则可以配置该指令来实现动态切换上游服务器，需要提前配置reslover指令
• slow_start=time：设置慢启动时间

upstream块内的其他指令

• keepalive：代理与后端服务器的长链接数，减少连接创建与销毁的代销
• keepalive_requests：每个长链接最大处理请求数，超过阈值后closed该长链接，另创建新的链接
• keepalive_time：每个活动中的长链接的存活时间，超过阈值后closed该长链接，达到此时间后，将在后续请求处理后关闭连接
• keepalive_timeout：每个长链接的超时时间，在此期间与上游服务器的空闲保持连接将保持打开状态

负载均衡样例

简单样例

upstream backend {
    # 30s内检查心跳发送两次包，未回复就代表该机器宕机，请求分发权重比为1:2
    server 192.168.44.131:8080 weight=100 max_fails=2 fail_timeout=30s;
    server 192.168.44.131:8090 weight=200 max_fails=2 fail_timeout=30s;
    # 长连接数
    keepalive 32;
    # 每个长连接提供的最大请求数
    keepalived_requests 100;
    # 每个长连接没有新的请求时，保持的最长时间
    keepalive_timeout 60s;
}
server {
    ######## 略
    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # 请求交给名为backend的upstream上
        proxy_pass http://nginx_boot;
    }
}

websocket上游服务器样例

upstream qa_backend {
    hash $remote_addr consistent;
    server 192.168.44.178:8080;
    server 192.168.44.179:8080;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

server {
    ####### 略
    location / {
        proxy_pass              http://qa_backend;
        proxy_connect_timeout   5s;
        proxy_read_timeout      60s;
        proxy_send_timeout      30s;
        proxy_http_version      1.1;
        proxy_set_header        Upgrade         $http_upgrade;
        proxy_set_header        Connection      "$connection_upgrade";
    }
}

nginx负载均衡算法

轮询

每个请求按时间顺序逐一分配到上游服务器

upstream qa_backend {
    server 192.168.44.178:8080;
    server 192.168.44.179:8080;
}

加权轮询

weight 的值越大，分配到的访问概率越高

upstream qa_backend {
    server 192.168.44.178:8080 weight 10;
    server 192.168.44.179:8080 weight 20;
}

ip_hash

每个请求按访问 IP 的哈希结果分配，使来自同一个 IP 的访客固定访问一台后端服务器，并且可以有效解决动态网页存在的 session 共享问题

upstream qa_backend {
    ip_hash
    server 192.168.44.178:8080;
    server 192.168.44.179:8080;
}

fair

需要配第三方插件模块 upstream_fair 模块，对比 weight、ip_hash 更加智能的负载均衡算法，fair 算法可以根据页面大小和加载时间长短智能地进行负载均衡，响应时间短的优先分配

upstream qa_backend {
    server 192.168.44.178:8080 weight 10;
    server 192.168.44.179:8080 weight 20;
    fair;
}

url_hash

需要安装nginx的hash软件包，按访问 url 的 hash 结果来分配请求，使每个 url 定向到同一个后端服务器，可以进一步提高后端缓存服务器的效率

upstream qa_backend {
    server 192.168.44.178:8080;
    server 192.168.44.179:8080;
    hash $request_uri;
    hash_method crc32;
}

upstream中可用的变量

• $upstream_addr
• $upstream_bytes_received
• $upstream_bytes_sent
• $upstream_cache_status
• $upstream_connect_time
• $upstream_cookie_name
• $upstream_header_time
• $upstream_http_name
• $upstream_queue_time
• $upstream_response_length
• $upstream_response_time
• $upstream_status

官方文档：https://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream