So konfigurieren Sie den Nginx-Lastausgleich

Polling

nginx verteilt alle Anfragen gleichmäßig an jeden Server im Cluster.

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: Definieren Sie einen Service-Cluster. Proxy_Pass: Leiten Sie den passenden Anforderungs-Proxy an den hinter Proxy_Pass konfigurierten Dienst weiter. Da hier der Lastausgleich konfiguriert werden muss, muss auf http:// der vom Upstream definierte Dienstcluster folgen. 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

Hinweis: Wenn Upstream einen Dienstcluster definiert, kann die konfigurierte Dienstadresse nur Domänenname + Port oder IP + Port sein und darf weder Protokoll noch Pfad enthalten, andernfalls meldet Nginx nginx: [emerg] invalid host im UpstreamDiese Fehlermeldung.

Gewichtet

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

Die ersten beiden Anfragen werden an den Dienst 127.0.0.1:7001 weitergeleitet, und die nächste Anfrage wird an den Dienst 150.109.118.85:7001 weitergeleitet service service und wird dann zweimal an 127.0.0.1:7001 weitergeleitet. . .

Mindestanzahl an Verbindungen

Dateispeicherort: src/http/modules/ngx_http_upstream_least_conn_module.c

nginx-Anfragen werden dem Server mit der kleinsten aktiven_Verbindung/Gewicht zugewiesen.

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

ip_hash

Dateispeicherort: src/http/modules/ngx_http_upstream_ip_hash_module.c🎜🎜Berechnen Sie einen Hash-Wert basierend auf der IP des Benutzers. Wenn im Lastausgleichscache ein Server vorhanden ist, der diesem Hash entspricht direkt auf den entsprechenden Server weitergeleitet. 🎜

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

🎜Nachdem Nginx die IP_Hash-Richtlinie verwendet, fordert es immer denselben Geschäftsdienst an, solange sich die IP des Computers des Benutzers nicht ändert. 🎜🎜Anwendungsszenario: Bei der Implementierung der Datei-Upload-Funktion wird zum Hochladen einer großen Datei die große Datei häufig in mehrere Fragmente unterteilt und dann auf den Server hochgeladen. Wenn die oben angegebene Strategie verwendet wird, wird dieselbe Datei in Fragmente unterteilt . Die Dateien wurden auf verschiedene Server hochgeladen, wodurch die Dateizusammenführung fehlschlug und die erwarteten Ergebnisse nicht erzielt werden konnten. Nachdem Nginx die IP_Hash-Richtlinie verwendet, muss der Client nur ein Fragment der aktuellen Datei hochladen. Wenn nachfolgende Dateifragmente hochgeladen werden, leitet Nginx die Anforderung automatisch an den Server weiter, der dem Hash entspricht, indem der Hash der IP berechnet wird. 🎜🎜hash🎜🎜Dateispeicherort: src/http/modules/ngx_http_upstream_hash_module.c🎜🎜Die Hash-Berechnungen, die durchgeführt werden können, umfassen remote_addr (Client-IP) (aus den Testergebnissen geht hervor, dass ip_hash direkt ersetzt werden kann), request_uri ( request uri), args (Anfrageparameter), im Folgenden wird hauptsächlich die Verwendung von request_uri als Demonstration verwendet, die anderen beiden Verwendungen sind ähnlich. 🎜🎜Berechnen Sie einen Hash-Wert basierend auf der angeforderten URL und leiten Sie die Anfrage dann an einen Server weiter. Nachdem nachfolgende Anfragen über den Hash berechnet wurden, wird die Anfrage an den Server weitergeleitet, der dem Hash entspricht. 🎜🎜Angenommen, was passiert, nachdem ein Server im Cluster ausgefallen ist: Wenn r1 Server a trifft, welchen Server trifft dann r2? . Wenn Server a ausfällt, wird die Korrespondenz zwischen dem zuvor von r1 berechneten Hash-Wert und Server a ungültig und r1 wird an Server b neu verteilt. Nachdem Server a wieder normal ist, wird r1 weiterhin Server b zugewiesen. 🎜

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

🎜Anwendungsszenario: Alle Anforderungen für dieselben Dateiressourcen werden an denselben Server weitergeleitet, wodurch Ressourcen leichter auf den Cache zugreifen können, wodurch Bandbreite und Ressourcen-Downloadzeit reduziert werden. 🎜🎜🎜consistent_hash🎜🎜🎜consistent_hash (konsistenter Hash) Dieses Modul wird fast auf die gleiche Weise verwendet wie das integrierte Hash-Modul von Nginx. Der Inhalt, der mit konsistentem_hash berechnet werden kann, ist derselbe wie das zuvor erwähnte integrierte Hash-Modul von Nginx, einschließlich remote_addr, request_uri und args. Sie können hier ngx_http_consistent_hash herunterladen, eine Software für Module von Drittanbietern. 🎜

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

🎜fair🎜🎜Serviceanfragen mit kurzen Reaktionszeiten werden zuerst vergeben. Sie können dieses Drittanbietermodul von der Download-Seite von nginx_upstream_fair beziehen. Dieses Modul wurde zuletzt vor 8 Jahren aktualisiert. Möglicherweise möchten Sie überlegen, ob Sie es verwenden müssen. 🎜

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

🎜Im Test war der Effekt derselbe wie in der Standardabfragesituation, und das Problem wurde noch nicht gefunden. . . 🎜🎜Load-Balancing-bezogene Parameter🎜🎜🎜down🎜🎜🎜Der als down markierte Server unterstützt vorübergehend keine Ressourcenanforderungen. 🎜rrreee🎜Da im obigen Lastausgleichsbeispiel 127.0.0.1:7001 als down markiert ist, werden keine Anfragen an diesen Dienst weitergeleitet und alle Anfragen werden weitergeleitet zu 150.109.118.85:7001Dieser Dienst. 🎜🎜🎜Gewicht🎜🎜🎜Der Gewichtungswert des Dienstes im Cluster, der Standardwert ist 1. Unter der Bedingung, dass nur die Gewichtung betroffen ist und alle Dienste im Cluster normal sind, leitet Nginx mehr Anfragen an Dienste mit größerer Gewichtung weiter. 🎜rrreee🎜Das Verhältnis der von Dienst 127 und Dienst 150 verarbeiteten Anfragen in diesem Cluster beträgt 2:1. 🎜🎜🎜max_fails🎜🎜🎜Die Anzahl der zulässigen Dienstfehler, wenn der Dienst Anforderungen verarbeitet. Der Standardwert ist 1. Wenn die Anzahl der Fehler bei der Dienstverarbeitungsanfrage max_fails überschreitet, werden nachfolgende Anfragen nicht an den Dienst weitergeleitet, bei dem der Fehler aufgetreten ist. 🎜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;
}

Das obige ist der detaillierte Inhalt vonSo konfigurieren Sie den Nginx-Lastausgleich. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!