Nginx负载均衡详解

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

下面将介绍 Nginx 开源版内置的 4 种负载均衡策略和 2 种三方负载均衡策略，他们分别是：

• 轮询
• 最少连接数
• ip_hash
• hash
• fair
• consistent_hash

本文只是展示了部分 nginx 实现负载均衡时可以使用的策略模块，另外在 nginx 商业版中还存在其他内置的策略模块。负载均衡的三方策略可以在三方模块列表这里找到。

轮询

默认情况

nginx 将所有请求均匀的分给集群中的每台服务器。

upstream test {server 127.0.0.1:7001; # 等同于 server 127.0.0.1:7001 weight=1;
	server 150.109.118.85:7001; # 等同于 server 150.109.118.85:7001 weight=1;
}

server {listen 8081;
	server_name localhost;

	location / {proxy_pass http://test/;
	}
}

upstream：定义一个服务集群。
proxy_pass: 将匹配的请求代理转发到 proxy_pass 后面配置的服务上，这里因为需要配置负载均衡，所以这里 http:// 后面必须要跟上 upstream 定义的服务集群。

注意 ：upstream 定义服务集群时，配置的服务地址只能是域名 + 端口或者 ip+ 端口，不能带有协议和路径，否则 nginx 会报nginx: [emerg] invalid host in upstream 这个错误信息。

加权（weight）

upstream test {server 127.0.0.1:7001 weight=2;
	server 150.109.118.85:7001 weight=1;
}

前面两次请求都会转发到 127.0.0.1:7001 这个服务，后面一次请求会转发到 150.109.118.85:7001 这个服务，再后面两次转发到127.0.0.1:7001，。。。

最少连接数

文件位置：src/http/modules/ngx_http_upstream_least_conn_module.c

nginx 请求分配给 active_connection/weight 最小的服务器。

upstream test {
  	least_conn;
	server 127.0.0.1:7001 weight=1;
	server 150.109.118.85:7001 weight=1;
}

ip_hash

文件位置：src/http/modules/ngx_http_upstream_ip_hash_module.c

根据用户的 ip，计算出一个 hash 值，如果负载均衡缓存中有这个 hash 对应的服务器，那就直接转发到对应的服务器上。

upstream test {ip_hash;
	server 127.0.0.1:7001;
	server 150.109.118.85:7001;
}

nginx 使用 ip_hash 策略后，只要用户电脑的 ip 不变化，就会始终请求同一台业务服务。

应用场景：在实现文件上传功能时，要实现一个大文件上传，往往会将这个大文件分成多个片段，然后上传到服务器，如果使用前面给的策略，就会出现同一个文件的分片被上传到不同服务器，导致文件合并失败，不能达到预期效果。nginx 使用 ip_hash 策略后，客户端只要上传了当前文件的一个片段，后续文件片段上传的时候，nginx 通过计算 ip 的 hash，自动把请求转发到 hash 对应的服务器。

hash

文件位置：src/http/modules/ngx_http_upstream_hash_module.c

可以进行 hash 计算的有 remote_addr（客户端 ip）（从测试结果上面看感觉可以直接替换掉 ip_hash）、request_uri(请求 uri)、args（请求参数），下面主要以 request_uri 的使用作为展示，其他两个使用都类似。

根据请求的 uri 计算出一个 hash 值，然后将该请求转发到一台服务器上面，后续请求通过 hash 计算后，如果有相同的 hash，那么就会将该请求转发到该 hash 对应的服务器。

如果集群中某台服务器宕机之后会出现什么情况：假设 r1 命中 a 服务器；r2 命中 b 服务器。当 a 服务器宕机，之前通过 r1 计算出来的 hash 与 a 服务器的对应情况会失效，r1 将重新分配给 b 服务器。后续 a 服务器恢复正常后，r1 还是会分配给 b 服务器。

upstream test {hash $request_uri;
	server 127.0.0.1:7001;
	server 150.109.118.85:7001;
}

应用场景：所有请求相同的文件资源的请求都会被转发到同一个服务器，资源更容易命中缓存，减少宽带和资源下载时间。

consistent_hash

consistent_hash（一致性 hash）这个模块使用方式和 nginx 内置的 hash 模块几乎相同。能够使用 consistent_hash 进行计算的内容和前面提到的 nginx 内置的 hash 模块一样，有 remote_addr、request_uri、args。这是一个三方模块，可以在 ngx_http_consistent_hash 这里下载。

upstream test {consistent_hash $request_uri;
	server 127.0.0.1:7001;
	server 150.109.118.85:7001;
}

fair

响应时间短的服务优先分配请求。这个是三方模块，可以在 nginx_upstream_fair 这里下载模块。这个模块上次更新是 8 年前，可能需要考虑下是否需要使用这个。

upstream test {fair;
	server 127.0.0.1:7001;
	server 150.109.118.85:7001;
}

测试中得出效果和轮询默认情况效果一样，暂时没有找到问题在哪。。。

负载均衡相关参数

down

标识 down 的服务器暂时不支持资源请求。

upstream test {server 127.0.0.1:7001 down;
	server 150.109.118.85:7001;
}

上面负载均衡的例子中，因为 127.0.0.1:7001 标识为 down，所以不会有请求转发到这个服务，所有的请求都会转发到150.109.118.85:7001 这个服务。

weight

集群中服务的权重值，默认是 1。在只有 weight 这一个影响条件下，且集群中服务都正常，nginx 会将更多的请求转发到 weight 更大的服务。

upstream test {server 127.0.0.1:7001 weight=2;
	server 150.109.118.85:7001 weight=1;
}

这个集群中 127 服务和 150 服务各处理的请求比例为 2:1。

max_fails

允许服务处理请求时服务出错的次数，默认为 1。当服务处理请求发生错误的次数超过 max_fails 时，后面的请求暂时不会转发到这台发生错误的服务。

upstream test {server 127.0.0.1:7001 max_fail=1;
	server 150.109.118.85:7001;
}

fail_timeout

当服务处理请求发生错误的次数超过 max_fails 以后，nginx 会暂时禁止将请求转发到这个服务。当过去 fail_timeout 设置的时间以后，nginx 会尝试将请求转发到刚才被禁止的服务，如果服务正常，那么后续的请求可以继续转发到这台服务，如果服务错误，那么继续等待 fail_timeout 时间后再来检测。fail_timeout 默认时间是 10s。

upstream test {server 127.0.0.1:7001 max_fail=1 fail_timeout=10s;
	server 150.109.118.85:7001;
}

backup

备用服务器，当所有非 backup 服务发生错误被停用或者设置为 down 时，nginx 会启用标识为 backup 的服务。

upstream test {server 127.0.0.1:7001 backup;
	server 150.109.118.85:7001;
}

max_conns

这个功能存在于 nginx 商业版。同一服务同时处理请求的个数。防止服务因处理请求过多，服务器性能不足，发生宕机的情况。

upstream test {server 127.0.0.1:7001 max_conns=10000;
	server 150.109.118.85:7001;
}

slow_start

这个功能存在于 nginx 商业版。当集群中错误服务等待 fail_timeout 时间后，nginx 检测到这个服务能够正常使用后，再等待 slow_start 时间后，才正式使用这个服务。

upstream test {server 127.0.0.1:7001 slow_start=30s;
	server 150.109.118.85:7001;
}