1. Einer der traditionellen Caches (404)
Diese Methode besteht darin, den 404-Fehler von Nginx an das Backend weiterzuleiten und dann Proxy_store zu verwenden, um die vom Backend zurückgegebene Seite zu speichern.
Konfiguration:
Standort/{
root /home/html/;#Home-Verzeichnis
läuft 1 Tag ab;#Ablaufzeit der Webseite
error_page 404 =200 /fetch$request_uri;#404 wird an das /fetch-Verzeichnis weitergeleitet
}
location /fetch/ {#404Direkt hier
internal;#Gibt an, dass auf dieses Verzeichnis extern nicht direkt zugegriffen werden kann
läuft 1 Tag ab;#Ablaufzeit der Webseite
alias /home/html/;#Die Dateisystemadresse des virtuellen Verzeichnisses muss mit dem Speicherort/ übereinstimmen. Proxy_store speichert die Datei in diesem Verzeichnis
Proxy_Pass http://www.sudone.com/;#Backend-Upstream-Adresse, /fetch ist auch ein Proxy
Proxy_set_header Accept-Encoding '';# Lassen Sie zu, dass das Backend keinen komprimierten Inhalt ( gzip oder deflate) zurückgibt. Das Speichern des komprimierten Inhalts führt zu Problemen.
Proxy_store on;#Geben Sie Nginx an, um die vom Proxy zurückgegebene Datei zu speichern
Proxy_temp_path /home/tmp;#Temporäres Verzeichnis, dieses Verzeichnis muss sich in derselben Festplattenpartition wie /home/html befinden
}
Beachten Sie bei der Verwendung, dass nginx über die Berechtigung zum Schreiben von Dateien in /home/tmp und /home/html verfügen muss. Unter Linux ist nginx im Allgemeinen für die Ausführung als Nobody-Benutzer konfiguriert, daher müssen diese beiden Verzeichnisse auf „nobody“ festgelegt werden Da es sich ausschließlich um den Nobody-Benutzer handelt, können Sie natürlich auch 777 chmod, aber alle erfahrenen Systemadministratoren raten davon ab, 777 nebenbei zu verwenden.
2. Traditioneller Cache 2 (!-e)
Das Prinzip ist im Grunde das gleiche wie beim 404-Sprung, aber prägnanter:
Standort/{
root /home/html/;
Proxy_store ein;
Proxy_set_header Accept-Encoding '';
Proxy-Temp-Pfad /home/tmp;
if ( !-f $request_filename )
{
Proxy_Pass http://www.sudone.com/;
}
}
Sie können sehen, dass diese Konfiguration im Vergleich zu 404 viel Code spart. Sie verwendet !-f, um festzustellen, ob die angeforderte Datei im Dateisystem vorhanden ist. Wenn sie nicht vorhanden ist, wird sie an das Backend übergeben und die Rückgabe wird ebenfalls mit gespeichert Proxy_Store.
Beide traditionellen Caches haben grundsätzlich die gleichen Vor- und Nachteile:
Nachteil 1: Dynamische Links mit Parametern wie read.php?id=1 werden nicht unterstützt. Da nginx nur den Dateinamen speichert, wird dieser Link nur als read.php im Dateisystem gespeichert, sodass Benutzer lesend zugreifen können. php?id= 2 wird falsche Ergebnisse zurückgeben. Gleichzeitig werden die Homepage in Form von http://www.sudone.com/ und das sekundäre Verzeichnis http://www.sudone.com/download/ nicht unterstützt, da Nginx sehr ehrlich ist und schreibt Eine solche Anfrage wird laut Linksystem in eine Datei geschrieben, und dieser Link ist offensichtlich ein Verzeichnis, sodass das Speichern fehlschlägt. In diesen Fällen ist zum korrekten Speichern ein Umschreiben erforderlich.
Nachteil 2: Es gibt keinen Mechanismus zum Ablaufen und Bereinigen des Caches in Nginx. Diese zwischengespeicherten Dateien werden dauerhaft auf dem Computer gespeichert. Wenn viele Dinge zwischengespeichert werden müssen, wird der gesamte Festplattenspeicher belegt. Zu diesem Zweck können Sie ein Shell-Skript verwenden, um es regelmäßig zu bereinigen, und Sie können dynamische Programme wie PHP schreiben, um Echtzeit-Updates durchzuführen.
Nachteil 3: Es können nur 200 Statuscodes zwischengespeichert werden, sodass vom Backend zurückgegebene Statuscodes wie 301/302/404 nicht zwischengespeichert werden. Wenn ein pseudostatischer Link mit einer großen Anzahl von Besuchen gelöscht wird, wird er fortgesetzt eindringen und verursachen, dass das hintere Ende großen Druck ausübt.
Nachteil 4: Nginx wählt nicht automatisch Speicher oder Festplatte als Speichermedium aus. Natürlich gibt es im aktuellen Betriebssystem einen Datei-Caching-Mechanismus auf Betriebssystemebene, sodass dies nicht erforderlich ist Sorgen Sie sich zu sehr um große gleichzeitige Lesevorgänge, wenn diese auf der Festplatte gespeichert werden und dadurch Leistungsprobleme verursacht werden.
Die Nachteile des herkömmlichen Caches von Nginx liegen auch darin, dass er sich in seinen Funktionen von Caching-Software wie Squid unterscheidet, sodass er auch als Vorteil angesehen werden kann. In Produktionsanwendungen wird es oft als Partner von Squid verwendet und kann häufig keine Links mit ? blockieren, aber Nginx kann deren Zugriff blockieren, wie zum Beispiel: http://sudone.com/? com / wird auf Squid als zwei Links behandelt, sodass es zu zwei Penetrationen kommt, während Nginx es nur einmal speichert, unabhängig davon, ob der Link http://sudone.com/?1 oder http://sudone.com/ wird. ? 123, kann von Nginx nicht zwischengespeichert werden, wodurch der Backend-Host effektiv geschützt wird.
Nginx speichert das Linkformular sehr genau im Dateisystem, sodass Sie den Cache-Status und den Inhalt eines Links auf dem Cache-Computer problemlos überprüfen und auch problemlos mit anderen Dateimanagern wie rsync zusammenarbeiten können ist vollständig eine Dateisystemstruktur.
Beide herkömmlichen Caches können unter Linux Dateien in /dev/shm speichern, damit der Systemspeicher zum Caching verwendet werden kann. Wenn der Speicher verwendet wird, wird der Ablaufinhalt viel schneller bereinigt. Wenn Sie /dev/shm/ verwenden, müssen Sie zusätzlich zum Verweisen des tmp-Verzeichnisses auf die /dev/shm-Partition bei einer großen Anzahl kleiner Dateien und Verzeichnisse auch die Anzahl der Inodes und die maximale Kapazität dieses Speichers ändern Partition:
mount -o size=2500M -o nr_inodes=480000 -o noatime,nodiratime -o remount /dev/shm
Der obige Befehl wird auf einem Computer mit 3G-Speicher verwendet. Da der standardmäßige maximale Speicher von /dev/shm die Hälfte des Systemspeichers beträgt, also 1500 MB, erhöht dieser Befehl ihn auf 2500 MB Standardmäßig reichen die System-Inodes möglicherweise nicht aus. Das Interessante ist jedoch, dass die Einstellung hier 480000 beträgt, was etwas konservativ ist, aber im Grunde ausreichend ist.
3. Cache basierend auf Mem -Cache d
Nginx bietet eine gewisse Unterstützung für Memcached , aber die Funktion ist nicht besonders stark und die Leistung ist immer noch sehr gut.
Standort /mem/ {
if ( $uri ~ "^/mem/([0-9A-Za-z_]*)$" )
{
setze $memcached_key "$1";
memcached_pass 192.168.1.2:11211;
}
läuft 70 ab;
}
Diese Konfiguration verweist http://sudone.com/mem/abc auf den Schlüssel abc von memcached, um Daten abzurufen.
Nginx verfügt derzeit über keinen Mechanismus zum Schreiben in Memcached, daher muss das Schreiben von Daten in Memcached mithilfe der dynamischen Sprache im Hintergrund erfolgen. Sie können 404 verwenden, um zum Schreiben von Daten direkt an das Backend zu gelangen.
4. Basierend auf dem Plug-in ncache eines Drittanbieters
ncache ist ein gutes Projekt, das von Sina Brothers entwickelt wurde. Es verwendet Nginx und Memcached, um einige Funktionen zu implementieren, die dem Squid-Caching ähneln. Sie können sich auf Folgendes beziehen:
http://code.google.com/p/ncache/
5. Die neu entwickelte Proxy_cache-Funktion von Nginx
Ab der Version nginx-0.7.44 unterstützt nginx eine formellere Cache-Funktion, die Squid ähnelt. Sie befindet sich noch in der Entwicklungsphase und die Unterstützung ist recht begrenzt. Dieser Cache speichert den Link nach dem Hashing mit der MD5-Codierung, sodass er unterstützt werden kann Jeder Link wird ebenfalls unterstützt.
Konfiguration:
Konfigurieren Sie zunächst einen Cache-Speicherplatz:
Proxy_cache_Pfad /Pfad/zu/Cache Levels=1:2 Keys_zone=NAME:10m inaktiv=5m max_size=2m clean_time=1m;
Beachten Sie, dass diese Konfiguration außerhalb des Server-Tags liegt und angibt, dass der Cache-Speicherplatz über zwei Ebenen von Hash-Verzeichnissen verfügt. Das Verzeichnis der ersten Ebene besteht aus 2 Buchstaben. Der gespeicherte Dateiname ähnelt /path/. to/cache /c/29/b7f54b2df7773722d382f4809d65029c; clean_time gibt eine Minute an. Leeren Sie den Cache einmal.
Standort/{
Proxy_Pass http://www.sudone.com/;
Proxy_cache NAME;#Namensschlüssel_zone verwenden
Proxy_cache_valid 200 302 1h;#200- und 302-Statuscodes werden 1 Stunde lang gespeichert
Proxy_cache_valid 301 1d;#301 Statuscode wird für einen Tag gespeichert
Proxy_cache_valid any 1m;#Andere werden eine Minute lang gespeichert
}