Unter Lastausgleich (Load Balance) versteht man den Ausgleich und die Verteilung der Last (Arbeitsaufgaben, Zugriffsanfragen) auf mehrere Betriebseinheiten (Server, Komponenten) umzusetzen.
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; } }
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;
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.)
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
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;
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.
keepalivedaktiviert 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!