Detaillierte Erläuterung der Cache-Konfiguration von Nginx Proxy_Cache

Vorwort:

Aufgrund meiner Arbeit beschäftige ich mich mit dem Bereich Online-Live-Streaming und für die Wiedergabe und das Herunterladen von Videos sind einige Technologien zum Herunterladen von Videos erforderlich. Beim Herunterladen eines kompletten Videos besteht der derzeit gängige Ansatz auf dem Markt darin, den gesamten Videostream aufzuteilen, auf einem Dateiserver zu speichern und ihn dann wiederzugeben, wenn der Benutzer ihn ansehen möchte. Durch die Rücksendung eines Videos an den Quellserver wird der Dateiserver aufgefordert, das Video Stück für Stück aufzuteilen und es dem Benutzer zur Wiedergabe zurückzugeben.

Heute konzentrieren wir uns auf die Konfiguration des Ursprungsserver-Cache und eine sinnvolle Caching-Strategie.

Am Beispiel der Cache-Konfiguration für den Quellserver wird ein vollständiger Satz von Cache-Konfigurationsmechanismen ausführlich erläutert, der auf alle anderen Cache-Konfigurationsszenarien angewendet werden kann.

Die heutige Erklärung gliedert sich in vier Punkte:

• Was ist die Aufgabe des Back-to-Origin-Servers?
• Cache zum Ursprungsserver muss hinzugefügt werden
• So konfigurieren Sie den Cache
• So konfigurieren Sie einen vollständigen Caching-Mechanismus für Geschäftsszenarien
  

Zurück zum Ursprungsserver:

Der Back-to-Source-Server wird in der folgenden Beschreibung als Quellserver bezeichnet. Wie in der Abbildung dargestellt, spannt er sich während des Dateidownloadvorgangs zwischen dem CDN und dem Dateiserver auf und dient als Download-Hub.

Quellstationsarchitektur: Die Quellstation ist eine Webserverarchitektur von nginx+php, wie in der Abbildung dargestellt:

Wenn der Ursprungsserver jedoch lediglich die Anforderung empfängt, die Ressource herunterlädt und sie dann zurückgibt, treten zwangsläufig die folgenden nicht optimierten Probleme auf:

1. CDN kann mehrere Return-to-Source-Phänomene aufweisen

2. Die Quellstation lädt dieselbe Ressource mehrmals herunter, was zu einer Verschwendung von Netzwerkverkehrsbandbreite und unnötigem Zeitaufwand führt.

Um diese Probleme zu optimieren, ist daher eine Cache-Schicht für die Quellsite erforderlich. Die Cache-Strategie verwendet das mit nginx gelieferte Proxy_Cache-Modul.

Proxy_cache-Prinzip:

Das Funktionsprinzip des Proxy_Cache-Moduls ist in der Abbildung dargestellt:

So konfigurieren Sie das Proxy_Cache-Modul

Fügen Sie der Datei nginx.conf den folgenden Code hinzu:

http{
  ......
  Proxy_Cache_Pfad/Daten/nginx/tmp-test Ebenen=1:2 Schlüsselzone=tmp-test:100m inaktiv=7d max_size=1000g;
}

Code-Erklärung:

proxy_cache_path Cache-Dateipfad

levels legt die Verzeichnishierarchie der Cache-Dateien fest; levels=1:2 bedeutet zwei Verzeichnisebenen.

keys_zone legt den Cachenamen und die gemeinsam genutzte Speichergröße fest

inaktiv Wenn innerhalb einer bestimmten Zeit niemand darauf zugreift, wird es gelöscht

max_size Der maximale Cache-Speicherplatz. Wenn der Cache-Speicherplatz voll ist, wird standardmäßig die Ressource mit der längsten Cache-Zeit überschrieben.

Starten Sie nginx nach Abschluss der Konfiguration neu. Wenn kein Fehler gemeldet wird, wird der konfigurierte Proxy-Cache wirksam.

Überprüfen Sie das Verzeichnis proxy_cache_path/data/nginx/ und Sie werden feststellen, dass ein tmp-test-Ordner generiert wird.

So verwenden Sie proxy_cache

Fügen Sie den folgenden Code zu Ihrer entsprechenden Nginx-Vhost-Serverkonfigurationsdatei hinzu:

Standort /tmp-test/ {
 temporärer Proxy-Cache-Test;
 Proxy_Cache_gültig 200 206 304 301 302 10d;
 Proxy-Cache-Schlüssel $uri;
 Proxy_set_header Host $host:$server_port;
 Proxy_Set_Header X-Real-IP $Remote_Addr;
 proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for;
 Proxy-Passwort: http://127.0.0.1:8081/media_store.php/tmp-test/;
}

Beschreibung des Konfigurationselements: Proxy_cache tmp-test verwendet die entsprechende Cache-Konfiguration mit dem Namen tmp-test

proxy_cache_valid 200 206 304 301 302 10d; httpcode 200 für 10 Tage zwischenspeichern

proxy_cache_key $uri definiert den eindeutigen Schlüssel für den Cache und verwendet den eindeutigen Schlüssel für den Hash-Zugriff

proxy_set_header passt den HTTP-Header an, der an den realen Backend-Server gesendet werden soll.

proxy_pass bezieht sich auf den nach dem Proxy weitergeleiteten Pfad. Beachten Sie, ob das abschließende / erforderlich ist.

An diesem Punkt wurde die grundlegendste Proxy-Cache-Funktion erfolgreich konfiguriert. Wenn die URI erfolgreich mit dem Standort übereinstimmt, wird der Proxy-Cache wirksam.

Nach dem Hinzufügen von proxy_cache ändert sich der Anforderungsprozess:

1. Erstbesuch:

Beim ersten Zugriff konnte proxy_cache die entsprechende Cache-Datei nicht finden (Cache-Fehler). Wenn die erste Anforderung abgeschlossen ist, behält proxy_cache den Cache:

2. Speichern Sie den Cache, wie in der Abbildung gezeigt:

3. Wenn dieselbe URL zum zweiten Mal aufgerufen wird und dieselbe Datei erneut auf der Ursprungssite eintrifft, findet proxy_cache die entsprechende Cache-Datei (trifft den Cache-HIT) und gibt sie direkt an den Anforderer zurück, ohne das PHP-Programm erneut auszuführen, wie in der Abbildung gezeigt:

Eine Frage stellen:

An diesem Punkt sind die grundlegendsten Proxy-Cache-Konfigurationen und die Einführung in den Zugriffsprozess abgeschlossen. Die grundlegendsten Konfigurationen können unsere Geschäftsanforderungen jedoch häufig nicht erfüllen. Wir stellen häufig die folgenden Fragen und Anforderungen:

1. Cache-Dateien müssen aktiv bereinigt werden
2. Der Schreibpfad ist eine Festplatte. Was soll ich tun, wenn die Festplatte voll ist?
3. So aktivieren Sie die Quellsite, um Breakpoint-Resume-Downloads und Cache-Strategien für Breakpoint-Resume-Downloads zu unterstützen
4. Wenn die Endbereichsanforderung (segmentierte Downloads) eine große Ressource mit derselben URI anfordert, wie können die Anforderungen unterschieden werden?
5. Sie müssen dem Anforderer auch die Ablaufzeit der Ressource mitteilen
6. Protokollstatistiken: Wie konfiguriert man Treffer- und Fehlfeldfelder und wie erstellt man Statistiken?

Wir werden die oben genannten Fragen nacheinander beantworten.

Problem 1: Cache aktiv leeren

Verwendung: nginx proxy_cache_purge-Modul, das paarweise mit proxy_cache auftritt und die entgegengesetzte Funktion hat. Entwurfsmethode: Starten Sie in nginx einen anderen Server. Wenn Sie den Cache der Antwortressourcen bereinigen müssen, greifen Sie auf dem lokalen Computer auf diesen Server zu. Beispiel: Greifen Sie auf 127.0.0.1:8083/tmp-test/TL39ef7ea6d8e8d48e87a30c43b8f75e30.txt zu, um die Cache-Datei der Ressource zu bereinigen. Konfigurationsmethode:

Standort /tmp-test/ {
        allow 127.0.0.1; //Nur diesem Rechner Zugriff erlauben deny all; //Alle anderen IP-Adressen nicht zulassen
        proxy_cache_purge tmp-test $uri; //Cache leeren}

proxy_cache_purge: Cache-Bereinigungsmodul tmp-test: angegebene key_zone $uri: angegebene Parameter zum Generieren des Schlüssels proxy_cache_purge Cache-Bereinigungsprozess, wie in der Abbildung dargestellt:

Frage 2: Was soll ich tun, wenn die Cache-Dateifestplatte voll ist?

Da der Schreibpfad ein einzelnes Verzeichnis ist, kann nur auf eine Festplatte geschrieben werden. Eine Festplatte ist bald voll. Es gibt zwei Möglichkeiten, dieses Problem zu lösen:

1. Wie kombiniere ich mehrere Festplatten zu einem Festplatten-Array? Der Nachteil ist: Der tatsächliche Speicherplatz verringert sich.

2. Verwenden Sie geschickt die Verzeichnisstruktur von proxy_cache_path. Da Ebenen = 1:2 sind, ist die Verzeichnisstruktur der Cache-Datei zweischichtig und der Name jeder Schicht des Verzeichnisses wird durch die Hash-Funktion generiert. Wie in der Abbildung gezeigt:

Es gibt insgesamt 16*16*16=4096 Dateiverzeichnisse. Erstellen Sie einen Softlink zum Verzeichnis der ersten Ebene und einen Softlink 0-f zum angegebenen Datenträgerverzeichnis, das Sie benötigen, wie in der Abbildung gezeigt:

Durch die Softlink-Methode wird erreicht, dass die Verzeichnisse auf verschiedenen Datenträgern als tatsächliche Pfade zum Speichern der Daten verwendet werden. Dadurch wird das Problem gelöst, dass mehrere Datenträger verwendet werden, aber ein Datenträger voll ist.

Frage 3: Unterstützungsbereich (Haltepunkt fortsetzen)

Nach dem Hinzufügen des Cache-Proxys schlägt die vom Client initiierte Bereichsanforderung fehl, wie in der folgenden Abbildung dargestellt:

Die Gründe, warum der Bereichsparameter nicht an die nächste Ebene übergeben werden kann, sind folgende:

Wenn der Cache-Proxy die HTTP-Anfrage an den Backend-Server weiterleitet, ändert sich der HTTP-Header und einige Parameter im Header werden gelöscht. Der Bereichsparameter wurde abgebrochen, was dazu führte, dass der Back-End-Nginx-Server den Bereichsparameter nicht erhielt, was letztendlich zum Fehlschlagen des Segment-Downloads führte. Daher ist es notwendig, den Proxy-Weiterleitungsheader zu konfigurieren. Zum Beispiel:

Standort /tmp-test/ {
        temporärer Proxy-Cache-Test;
        Proxy_Cache_gültig 200 206 304 301 302 10d;
        Proxy-Cache-Schlüssel $uri;
        proxy_set_header Bereich $http_range;
        Proxy-Passwort http://127.0.0.1:8081/media_store.php/tmp-test/;
}

Die Bedeutung des roten Teils: Setzen Sie den Bereichswert ($http_range) in der http-Anfrage in den vom Proxy weitergeleiteten http-Anforderungsheader als Wert des Parameterbereichs.

Frage 4: Wenn das Laden von Bereichen unterstützt wird, muss proxy_cache_key neu konfiguriert werden:

Wenn die Anforderungsseite per Range eine große Ressource mit derselben URI anfordert (segmentierter Download), wie identifiziert der Proxy-Cache den der Ressource entsprechenden Schlüssel? Da nginx wie folgt konfiguriert ist: proxy_cache_key $uri, wobei URI als Schlüssel verwendet wird, wird derselbe URI als Schlüssel verwendet, wenn es sich bei der Anforderung um eine normale Anforderung oder eine Bereichsanforderung handelt. proxy_cache führt wahrscheinlich zu einer Fehlerrückgabe. Wie in der folgenden Abbildung dargestellt:

Die Lösung lautet wie folgt: Ändern Sie proxy_cache_key und konfigurieren Sie proxy_cache_key $http_range$uri. Dadurch wird das Problem der Schlüsseleindeutigkeit gelöst. Dadurch können Anomalien im zuerst abgerufenen Inhalt und im später abgerufenen zwischengespeicherten Inhalt verhindert werden, unabhängig davon, ob es sich um eine normale Anforderung oder eine Anforderung aus einem anderen Bereich handelt.

Frage 5: So konfigurieren Sie die Rückgabeablaufzeit

Der Anforderer muss durch Rückgabe der Ablaufzeit angeben, welche Ressourcen zwischengespeichert werden müssen und welche nicht.

Um zu verhindern, dass der Anforderer die geteilten Ressourcen als vollständige Ressourcen zwischenspeichert, müssen wir die Ablaufzeit für normale Anforderungen zurückgeben und nicht die Ablaufzeit für Bereichsanforderungen. Um dieses Problem zu lösen, können Sie nginx wie folgt konfigurieren:

Standort /media_store.php {
   fastcgi_pass 127.0.0.1:9000;
   fastcgi_index media_store.php;
   fastcgi_param SCRIPT_FILENAME $Dokumentstammsatz/$fastcgi_script_name;
   fastcgi_params einschließen;
   wenn ( $http_range = '' ) {
     läuft in 2592000s ab;
   }
}

Fügen Sie die Beurteilung von $http_range am Speicherort nach proxy_pass hinzu, und expires gibt die Ablaufzeit an. 2592000s bezieht sich auf die Cache-Ablaufzeit.

Frage 7: Wie kann ich Cache-Treffer im HTTP-Header widerspiegeln und im Nginx-Protokoll anzeigen?

Lösung:

Verwenden der nginx-Variable $upstream_cache_status: Diese Variable stellt den Status des Cache-Treffers dar.

Wenn es trifft, ist es ein TREFFER; wenn es verfehlt, ist es ein VERFEHLT

Fügen Sie die zurückgegebene Nginx-Serverkonfiguration hinzu:

add_header Nginx-Cache "$upstream_cache_status";

Fügen Sie in nginxlog hinzu:

log_format combinedio …$upstream_cache_status;

Screenshot des HTTP-Return-Headers:

Screenshot des Nginx-Protokolls:

Zusammenfassen:

Dies ist das Ende der Einführung in einen vollständigen Satz von Cache-Strategien. Diese Lösung implementiert nicht nur die grundlegende Cache-Konfiguration, sondern löst auch Probleme, die in tatsächlichen Szenarioanwendungen auftreten, wie z. B. Festplattenerweiterung, Cache-Bereinigung, Wiederaufnahme von Haltepunkten, Cache-Ablaufzeit, Cache-Trefferaufforderungen usw. Solange diese Lösung flexibel verwendet wird, kann sie grundsätzlich die Anforderungen erfüllen, unabhängig davon, wie komplex das Szenario ist. Das Obige sind die Fallstricke, auf die ich bei meiner Arbeit gestoßen bin, und ich habe die Ergebnisse kontinuierlich verbessert und zusammengefasst. Ich hoffe, sie werden den Lesern hilfreich sein.

Dies ist das Ende dieses Artikels über die detaillierte Konfiguration von nginx proxy_cache. Weitere relevante Inhalte zu nginx proxy_cache finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den verwandten Artikeln weiter unten. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!