1. Une des caches traditionnelles (404)
Cette méthode consiste à diriger l'erreur 404 de nginx vers le backend, puis à utiliser proxy_store pour enregistrer la page renvoyée par le backend.
Configuration:
emplacement/{
racine /home/html/;#répertoire Accueil
expire 1j;#Délai d'expiration de la page Web
error_page 404 =200 /fetch$request_uri;#404 dirigé vers le répertoire /fetch
}
emplacement /fetch/ {#404Direct ici
internal;#Indique que ce répertoire n'est pas directement accessible en externe
expire 1j;#Délai d'expiration de la page Web
alias /home/html/;#L'adresse du système de fichiers du répertoire virtuel doit être cohérente avec l'emplacement/, proxy_store enregistrera le fichier dans ce répertoire
proxy_pass http://www.sudone.com/;#Adresse amont du backend, /fetch est également un proxy
proxy_set_header Accept-Encoding '';# Laissez le backend ne pas renvoyer le contenu compressé ( gzip ou deflate). L'enregistrement du contenu compressé entraînera des problèmes.
proxy_store on;#Spécifiez nginx pour enregistrer le fichier renvoyé par le proxy
proxy_temp_path /home/tmp;#Répertoire temporaire, ce répertoire doit se trouver dans la même partition de disque dur que /home/html
}
Lors de son utilisation, veuillez noter que nginx doit avoir l'autorisation d'écrire des fichiers dans /home/tmp et /home/html Sous Linux , nginx est généralement configuré pour s'exécuter en tant qu'utilisateur personne, donc ces deux répertoires doivent être chown personne. il doit être exclusif à l'utilisateur personne, bien sûr, vous pouvez également chmod 777, mais tous les administrateurs système expérimentés conseilleront de ne pas utiliser 777 avec désinvolture.
2. Cache traditionnel 2 (!-e)
Le principe est fondamentalement le même que celui du saut 404, mais en plus concis :
emplacement/{
racine /home/html/;
proxy_store activé ;
proxy_set_header Accept-Encoding '';
chemin_temp_proxy /home/tmp;
si ( !-f $request_filename )
{
proxy_pass http://www.sudone.com/;
}
}
Vous pouvez voir que cette configuration économise beaucoup de code par rapport à 404. Elle utilise !-f pour déterminer si le fichier demandé existe sur le système de fichiers. S'il n'existe pas, proxy_pass au backend, et le retour est également enregistré en utilisant. proxy_store.
Les deux caches traditionnels présentent fondamentalement les mêmes avantages et inconvénients :
Inconvénient 1 : les liens dynamiques avec des paramètres, tels que read.php?id=1, ne sont pas pris en charge. Étant donné que nginx enregistre uniquement le nom du fichier, ce lien est uniquement enregistré sous read.php dans le système de fichiers, afin que les utilisateurs puissent accéder à read. php?id= 2 renverra des résultats incorrects. En même temps, il ne prend pas en charge la page d'accueil sous la forme http://www.sudone.com/ et le répertoire secondaire http://www.sudone.com/download/, car nginx est très honnête et écrira une telle requête dans un fichier selon le système de liens, et ce lien est évidemment un répertoire, donc la sauvegarde échoue. Dans ces cas, une réécriture est nécessaire pour enregistrer correctement.
Inconvénient 2 : il n'existe aucun mécanisme d'expiration et de nettoyage du cache dans nginx. Ces fichiers mis en cache seront stockés de manière permanente sur la machine. S'il y a beaucoup de choses à mettre en cache, cela remplira tout l'espace du disque dur. À cette fin, vous pouvez utiliser un script shell pour le nettoyer régulièrement et vous pouvez écrire des programmes dynamiques tels que php pour effectuer des mises à jour en temps réel.
Inconvénient 3 : seuls 200 codes d'état peuvent être mis en cache, donc les codes d'état tels que 301/302/404 renvoyés par le backend ne seront pas mis en cache. Si un lien pseudo-statique avec un grand nombre de visites est supprimé, il continuera. pénétrer et provoquer L'arrière subit beaucoup de pression.
Inconvénient 4 : nginx ne sélectionnera pas automatiquement la mémoire ou le disque dur comme support de stockage. Bien entendu, il y aura un mécanisme de mise en cache des fichiers au niveau du système d'exploitation dans le système d'exploitation actuel, ce n'est donc pas nécessaire. vous inquiétez trop des lectures simultanées volumineuses si elles sont stockées sur le disque dur, ce qui provoque des problèmes de performances.
Les inconvénients du cache traditionnel de nginx résident également dans ses fonctionnalités différentes de celles des logiciels de mise en cache tels que Squid, il peut donc également être considéré comme son avantage. Dans les applications de production, il est souvent utilisé comme partenaire avec Squid. Squid est souvent incapable de bloquer les liens avec ?, mais nginx peut bloquer leur accès, comme : http://sudone.com/? et http://sudone. com / sera traité comme deux liens sur Squid, cela provoquera donc deux pénétrations ; tandis que nginx ne le sauvegardera qu'une seule fois, peu importe que le lien devienne http://sudone.com/?1 ou http://sudone.com/. ? 123, ne peut pas être mis en cache par nginx, protégeant ainsi efficacement l'hôte backend.
nginx enregistrera très fidèlement le formulaire de lien dans le système de fichiers, de sorte que pour un lien, vous puissiez facilement vérifier l'état et le contenu du cache sur la machine de cache, et vous pouvez également facilement coopérer avec d'autres gestionnaires de fichiers tels que rsync. est complètement une structure de système de fichiers.
Ces deux caches traditionnels peuvent enregistrer des fichiers dans /dev/shm sous Linux. Généralement, je fais cela afin que la mémoire système puisse être utilisée pour la mise en cache. Si la mémoire est utilisée, le contenu expiré sera nettoyé beaucoup plus rapidement. Lors de l'utilisation de /dev/shm/, en plus de pointer le répertoire tmp vers la partition /dev/shm, s'il y a un grand nombre de petits fichiers et répertoires, vous devez également modifier le nombre d'inodes et la capacité maximale de cette mémoire partition:
mount -o size=2500M -o nr_inodes=480000 -o noatime,nodiratime -o remount /dev/shm
La commande ci-dessus est utilisée sur une machine avec une mémoire 3G. Étant donné que la mémoire maximale par défaut de /dev/shm est la moitié de la mémoire système, soit 1 500 Mo, cette commande l'augmentera à 2 500 Mo. En même temps, le nombre de shm. Les inodes système ne suffisent peut-être pas par défaut. Mais ce qui est intéressant, c'est qu'ils peuvent être ajustés à volonté. L'ajustement ici est de 480 000, ce qui est un peu conservateur, mais c'est fondamentalement suffisant.
3. Cache basé sur le cache mémoire d
nginx prend en charge memcached , mais la fonction n'est pas particulièrement puissante et les performances sont toujours très bonnes.
emplacement /mem/ {
si ( $uri ~ "^/mem/([0-9A-Za-z_]*)$" )
{
définir $memcached_key "$1" ;
memcached_pass 192.168.1.2:11211 ;
}
expire 70 ;
}
Cette configuration fera pointer http://sudone.com/mem/abc vers la clé abc de memcached pour récupérer les données.
nginx ne dispose actuellement d'aucun mécanisme pour écrire sur memcached, donc l'écriture de données sur memcached doit être effectuée en utilisant le langage dynamique en arrière-plan. Vous pouvez utiliser 404 pour diriger vers le backend pour écrire des données.
4. Basé sur le plug-in tiers ncache
ncache est un bon projet développé par Sina Brothers. Il utilise nginx et memcached pour implémenter certaines fonctions similaires à la mise en cache Squid. Je n'ai aucune expérience dans l'utilisation de ce plug-in.
http://code.google.com/p/ncache/
5. La nouvelle fonction proxy_cache de nginx
À partir de la version nginx-0.7.44, nginx prend en charge une fonction de cache plus formelle similaire à Squid. Il est encore en phase de développement et la prise en charge est assez limitée. Ce cache enregistre le lien après l'avoir haché avec l'encodage md5, il peut donc prendre en charge. n'importe quel lien Dans le même temps, les statuts non-200 tels que 404/301/302 sont également pris en charge.
Configuration:
Configurez d'abord un espace de cache :
proxy_cache_path /path/to/cachelevels=1:2 keys_zone=NAME:10m inactive=5m max_size=2m clean_time=1m ;
Notez que cette configuration est en dehors de la balise du serveur. Levels spécifie que l'espace de cache comporte deux niveaux de répertoires de hachage. Le répertoire de premier niveau contient 1 lettre et le deuxième niveau contient 2 lettres. Le nom du fichier enregistré sera similaire à /path/. to/cache /c/29/b7f54b2df7773722d382f4809d65029c ; keys_zone donne un nom à cet espace, 10 min signifie que la taille de l'espace est de 10 Mo ; 5 min pour inactif signifie que le temps de cache par défaut est de 5 minutes, et 2 min pour max_size signifie qu'un seul fichier dépassant 2 min ne sera pas mis en cache ; clean_time spécifie une minute Videz le cache une fois.
emplacement/{
proxy_pass http://www.sudone.com/;
proxy_cache NOM ;#Utiliser NOM clés_zone
proxy_cache_valid 200 302 1h ; les codes d'état #200 et 302 sont enregistrés pendant 1 heure
proxy_cache_valid 301 1d ; le code d'état #301 est enregistré pendant un jour
proxy_cache_valid any 1m;#Les autres sont enregistrés pendant une minute
}