Wie Nginx ngx_http_upstream_module verwendet, um die Lastausgleichsfunktion zu implementieren

Einführung in den Lastausgleich

Was ist Lastausgleich?

Unter Lastausgleich (Load Balance) versteht man den Ausgleich und die Verteilung der Last (Arbeitsaufgaben, Zugriffsanfragen) auf mehrere Betriebseinheiten (Server, Komponenten) umzusetzen.

Warum Lastausgleich erforderlich ist

Wenn ein einzelner Webserver direkt mit Benutzern konfrontiert ist, kann er eine große Anzahl gleichzeitiger Anforderungen übertragen, und es kann schwierig sein, einen einzelnen Server zu laden. Wir müssen mehrere Webserver verwenden, um einen Cluster zu bilden Verwenden Sie die Nginx-Lastausgleichsfunktion. Verteilen Sie Anforderungen an verschiedene Back-End-Server, um eine Verteilung des Lastverkehrs zu erreichen, die Gesamtleistung zu verbessern und die Funktionen zur Systemwiederherstellung zu verbessern.

• Was ist der Unterschied zwischen Lastausgleich und Proxy?

Ein Proxy besteht darin, einen Server basierend auf der URI-Planung zu vertreten und ihn für Anwendungsknoten mit unterschiedlichen Funktionen einzuplanen.

Beim Lastausgleich werden Clientanforderungen an eine Reihe von Proxys weitergeleitet Upstream-Ressourcenpools über Proxy_Pass

• Um Lastausgleichsszenarien zu implementieren

Zur Implementierung der Lastausgleichsfunktion sind zwei Module erforderlich:

• proxy_pass: Proxy-Modul

• Upstream: virtueller Ressourcenpool

Beispiel: eine offizielle Lastausgleichsanzeige

upstream backend {
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server unix:/tmp/backend3;

    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

Beispiel: Vervollständigen Sie selbst ein kleines Beispiel

upstream node {
    server 192.168.10.3:80;
    server 192.168.10.4:80;
}
server {
    listen 80;
    server_name www.yyang.com;
    location / {
        proxy_pass http://node;
        include prxoy_params;
    }
}

Lastausgleichsplanungsalgorithmus

Abfrageplanung

der Reihe nach nacheinander auf verschiedene Backend-Knoten verteilt, was auch der Standardalgorithmus ist . (Einfach ausgedrückt ist es 1:1:1)

Gewichtete Abfrage
Angesichts der unterschiedlichen Leistung verschiedener Server werden den Knoten unterschiedliche Gewichte zugewiesen, sodass sie die entsprechende Anzahl an Gewichtsanforderungen erhalten

server 192.168.10.3:80 weight=3;
server 192.168.10.4:80 weight=1;

Das obige Beispiel Das bedeutet, dass alle vier Anfragen drei Anfragen für 10.3 und einer Anfrage für 10.4 zugeordnet werden und der Zyklus weitergeht.

ip_hash

Führen Sie entsprechend der vom Benutzer angeforderten IP eine Hash-Operation für die IP durch und weisen Sie die Anforderung basierend auf dem berechneten Wert einem bestimmten Knoten im Backend zur Verarbeitung zu.

Der Wertebereich sind die ersten drei 8 Bits der IPv4-Adresse oder die gesamte Adresse von IPv6 als Hash-Schlüssel, wodurch sichergestellt wird, dass die IP von einem Client immer an denselben Server weitergeleitet wird, es sei denn, der sekundäre Server ist nicht verfügbar. Einfach ausgedrückt sind die ersten drei Zahlensätze von 172.16.20.1 und 172.16.20.2 gleich (alle 172.16.20). Eine große Anzahl von Anfragen von derselben IP führt zu übermäßigem Datenverkehr auf einem bestimmten Knoten. Wenn ein Knoten vorübergehend offline ist, wird empfohlen, den Down-Status zu verwenden gleichzeitig.

ip_hash;
server 192.168.10.3:80;
server 192.168.10.4:80;

Konsistenter Hash

Um die oben genannten Probleme zu vermeiden, wurde ein konsistentes Hashing mit der Modulo-Methode entwickelt, das jedoch nicht die Anzahl der Serverknoten moduliert, sondern Modulo 2 hoch 32 . Der Hash-Funktionswert ist 0~2^32-1 . (Bildet einen virtuellen Ring und Benutzeranfragen werden an im Uhrzeigersinn benachbarte Knoten gesendet.)

Es gibt ein Problem: Wenn weniger Back-End-Knoten vorhanden sind, kann dies zu einer Datenverzerrung führen. Daher führt konsistentes Hashing einen virtuellen Knotenmechanismus ein, d. h. z Jeder Server berechnet mehrere Hashes und platziert einen virtuellen Knoten an jedem Ort des berechneten Ergebnisses.

Was sollen wir tun, wenn wir ip_hash verwenden möchten, die Berechnungsformel jedoch einen konsistenten Hash verwendet?

hash $remote_addr consistent;
server 192.168.10.3:80;
server 192.168.10.4:80;

url_hash

nimmt das Hash-Modulo basierend auf der URL des Benutzers und weist die Anfrage basierend auf dem Vorgangswert einem bestimmten Backend-Server zu.

1. Der Benutzer fordert Nginx-Lastausgleich an, und über den URL-Algorithmus wird die Anforderung an Cache1 geplant

2. Cache1 hat keine Daten, er ruft die Daten vom Backend ab, gibt die Daten zurück und speichert die Daten im Cache

3 . Wenn andere Benutzer auf dieselbe URL zugreifen, wird der Server weiterhin für den Cache1-Knoten geplant. 4.cache1 gibt die Daten direkt zurück Für diesen Server geplant.

hash $request_uri consistent;
server 192.168.10.3:80;
server 192.168.10.4:80;

Backup

Standby-Knoten, dieser Knoten wird unter normalen Umständen nicht eingeplant; wenn der Knoten wiederhergestellt wird, wird er weiterhin in den Standby-Zustand versetzt.

least_conn;
server 192.168.10.3:80;
server 192.168.10.4:80;

max_conns

wird verwendet, um die maximale Anzahl der von jedem Backend-Knoten empfangenen TCP-Verbindungen zu begrenzen. Wenn das Limit überschritten wird, wird ein Fehler ausgegeben.

server 192.168.10.3:80 down;
server 192.168.10.4:80;

Einer kann 10 verbinden. Zwei können 20 verbinden. Wenn es 20 überschreitet, tritt ein Fehler auf.

keepalived

aktiviert das Caching mit dem Backend-Server, also lange Links, um den Website-Durchsatz zu verbessern.

Diese Funktion ist standardmäßig nicht aktiviert. Wenn eine Anfrage vorliegt, wird eine Verbindung hergestellt, aufrechterhalten und geschlossen. Wenn jedoch alle Verbindungen zwischengespeichert sind, werden andere Systemressourcen belegt Leerlauf, daher kann der Keepalived-Parameter verwendet werden.

server 192.168.10.3:80;
server 192.168.10.4:80;
server 192.168.10.5:80 backup;

max_fails und fail_timeout

max_fails=2：服务器通信失败两次，认为服务器不可用
fail_timeout=5s：服务器通信失败后，每5秒探测一次服务器是否恢复正常。
在fail_timeout设定时间内，与服务器连接失败次数达到max_fails数量，则认为服务器不可用。
如果不设置的话默认是探测一次，间隔10s。

server 192.168.10.3:80 max_fails=2 fail_timeout=5s;
server 192.168.10.4:80 max_fails=2 fail_timeout=5s;

Das obige ist der detaillierte Inhalt vonWie Nginx ngx_http_upstream_module verwendet, um die Lastausgleichsfunktion zu implementieren. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!