nginx 로드 밸런싱을 구성하는 방법

Polling

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:// 뒤에는 업스트림에서 정의한 서비스 클러스터가 와야 합니다. 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会命中哪个服务器？。如果a服务器宕机，之前通过r1计算出来的哈希值与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

Note: 업스트림이 서비스 클러스터를 정의할 때 구성된 서비스 주소는 도메인 이름 + 포트 또는 IP + 포트만 가능하며 프로토콜과 경로를 포함할 수 없습니다. 그렇지 않으면 nginx는 nginx: [emerg] 잘못된 호스트를 보고합니다. 업스트림에서이 오류 메시지가 나타납니다.

Weighted

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로 전달됩니다. service 서비스를 수행한 후 127.0.0.1:7001로 두 번 전달됩니다. . .

최소 연결 수

파일 위치: src/http/modules/ngx_http_upstream_least_conn_module.c

nginx 요청은 active_connection/weight가 가장 작은 서버에 할당됩니다.

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

ip_hash

파일 위치: src/http/modules/ngx_http_upstream_ip_hash_module.c🎜🎜사용자의 IP를 기준으로 해시 값을 계산합니다. 로드 밸런싱 캐시에 이 해시에 해당하는 서버가 있는 경우입니다. 해당 서버로 직접 전달됩니다. 🎜

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

🎜nginx는 ip_hash 정책을 사용한 후에는 사용자 컴퓨터의 IP가 변경되지 않는 한 항상 동일한 비즈니스 서비스를 요청합니다. 🎜🎜응용 시나리오: 파일 업로드 기능을 구현할 때 대용량 파일을 업로드하려면 대용량 파일을 여러 조각으로 나누어 서버에 업로드하는 경우가 많습니다. 위에 주어진 전략을 사용하면 동일한 파일이 여러 조각으로 나누어집니다. . 파일이 다른 서버에 업로드되어 파일 병합이 실패하고 예상한 결과를 얻을 수 없습니다. nginx가 ip_hash 정책을 사용한 후 클라이언트는 현재 파일의 조각만 업로드하면 되며, 후속 파일 조각이 업로드되면 nginx는 IP의 해시를 계산하여 해시에 해당하는 서버에 자동으로 요청을 전달합니다. 🎜🎜hash🎜🎜파일 위치: src/http/modules/ngx_http_upstream_hash_module.c🎜🎜 수행할 수 있는 해시 계산에는 remote_addr(클라이언트 IP)(테스트 결과 ip_hash를 직접 대체할 수 있는 것으로 나타남), request_uri( request uri) , args(요청 매개변수), 다음은 주로 request_uri의 사용을 데모로 사용하고 다른 두 가지 사용은 유사합니다. 🎜🎜요청된 URI를 기반으로 해시 값을 계산한 후 서버로 요청을 전달합니다. 이후의 요청도 해시를 통해 계산된 후 동일한 해시가 있으면 해당 해시에 해당하는 서버로 요청이 전달됩니다. 🎜🎜클러스터의 서버가 다운된 후 어떤 일이 발생한다고 가정해 보겠습니다. r1이 서버 a에 도달하면 r2는 어느 서버에 도달할까요? . 서버 a가 다운되면 이전에 r1이 계산한 해시 값과 서버 a 간의 대응 관계가 무효화되고 r1은 서버 b에 재분배됩니다. 서버 a가 정상으로 돌아온 후에도 r1은 여전히 ​​서버 b에 할당됩니다. 🎜

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

🎜애플리케이션 시나리오: 동일한 파일 리소스에 대한 모든 요청은 동일한 서버로 전달되므로 리소스가 캐시에 더 쉽게 도달하여 대역폭과 리소스 다운로드 시간이 줄어듭니다. ㅋㅋㅋ Consistency_hash를 이용하여 계산할 수 있는 내용은 앞서 언급한 nginx 내장 해시 모듈과 Remote_addr, request_uri, args 등이 동일합니다. 타사 모듈용 소프트웨어인 ngx_http_consistant_hash를 여기에서 다운로드할 수 있습니다. 🎜

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

🎜fair🎜🎜응답 시간이 짧은 서비스 요청이 먼저 할당됩니다. nginx_upstream_fair의 다운로드 페이지에서 이 타사 모듈을 얻을 수 있습니다. 이 모듈은 8년 전에 마지막으로 업데이트되었습니다. 이 모듈을 사용해야 하는지 고려해 보세요. 🎜

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

🎜테스트에서는 기본 폴링 상황과 효과가 동일하며, 아직 문제는 발견되지 않았습니다. . . 🎜🎜로드 밸런싱 관련 매개변수🎜🎜🎜down🎜🎜🎜 down으로 표시된 서버는 일시적으로 리소스 요청을 지원하지 않습니다. 🎜rrreee🎜위의 로드 밸런싱 예시에서는 127.0.0.1:7001이 down으로 표시되었기 때문에 이 서비스에는 어떤 요청도 전달되지 않고 모든 요청이 전달됩니다. 150.109.118.85:7001이 서비스로. 🎜🎜🎜weight🎜🎜🎜클러스터 내 서비스의 가중치 값, 기본값은 1입니다. 가중치만 영향을 받고 클러스터의 모든 서비스가 정상이라는 조건에서 nginx는 가중치가 더 큰 서비스에 더 많은 요청을 전달합니다. 🎜rrreee🎜이 클러스터의 서비스 127과 서비스 150에서 처리되는 요청 비율은 2:1입니다. 🎜🎜🎜max_fails🎜🎜🎜서비스가 요청을 처리할 때 허용되는 서비스 오류 수, 기본값은 1입니다. 서비스 처리 요청의 오류 개수가 max_fails를 초과하면 오류가 발생한 서비스로 후속 요청이 전달되지 않습니다. 🎜rrreee🎜🎜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;
}

위 내용은 nginx 로드 밸런싱을 구성하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!