Nginx Tomcat übernimmt den Lastausgleich

Nginx-Lastausgleich

Aktuelle Projekte müssen unter Berücksichtigung der Parallelität entworfen werden. Beim Entwerfen der Projektarchitektur habe ich daher überlegt, Nginx zum Erstellen eines Tomcat-Clusters und dann Redis zum Erstellen einer verteilten Sitzung zu verwenden. Im Folgenden werde ich meinen Erkundungsprozess Schritt für Schritt erläutern.

Obwohl Nginx klein ist, ist es in der Tat sehr leistungsfähig. Es unterstützt Reverse-Proxy, Lastausgleich, Daten-Caching, URL-Umschreibung, Lese-/Schreibtrennung, dynamische und statische Trennung usw. Als nächstes werde ich über die Konfiguration des Lastausgleichs sprechen. Im nächsten Artikel wird die Kombination mit Redis getestet.

Nginx-Lastausgleichsplanungsmethode

Das Upstream-Modul des Lastausgleichsmoduls von Nginx unterstützt hauptsächlich die folgenden 4 Planungsalgorithmen:

1. Serverabfrage (Standardmodus): Jeder angeforderte Zugriff wird in chronologischer Reihenfolge einem anderen Server zugewiesen. Wenn ein Back-End-Server ausfällt, wird der fehlerhafte Benutzerzugriff automatisch eliminiert unberührt. Die Gewichtung gibt die Gewichtung der Abfrage an. Je größer der Gewichtungswert ist, desto höher ist die zugewiesene Zugriffswahrscheinlichkeit. Sie wird hauptsächlich verwendet, wenn die Leistung auf der Serverseite ungleichmäßig ist.

2. ip_hash: Jede Anfrage wird entsprechend dem Hashwert der aufgerufenen IP zugewiesen. Benutzer in dieser Zeile werden nach der Korrektur an einen Server im Backend weitergeleitet Auf dem Server können Sie das Problem der Sitzungsfreigabe auf Webseiten effektiv lösen.

3. Fair: Dieser Algorithmus kann Lastausgleichsentscheidungen basierend auf Seitengröße und Ladezeit, also basierend auf der, intelligent durchführen Back-End-Server Die Antwortzeit wird zum Zuweisen von Anforderungen verwendet und der Antwortzeitraum wird priorisiert. Nginx selbst lässt sich nicht in das Fair-Modul integrieren. Wenn Sie diesen Planungsalgorithmus benötigen, müssen Sie das Upstream_fair-Modul von Nginx herunterladen und es dann in der Konfiguration konfigurieren und laden.

4. url_hash: Dieser Planungsalgorithmus weist Anfragen basierend auf dem Hash-Ergebnis der besuchten URL zu, sodass jede URL an denselben Back-End-Server weitergeleitet wird, was das weiter verbessern kann Effizienz des Back-End-Servers. Nginx selbst integriert dieses Modul nicht. Wenn Sie es verwenden, müssen Sie das Hash-Paket von Nginx installieren, es kompilieren und in Nginx laden.

Vom Upstream-Modul von Nginx unterstützte Statusparameter

Im Upstream-Modul von http können Sie die IP-Adresse des Backend-Servers über angeben Serverdirektive und Port, und Sie können auch den Status jedes Backend-Servers in der Lastausgleichsplanung festlegen. Die normalerweise eingestellten Statusparameter lauten wie folgt:

1. down: Zeigt an, dass der aktuelle Server vorübergehend nicht am Lastausgleich teilnimmt.

2. Backup: Reservierter Backup-Server. Der Backup-Server wird nur dann angefordert, wenn alle anderen Nicht-Backup-Maschinen ausfallen oder ausgelastet sind, sodass dieser Server am wenigsten belastet ist.

3. max_fails: Die Anzahl der zulässigen Anforderungsfehler, der Standardwert ist 1. Wenn die maximale Anzahl von Malen überschritten wird, wird der durch das Modul „proxy_next_upstream“ definierte Fehler zurückgegeben.

4. fail_timeout: Die Zeit zum Anhalten des Dienstes nach max_fails-Fehlern. max_fails kann zusammen mit fail_timeout verwendet werden.

Hinweis: Wenn der Lastausgleichsplanungsalgorithmus ip_hash verwendet, kann der Status des Backend-Servers in der Lastausgleichsplanung nicht Gewichtung und Backup sein.

Nginx-Parameterkonfiguration und -beschreibung

#user  nobody;
worker_processes  2;

error_log  logs/error.log;
error_log  logs/error.log  notice;
error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    gzip  on;
    gzip_min_length 1k;
    gzip_buffers 4 16k;
    gzip_http_version 1.0;
    gzip_vary on;


    upstream andy {
		server 192.168.1.110:8080 weight=1 max_fails=2 fail_timeout=30s;
		server 192.168.1.111:8080 weight=1 max_fails=2 fail_timeout=30s;
        ip_hash;
    }

    server {
        listen       80;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

	location /andy_server {
	    proxy_next_upstream http_502 http_504 error timeout invalid_header;
	    proxy_set_header Host  $host;
	    proxy_set_header X-Real-IP $remote_addr;
	    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	    proxy_pass http://andy; #此处proxy_pass定义的name需要跟upstream 里面定义的name一致
	    expires      3d;
		
	   #以下配置可省略
	   client_max_body_size        10m;
	   client_body_buffer_size     128k;
	   proxy_connect_timeout       90;
	   proxy_send_timeout          90;
	   proxy_read_timeout          90;
	   proxy_buffer_size           4k;
	   proxy_buffers               4 32k;
	   proxy_busy_buffers_size     64k;
	   proxy_temp_file_write_size 64k;
	}

        error_page  404              /404.html;
		
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }

}

Hinweis: Siehe Eine ausführliche Konfigurationserklärung finden Sie im vorherigen Artikel.

Nginx-Lastausgleichstest

Nginx wird jetzt auf den Tomcat-Servern 192.168.1.110, 192.168.1.110 und 192.168 bereitgestellt bereitgestellt auf .111.

1. Wenn beim Öffnen von http://192.168.1.110/andy_server/ der Nginx-Ladecluster den Standardmodus annimmt, wird der Server jedes Mal abgefragt.

wie folgt:

                                             Diese Methode kann das Cluster-Sitzungsproblem nicht lösen.

                                                                         🎜>

Diese Methode löst das Sitzungsproblem. Wenn der Server 192.168.1.110 ausfällt, überträgt Nginx die Anfrage an den Server, der nicht heruntergefahren ist (fahren Sie nach dem Testen den Server 192.168.1.110 herunter und stellen Sie dann die Anfrage Springt zum Server 192.168.1.111. Es gibt jedoch auch ein Problem. Wenn der Hash-Server ausfällt und Nginx auf einen anderen Server übertragen wird, geht die Sitzung natürlich verloren.

3. Die verbleibenden zwei entsprechenden Module, die für die Installation von Nginx erforderlich sind, werden nicht auf die gleiche Weise wie oben getestet.

Zusammenfassung

Unabhängig davon, welche Lastausgleichsmethode verwendet wird, kommt es zu Sitzungsverlusten. Um dieses Problem zu lösen, muss die Sitzung separat gespeichert werden, unabhängig davon, ob es sich um eine Datenbank, eine Datei oder einen verteilten Speicherserver handelt, was für den Clusteraufbau unerlässlich ist. Der nächste Artikel wird das Sitzungsproblem testen und lösen

Copyright-Erklärung: Dieser Artikel ist ein Originalartikel des Bloggers und darf nicht ohne die Erlaubnis des Bloggers reproduziert werden.

Das Obige stellt Nginx Tomcat für den Lastausgleich vor, einschließlich seiner Aspekte. Ich hoffe, es wird für Freunde hilfreich sein, die sich für PHP-Tutorials interessieren.