Utilisation et configuration de nginx
- 1. Qu'est-ce que nginx
- 2.module nginx
- Scénarios d'application 3.nginx :
- 4. Installation de nginx
- 5. Commandes communes de Nginx
- 6. Structure du fichier de configuration
- 7. Hôte virtuel Nginx
- 8. Le rôle de la localisation
-
- 1.règles de localisation
- 2. Préparation
- 3. Correspondance de préfixe
- 4. Correspondance exacte
- 5. Correspondance exacte du préfixe
- 6. Expressions régulières
- 7. Correspondance universelle
- 8. Comparaison des priorités
- 9. Exemple complet
- 10. Ordre de correspondance
- 11.processus de correspondance de chemin
- 12. Suggestions d'utilisation pratiques
- 9.Proxy inverse Nginx
- 10. Équilibrage de charge Nginx
- 11. Cas courants de Nginx
1. Qu'est-ce que nginx
1. Définition de nginx : Nginx est un service HTTP et reverse proxy hautes performances, ainsi qu'un service IMAP/POP3/SMTP
- Traiter rapidement les demandes de réponse
- Connexions simultanées élevées
- faible consommation de mémoire
- A une grande fiabilité
- Haute évolutivité
- Déploiement à chaud
La conception séparée du processus de gestion principal et du processus de travail permet à Nginx d'avoir une fonction de déploiement à chaud.Il peut mettre à niveau le fichier exécutable Nginx dans le cadre d'un service ininterrompu 7 × 24 heures, et peut également modifier la configuration sans arrêter le service. fichiers, remplacer les fichiers journaux et autres fonctions
2. Capable de traiter un grand nombre de connexions parallèles : Nginx peut prendre en charge 50 000 connexions parallèles dans les résultats des tests officiels, mais dans les opérations réelles, il peut prendre en charge 20 000 à 40 000 connexions parallèles. En revanche, le nombre de connexions parallèles de Tomcat n'est que de quelques centaines.
3.Par rapport à Apache
Nginx a été écrit dans le but exprès de surpasser les performances du serveur Web Apache
- Nginx fournit des fichiers statiques prêts à l'emploi, utilise beaucoup moins de mémoire qu'Apache et peut gérer environ quatre fois plus de requêtes par seconde qu'Apache. Les performances en faible concurrence sont comparables à celles d'Apache, parfois même inférieures, mais en cas de concurrence élevée, Nginx peut maintenir une faible consommation de ressources et des performances élevées. Il existe également une conception hautement modulaire et l'écriture du module est simple et concise.
- Le coût de ce gain de performances est une flexibilité réduite, telle que la possibilité de remplacer les paramètres d'accès à l'échelle du système pour chaque fichier (Apache utilise des fichiers .htaccess pour ce faire, et Nginx n'a pas de telle fonctionnalité intégrée). L'ajout de modules tiers à Nginx nécessite de recompiler l'application à partir des sources avec des modules liés statiquement. Ce problème a été partiellement résolu dans la version 1.9.11 avec l'ajout du chargement dynamique des modules. Cependant, les modules doivent toujours être compilés en même temps que Nginx, et tous les modules ne sont pas compatibles avec ce système - certains nécessitent l'ancien processus de liaison statique.
4.Apache contre Nginx
5. Comparaison des serveurs Web couramment utilisés
| Comparer les éléments\serveur | Apache | Nginx | Lumièretpd |
|---|---|---|---|
| Procuration | très bien | très bien | en général |
| Réécrivain | bien | très bien | en général |
| Fcgi | pas bon | bien | très bien |
| Déploiement à chaud | pas de support | soutien | pas de support |
| Pression du système | très grand | très petit | plus petit |
| la stabilité | bien | très bien | pas bon |
| sécurité | bien | en général | en général |
| Traitement de fichiers statiques | en général | très bien | bien |
| proxy inverse | en général | très bien | en général |
2.module nginx
1. La conception modulaire globale est une caractéristique majeure de Nginx, et même la fonction principale du serveur http est également un module
2. Les modules de l'ancienne version de Nginx sont statiques. L'ajout et la suppression de modules nécessitent une recompilation de Nginx. Les versions 1.9.11 et plus récentes prennent déjà en charge le chargement dynamique des modules.
3. Une conception hautement modulaire constitue la base architecturale de Nginx. Le serveur Nginx est décomposé en plusieurs modules. Chaque module est un module fonctionnel et n'est responsable que de ses propres fonctions. Les modules suivent strictement le principe de "haute cohésion et faible couplage". ". en principe
4. Le schéma du module est le suivant :
5. Module principal : Le module principal est un module essentiel au fonctionnement normal du serveur Nginx. Il fournit des fonctions de base telles que la journalisation des erreurs, l'analyse des fichiers de configuration, le mécanisme piloté par les événements et les processus. gestion.
6. Module HTTP standard : Le module HTTP standard fournit des fonctions liées à l'analyse du protocole HTTP, telles que : la configuration du port, les paramètres d'encodage des pages Web, les paramètres d'en-tête de réponse HTTP, etc.
7. Module HTTP optionnel : Le module HTTP optionnel est principalement utilisé pour étendre les fonctions HTTP standard, permettant à Nginx de gérer certains services spéciaux, tels que : la transmission multimédia Flash, l'analyse des requêtes GeoIP, le support SSL, etc.
8. Module de service de messagerie : Le module de service de messagerie est principalement utilisé pour prendre en charge le service de messagerie de Nginx, notamment la prise en charge du protocole POP3, du protocole IMAP et du protocole SMTP.
9. Modules tiers : Les modules tiers sont utilisés pour étendre les applications du serveur Nginx et compléter les fonctions définies par le développeur, telles que : la prise en charge de Json, la prise en charge de Lua, etc.
Scénarios d'application 3.nginx :
Nginx est un serveur HTTP et un serveur proxy inverse gratuit, open source et hautes performances ; c'est également un serveur proxy IMAP, POP3 et SMTP ; Nginx peut être utilisé comme serveur HTTP pour la publication et le traitement de sites Web, et Nginx peut être utilisé en tant que serveur proxy inverse.Mise en œuvre de l'équilibrage de charge proxy
1. À propos de l'agence : À l'heure actuelle, deux rôles sont impliqués, l'un est le rôle d'agent et l'autre est le rôle cible. Le processus dans lequel le rôle d'agent accède au rôle cible pour effectuer certaines tâches via cet agent est appelé agent. processus opérationnel ; tout comme un monopole dans la vie Boutique ~ Un client achète une paire de chaussures dans un magasin adidas. Ce magasin est un agent. Le rôle d'agent est le fabricant adidas et le rôle cible est l'utilisateur.
2. Forward proxy : "Il agit comme un proxy pour le client et fait des requêtes au nom du client. " C'est un serveur entre le client et le serveur d'origine. Afin d'obtenir du contenu du serveur d'origine, le client envoie un requête au proxy. Une requête spécifie la cible (serveur d'origine), puis le proxy transmet la requête au serveur d'origine et renvoie le contenu obtenu au client. Le client doit définir certains paramètres spéciaux pour utiliser le proxy de transfert.
Donnez une châtaigne :
Dans l'environnement réseau actuel, si nous devons accéder à certains sites Web étrangers pour des raisons techniques, vous constaterez que nous ne pouvons pas accéder à certains sites Web étrangers via un navigateur. À l'heure actuelle, tout le monde peut utiliser une opération FQ Pour accéder, la méthode principale de FQ consiste à trouver un serveur proxy qui peut accéder aux sites Web étrangers. Nous envoyons la demande au serveur proxy, et le serveur proxy accède au site Web étranger, puis nous transmet les données consultées.
Le mode proxy ci-dessus est appelé proxy de transfert. La plus grande caractéristique du proxy de transfert est que le client est très clair sur l'adresse du serveur auquel il souhaite accéder ; le serveur sait seulement de quel serveur proxy provient la requête, mais pas de quel client spécifique elle provient. from; forward proxy Le mode masque ou cache les informations réelles du client. Regardons un diagramme schématique :
le client doit configurer un serveur proxy de transfert. Bien entendu, le principe est de connaître l'adresse IP du serveur proxy de transfert et le port du programme agent. Comme le montre l'image
3. Objectif du forward proxy :
- Accédez à des ressources auparavant inaccessibles, telles que Google
- Peut être mis en cache pour accélérer l'accès aux ressources
- Autoriser l’accès des clients et s’authentifier en ligne
- L'agent peut enregistrer les enregistrements d'accès des utilisateurs (gestion du comportement en ligne) et masquer les informations des utilisateurs de l'extérieur.
4. Reverse proxy : "Il fait office de proxy pour le serveur et reçoit les requêtes au nom du serveur. " Il est principalement utilisé dans le cas de déploiement distribué de clusters de serveurs. Le reverse proxy masque les informations du serveur.
Donnez une châtaigne :
Par exemple, le nombre de visiteurs se connectant quotidiennement au site à la même heure a explosé. Un seul serveur est loin de pouvoir satisfaire le désir d'achat croissant des gens. A cette époque, un terme familier apparaît : déploiement distribué ; Autrement dit, le problème de la limitation du nombre de visiteurs est résolu en déployant plusieurs serveurs ; la plupart des fonctions d'un certain site Web sont également implémentées directement en utilisant Nginx pour le proxy inverse, et en encapsulant Nginx et d'autres composants, il a un nom fantaisiste : Tengine, les enfants intéressés peuvent visiter le site officiel de Tengine pour consulter des informations spécifiques : http://tengine.taobao.org/
Alors, comment le proxy inverse implémente-t-il les opérations de cluster distribué ?Regardons d'abord un diagramme schématique
1. Grâce au diagramme ci-dessus, vous pouvez voir clairement que lorsque plusieurs clients envoient des requêtes au serveur, le serveur Nginx Après l'avoir reçu, il est distribué au serveur de traitement d'affaires principal pour le traitement selon certaines règles. À ce stade, la source de la demande est claire, c'est-à-dire le client, mais il n'est pas clair quel serveur gère la demande. Nginx joue le rôle de C'est un rôle de proxy inverse
2. Le client ignore l'existence du proxy. Le proxy inverse est transparent pour le monde extérieur. Les visiteurs ne savent pas qu'ils accèdent à un proxy car le client peut y accéder sans aucune configuration.
5. Le rôle du proxy inverse :
- Pour assurer la sécurité de l'intranet, le proxy inverse est généralement utilisé comme adresse d'accès au réseau public et le serveur Web est l'intranet.
- Équilibrage de charge, optimisez la charge du site Web via le serveur proxy inverse
6. Scénario de projet : Normalement, lorsque nous exploitons un projet réel, un proxy direct et un proxy inverse sont susceptibles d'exister dans un scénario d'application. La demande du client proxy proxy direct pour accéder au serveur cible, et le serveur cible est un serveur d'intérêt simple inversé. , proxy inverse plusieurs serveurs de traitement d'entreprise réels, la topologie spécifique est la suivante
7. La différence entre les deux : Prenez une image pour illustrer la différence entre le proxy direct et le proxy inverse, comme le montre la figure
- Dans le proxy direct, le proxy et le client appartiennent au même réseau local (dans la case de la figure), ce qui masque les informations client.
- Dans le proxy inverse, Proxy et Serveur appartiennent au même LAN (dans l'encadré de la figure), ce qui masque les informations du serveur
- En fait, ce que fait Proxy dans les deux proxys est d'envoyer et de recevoir des requêtes et des réponses au nom du serveur. Cependant, d'un point de vue structurel, la gauche et la droite sont interchangées, donc la méthode proxy qui est apparue plus tard est appelée une méthode proxy inversée. Procuration.
4. Installation de nginx
Il existe deux façons d'installer nginx sous centos, l'une est yum install et l'autre est la compilation et l'installation. Bien sûr, la première méthode est plus simple, mais elle présente certains inconvénients. Par exemple, nous devons utiliser des modules tiers spécifiques . , à ce stade, vous devez utiliser la compilation et l'installation.
1.Installer la marque
yum -y install autoconf automake make
2.Installer g++
yum -y install gcc gcc-c++
3. Installez les bibliothèques dont dépend nginx
yum -y install wget pcre pcre-devel zlib zlib-devel openssl openssl-devel
4. Téléchargez nginx
wget http://nginx.org/download/nginx-1.24.0.tar.gz
5. Décompressez
tar -zxvf nginx-1.24.0.tar.gz
6. Compilez et installez (entrez dans le répertoire nginx)
./configure --prefix=/root/nginx # 编译源码，指定安装位置
make && make install
7. Configurer les variables d'environnement
- Modifier le fichier de profil
vi /etc/profile
- Ajouter l'emplacement nginx dans la dernière ligne
export PATH=$PATH:/root/nginx/sbin
- Actualiser les variables d'environnement
source /etc/profile
8. Désactivez le pare-feu
- Fermé temporairement
systemctl stop firewalld.service
- définitivement fermé
systemctl disable firewalld.service
5. Commandes communes de Nginx
1. Commencez
#不指定启动配置文件，默认为NGINX_HOME/conf/nginx.conf
nginx
# 如果指定配置文件
nginx -c nginx.conf
2. Arrêtez
nginx -s stop
3.Quitter
nginx -s quit
4.Fermer
# 查看nginx进程号
ps -aux | grep nginx
# 杀掉进程
kill -9 nginx
5. Rechargez le fichier de configuration
nginx -s reload
6. Vérifiez si le fichier de configuration est correct
nginx -t -c /路径/nginx.conf
7. Afficher le fichier de configuration
nginx -T
8. Vérifiez les informations de version de nginx
nginx -v
6. Structure du fichier de configuration
1. Structure du fichier
1. Le fichier de configuration Nginx se trouve généralement dans le répertoire conf sous le répertoire d'installation de Nginx. L'ensemble du fichier est composé de blocs. Chaque bloc est représenté par des accolades "{}". D'autres niveaux de bloc peuvent être imbriqués dans le bloc, parmi lesquels main La couche est le niveau le plus élevé
2. Le fichier de configuration nginx comprend principalement 4 parties, principale (paramètres globaux), serveur (paramètres de l'hôte), en amont (paramètres du serveur en amont, principalement proxy inverse, configuration liée à l'équilibrage de charge) et emplacement (correspondances d'URL un emplacement spécifique) paramètres), chaque section contient plusieurs instructions
- Les paramètres de la section Principale affectent les paramètres de toutes les autres sections ;
- La partie serveur est principalement utilisée pour spécifier le nom de domaine hôte de la machine virtuelle, l'adresse IP et le port ;
- Les instructions en amont sont utilisées pour configurer une série de serveurs back-end, configurer le proxy inverse et l'équilibrage de charge des serveurs back-end ;
- La partie Emplacement est utilisée pour faire correspondre l'emplacement de la page Web (par exemple, avec le répertoire "/", "/images", etc.)
3. La relation entre eux est que le serveur hérite de main, l'emplacement hérite du serveur et en amont n'hérite ni des instructions ni n'est hérité
4. Parmi ces quatre parties, chaque partie contient un certain nombre d'instructions. Ces instructions comprennent principalement les instructions du module principal Nginx, les instructions du module d'événement et les instructions du module principal HTTP. En même temps, chaque partie peut également utiliser d'autres instructions du module HTTP, telles que comme module Http SSL, module HttpGzip Static et module Http Addition, etc.
5. Le vrai fichier de configuration de nginx peut être le suivant
########### 每个指令必须有分号结束。#################
#user administrator administrators; #配置用户或者组，默认为nobody nobody。
#worker_processes 2; #允许生成的进程数，默认为1
#pid /nginx/pid/nginx.pid; #指定nginx进程运行文件存放地址
error_log log/error.log debug; #制定日志路径，级别。这个设置可以放入全局块，http块，server块，级别以此为：debug|info|notice|warn|error|crit|alert|emerg
events {
accept_mutex on; #设置网路连接序列化，防止惊群现象发生，默认为on
multi_accept on; #设置一个进程是否同时接受多个网络连接，默认为off
#use epoll; #事件驱动模型，select|poll|kqueue|epoll|resig|/dev/poll|eventport
worker_connections 1024; #最大连接数，默认为512
}
http {
include mime.types; #文件扩展名与文件类型映射表
default_type application/octet-stream; #默认文件类型，默认为text/plain
#access_log off; #取消服务日志
log_format myFormat '$remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for'; #自定义格式
access_log log/access.log myFormat; #combined为日志格式的默认值
sendfile on; #允许sendfile方式传输文件，默认为off，可以在http块，server块，location块。
sendfile_max_chunk 100k; #每个进程每次调用传输数量不能大于设定的值，默认为0，即不设上限。
keepalive_timeout 65; #连接超时时间，默认为65s，可以在http，server，location块。
upstream mysvr {
server 127.0.0.1:7878;
server 192.168.10.121:3333 backup; #热备
}
error_page 404 https://www.baidu.com; #错误页
server {
keepalive_requests 120; #单连接请求上限次数。
listen 4545; #监听端口
server_name 127.0.0.1; #监听地址
location ~*^.+$ {
#请求的url过滤，正则匹配，~为区分大小写，~*为不区分大小写。
#root path; #根目录
#index vv.txt; #设置默认页
proxy_pass http://mysvr; #请求转向mysvr 定义的服务器列表
deny 127.0.0.1; #拒绝的ip
allow 172.18.5.54; #允许的ip
}
# 第一个程序，hellow world
location /sayhello {
default_type text/html;
return 200 "nginx hello world";
}
}
}
2. Configuration globale
user nobody nobody;
worker_processes 2;
error_log logs/error.log notice;
pid logs/nginx.pid;
events{
use epoll;
worker_connections 65536;
}
1.user : commande du module principal, spécifie l'utilisateur et le groupe d'utilisateurs pour exécuter le processus Nginx Worker. Par défaut, il est exécuté par le compte personne.
User est une commande du module principal qui spécifie l'utilisateur et le groupe d'utilisateurs pour exécuter le processus Nginx Worker. Par défaut, il est exécuté par le compte personne.
2.worker_processes : la commande du module principal spécifie le nombre de processus à démarrer par Nginx. Chaque processus Nginx consomme en moyenne 10 M à 12 M de mémoire. Il est recommandé de spécifier le même nombre que le nombre de processeurs.
Si worker_processes 2 est configuré à cet endroit, alors il y aura deux processus de travail.
3.error_log : commande du module principal, utilisée pour définir le fichier journal d'erreur global. Les niveaux de sortie du journal incluent le débogage, l'information, la notification, l'avertissement, l'erreur et la critique. Parmi eux, le journal de sortie du débogage est le plus détaillé, et le crit le journal de sortie est le moins.
Le chemin du fichier journal se trouve généralement dans le répertoire logs du répertoire d'installation de nginx.
4.pid : instruction du module principal, utilisée pour spécifier l'emplacement du fichier de stockage du pid du processus
Le numéro de processus est le même que celui du maître nginx. Il n'existe que lorsque nginx est en cours d'exécution. Si nginx s'arrête, le pid sera également supprimé.
5. commande events event : consiste à définir le mode de fonctionnement de Nginx et la limite supérieure du nombre de connexions.
3.events commande d'événement
La commande events consiste à définir le mode de fonctionnement de Nginx et la limite supérieure du nombre de connexions.
1.use : commande du module d'événement, utilisée pour spécifier le mode de fonctionnement de Nginx
Les modes de travail pris en charge par Nginx incluent select, poll, kqueue, epoll, rtsig et /dev/poll. Select et poll sont tous deux des modes de travail standard. Kqueue et epoll sont des modes de travail efficaces. La différence est que epoll est utilisé sur la plate-forme Linux. . , et kqueue est utilisé dans les systèmes BSD. Pour les systèmes Linux, le mode de fonctionnement epoll est le premier choix.
2.worker_connections : directive du module d'événement, utilisée pour définir le nombre maximum de connexions pour chaque processus Nginx, la valeur par défaut est 1024
Le nombre maximum de connexions client est déterminé par Worker_processes et Worker_connections, c'est-à-dire Max_client=worker_processes*worker_connections
Lorsqu'il agit en tant que proxy inverse, max_clients devient : max_clients = Worker_processes * Worker_connections/4.
Le nombre maximum de connexions d'un processus est limité par le nombre maximum de fichiers ouverts du processus système Linux. Le paramètre work_connections ne peut prendre effet qu'après l'exécution de la commande du système d'exploitation "ulimit -n 65536".
4.Configuration du serveur HTTP
Le code de configuration Nginx pour les propriétés liées au serveur HTTP est le suivant :
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"';
# 启动零拷贝提高性能
sendfile on;
# 设置keepalive长连接超时时间
keepalive_timeout 65;
# 引入子配置文件
include /nginx/conf/conf.d/*.conf;
}
1.include : L'instruction du module principal est utilisée pour définir les fichiers inclus dans le fichier de configuration, ce qui peut réduire la complexité du fichier de configuration principal et disperser les configurations spécifiques d'autres modules dans différents dossiers.
2.default_type : Il appartient à la directive du module principal HTTP. Le type par défaut est défini ici sur le flux binaire, qui est utilisé lorsque le type de fichier n'est pas défini. Par exemple, lorsque l'environnement PHP n'est pas configuré, Nginx ne l'analysera pas. A ce moment, accédez au fichier PHP avec un navigateur et une fenêtre de téléchargement apparaîtra.
3.log_format : log_format est l'instruction du module HttpLog de Nginx, qui est utilisée pour spécifier le format de sortie du journal Nginx. main est le nom de ce format de sortie de journal, qui peut être référencé dans l'instruction access_log ci-dessous.
log_format main '$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$gzip_ratio"';
log_format download '$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$http_range" "$sent_http_content_range"';
7. Hôte virtuel Nginx
- L'hôte virtuel dans les services Web est un site Web indépendant. Ce site correspond à un nom de domaine indépendant (il peut également s'agir d'une adresse IP ou d'un port), dispose de programmes et de ressources indépendants et peut fournir indépendamment des services externes auxquels les utilisateurs peuvent accéder. .
- Dans Nginx, une étiquette de serveur{} est utilisée pour identifier un hôte virtuel. Un service Web peut avoir plusieurs paires d'étiquettes d'hôte virtuel, c'est-à-dire qu'il peut prendre en charge plusieurs sites d'hôtes virtuels en même temps. Il existe deux types d'hôtes virtuels : les hôtes virtuels basés sur un nom de domaine et les hôtes virtuels basés sur IP+port.
1. Préparation
1. Initialisez d’abord le répertoire de test suivant
mkdir -p /root/nginx/html/{
andy01,andy02}/
2. Créer un fichier d'index
Créez un fichier Index dans le répertoire andy01
vi /root/nginx/html/andy01/index.html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>andy01</title>
<head>
<body>
<H1>
Andy01 ---> 这是Andy01测试文件
</H1>
</body>
</html>
Créez le fichier Index dans le répertoire andy02
vi /root/nginx/html/andy02/index.html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>andy01</title>
<head>
<body>
<H1>
Andy02 ---> 这是Andy02测试文件
</H1>
</body>
</html>
2. Configurer l'hôte virtuel
1. Créez le dossier conf.d dans le répertoire conf du répertoire d'installation de nginx et enregistrez notre propre configuration nginx
mkdir -p /root/nginx/conf/conf.d
2. Modifiez le fichier de configuration nginx et ajoutez le contenu suivant
- Entrez le fichier nginx.conf
vi /root/nginx/conf/nginx.conf
- Ajouter du contenu
# 在http模块末尾添加配置，引入我们自己写的所有配置文件
include conf.d/*.conf;
3. Créez le fichier de configuration hostserver.conf sous le dossier conf.d. Le contenu est le suivant
1. Modifiez le fichier conf.d
vi hostserver.conf
2.Ajoutez le contenu suivant
server {
listen 80;
charset utf-8;
server_name www.andy01.com;
location /{
root html/andy01;
index index.html index.htm;
expires 7d;
}
}
server {
listen 80 ;
charset utf-8;
server_name www.andy02.com;
location /{
root html/andy02;
index index.html index.htm;
expires 7d;
}
}
4. Configurer l'hôte local
192.168.44.116 www.andy01.com
192.168.44.116 www.andy02.com
5. Test d'accès
1. Visitez www.andy01.com
2. Visitez www.andy02.com
6. Si l'erreur suivante se produit
, modifiez le fichier nginx.conf
7. Ordre de correspondance des hôtes virtuels
- Priorité la plus élevée : correspondance exacte
- Deuxième priorité : les jokers en premier
- La troisième priorité : après la wildcard
3. Correspondance d'hôte par défaut
La fonction de l'hôte virtuel par défaut est la suivante : si plusieurs noms de domaine accédés pointent vers ce serveur Web, mais qu'aucun nom de domaine n'est ajouté à l'hôte virtuel nginx, l'hôte virtuel par défaut (pan-analytics) sera accédé
server {
# 将域名www.andy02.com 设置为默认虚拟主机
listen 80 default;
charset utf-8;
server_name www.andy02.com;
location /{
root html/andy02;
index index.html index.htm;
expires 7d;
}
}
Test : 192.168.44.136
8. Le rôle de la localisation
Localisation signifie "positionnement". Différents traitements sont effectués en fonction des différentes URL demandées. Dans l'hôte virtuel (serveur), la configuration de l'emplacement est essentielle et différentes parties du site Web peuvent être positionnées selon différentes méthodes de traitement.
1.règles de localisation
1. Règles de localisation : la section de localisation correspond à l'URI demandé par le client en spécifiant un modèle. Permet la correspondance de chaque emplacement défini en fonction de l'URI demandé par l'utilisateur. Une fois mise en correspondance, la demande sera traitée par la configuration dans le bloc de configuration d'emplacement correspondant, comme le contrôle d'accès et d'autres fonctions.
2. Grammaire
location [修饰符] pattern {…}
3. Description des modificateurs couramment utilisés
| modificateur | Fonction |
|---|---|
| nul | La correspondance de préfixe peut correspondre aux URI préfixés par le chemin qui doit correspondre. |
| = | correspondance exacte |
| ~ | Correspondance de modèles d'expressions régulières, sensible à la casse |
| ~* | Correspondance de modèle Regex, insensible à la casse |
| ^~ | La correspondance exacte des préfixes, similaire au comportement sans modificateurs, commence également par le module spécifié. La différence est que si le modèle correspond, il arrête de rechercher d'autres modèles et ne prend pas en charge les expressions régulières. |
| / | Correspondance universelle, toute demande sera satisfaite. |
2. Préparation
1. Configurer l'hôte local
192.168.44.136 www.andy.com
2. Ajoutez un nouveau fichier de configuration location.conf au répertoire conf/con.d sous le répertoire d'installation de ngxin.
touch location.conf
3. Correspondance de préfixe
Aucun modificateur signifie qu'il doit commencer par le modèle spécifié. Il n'y a pas de modificateur devant le modèle spécifié. Écrivez l'URI qui doit être mis en correspondance directement après l'emplacement. Sa priorité est la deuxième après la correspondance normale.
server {
listen 80;
server_name www.location.com;
charset utf-8;
location /abc {
default_type text/html;
return 200 "前缀匹配-abc...";
}
}
Le contenu suivant peut alors correspondre correctement :
- www.andy.com/abc
- www.andy.com/abc/
- www.andy.com/abc?..
4. Correspondance exacte
La correspondance exacte utilise = pour indiquer que lorsque nginx effectue une correspondance d'itinéraire, la correspondance exacte a la priorité la plus élevée. Une fois que la demande correspond avec précision, nginx cessera de rechercher d'autres éléments correspondants.
server {
listen 80;
server_name www.andy.com;
charset utf-8;
location = /abc {
default_type text/html;
return 200 "精确匹配-abc-accurate";
}
}
1. Le contenu suivant peut alors être correctement mis en correspondance :
- www.andy.com/abc
- www.andy.com/abc?..
2. Le contenu suivant ne peut pas être égalé
- www.andy.com/abc/
- www.andy.com/abc/def
5. Correspondance exacte du préfixe
La priorité de la correspondance exacte du préfixe est juste derrière la correspondance exacte. Une fois que nginx a réussi à faire correspondre le préfixe exact d'une requête, il arrête de rechercher d'autres éléments correspondants.
server {
listen 80;
server_name www.andy.com;
charset utf-8;
location ^~ /abc {
default_type text/html;
return 200 "精确前缀匹配-abc-prefix";
}
}
Le contenu suivant peut alors correspondre correctement
- www.andy.com/abc
- www.andy.com/abc/
- www.andy.com/abc?..
6. Expressions régulières
La correspondance régulière est divisée en deux types : sensible à la casse et insensible à la casse, représentés respectivement par ~ et ~* ; après l'échec d'une demande de correspondance exacte et de correspondance de préfixe exacte, si un emplacement de correspondance régulière pertinent est configuré, nginx essaiera de faire la demande Effectuer une correspondance régulière. Il est à noter qu'il n'y a pas de priorité entre les correspondances régulières, mais elles sont appariées dans l'ordre dans lequel elles apparaissent dans le fichier de configuration. Une fois la précédente trouvée, la recherche s'arrêtera et continuera.
1. Sensible à la casse
~ : indique que l'expression régulière spécifiée est sensible à la casse, par exemple :
server {
listen 80;
server_name www.andy.com;
charset utf-8;
location ~ ^/abc$ {
default_type text/html;
return 200 "正则区分大小写-abc-regular-x";
}
}
Le contenu suivant peut alors correspondre correctement :
- www.andy.com/abc
- www.andy.com/abc?.…
Le contenu suivant ne peut pas être mis en correspondance :
- www.andy.com/abc/
- www.andy.com/ABC
- www.andy.com/abcde
2. Non sensible à la casse
~* : indique que l'expression régulière spécifiée n'est pas sensible à la casse, par exemple :
server {
listen 80;
server_name www.andy.com;
charset utf-8;
location ~* ^/abc$ {
default_type text/html;
return 200 "正则不区分大小写-abc-regular-Y";
}
}
Le contenu suivant correspondra alors correctement :
- www.location.com/abc
- www.location.com/abc?.…
- Le contenu suivant de www.location.com/ABC
ne peut pas être égalé : - www.location.com/abc/
- www.location.com/abcde
7. Correspondance universelle
La correspondance universelle est représentée par un / et peut correspondre à toutes les requêtes. Généralement, il y aura une règle de correspondance universelle à la fin du fichier de configuration nginx. Lorsque d'autres règles de correspondance ne sont pas valides, la demande sera acheminée vers la règle de correspondance universelle pour traitement. ; si la correspondance universelle n'est pas configurée, et autre Lorsque toutes les règles de correspondance échouent, nginx renvoie une erreur 404
server {
listen 80;
server_name www.andy.com;
charset utf-8;
location /{
default_type text/html;
return 200 "通用匹配-default";
}
}
8. Comparaison des priorités
server {
listen 80;
server_name www.andy.com;
charset utf-8;
default_type text/html;
location = /abc {
return 200 "精确匹配-abc";
}
location ^~ /abc {
return 200 "精确前缀匹配-abc";
}
location ~ ^/abc$ {
return 200 "正则匹配-abc";
}
location /abc {
return 200 "前缀匹配-abc";
}
location /{
return 200 "通用匹配-default";
}
}
andy /abc et andy ^~ /abc correspondent tous deux à ceux commençant par /abc. S'ils existent en même temps, une erreur sera signalée.
9. Exemple complet
server {
listen 80;
server_name www.andy.com;
default_type text/html;
charset utf-8;
location = / {
return 200 "规则A";
}
location = /login {
return 200 "规则B";
}
location ^~ /static/ {
return 200 "规则C";
}
location ^~ /static/files {
return 200 "规则X";
}
location ~ \.(gif|jpg|png|js|css)$ {
return 200 "规则D";
}
location ~* \.js$ {
return 200 "规则E";
}
location /img {
return 200 "规则Y";
}
location / {
return 200 "规则F";
}
}
| demander l'uri | Faire correspondre les règles de routage |
|---|---|
| http://www.andy.com/ | Règle A |
| http://www.andy.com/login | Règle B |
| http://www.andy.com/register | Règle F |
| http://www.andy.com/static/a.html | Règle C |
| http://www.andy.com/static/files/a.txt | RègleX |
| http://www.andy.com/a.png | Règle D |
| http://www.andy.com/a.PNG | Règle F |
| http://www.andy.com/img/a.gif | Règle D |
| http://www.andy.com/img/a.tiff | Règle Y |
10. Ordre de correspondance
1. Ordre et priorité de correspondance, de haut en bas :
- Les correspondances exactes avec "=" sont prioritaires
- expression régulière
- correspondance exacte sans modificateurs
2. Les règles de correspondance spécifiques sont les suivantes :
- =Lorsqu'une correspondance précise est obtenue, arrêtez l'action de localisation et passez directement à une correspondance précise.
- Lorsqu'une correspondance générale (y compris une correspondance de préfixe exacte) est trouvée, toutes les correspondances courantes sont collectées en premier, et enfin la plus longue est comparée.
- Si la correspondance ordinaire la plus longue est déclarée comme correspondance exacte de préfixe, cette correspondance sera effectuée directement et la localisation sera arrêtée.
- Si la correspondance ordinaire la plus longue ne correspond pas exactement à un préfixe, continuez vers l'emplacement habituel.
- Exécutez une correspondance régulière dans l'ordre du code et arrêtez l'emplacement lorsque le premier emplacement régulier est atteint.
Remarque : Lorsque plusieurs expressions régulières apparaissent, suivez l'ordre dans lequel elles sont définies dans le fichier de configuration.
11.processus de correspondance de chemin
En supposant que le chemin de la requête http est http://192.168.0.132:8088/mvc/index?id=2, le processus de correspondance est le suivant :
- Décomposez l'URL entière en nom de domaine/port/chemin/params
- Tout d’abord, mappez le nom de domaine/le port à l’hôte virtuel du serveur cible.
- La partie chemin participe à la correspondance d'emplacement, chemin = partie correspondante chemin1 + partie restante chemin2
- Entrez le processus interne du corps de la méthode de localisation.
- S'il s'agit d'un traitement de fichier statique, entrez dans le répertoire cible pour rechercher le fichier : lors de l'utilisation de la commande root, recherchez le fichier correspondant à path1+path2 ; lors de l'utilisation de la commande alias, recherchez le fichier correspondant à path2.
- S'il s'agit d'un proxy proxy, lorsqu'il est sous la forme proxy_pass=ip:port, il transmet le chemin path1+path2 à tomcat ; lorsqu'il est sous la forme proxy_pass=ip:port/xxx, il transmet le chemin path2 vers Tomcat, et les paramètres suivent toujours le transfert.
12. Suggestions d'utilisation pratiques
Par conséquent, en utilisation réelle, j'estime personnellement qu'il existe au moins trois définitions de règles correspondantes, comme suit :
#直接匹配网站根，通过域名访问网站首页比较频繁，使用这个会加速处理，官网如是说。
#这里是直接转发给后端应用服务器了，也可以是一个静态首页
# 第一个必选规则
location = / {
proxy_pass http://tomcat:8080/index
}
# 第二个必选规则是处理静态文件请求，这是nginx作为http服务器的强项
# 有两种配置模式，目录匹配或后缀匹配,任选其一或搭配使用
location ^~ /static/ {
alias /webroot/static/;
}
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {
root /webroot/res/;
}
# 第三个规则就是通用规则，用来转发动态请求到后端应用服务器
# 非静态文件请求就默认是动态请求，自己根据实际把握
# 毕竟目前的一些框架的流行，带.php,.jsp后缀的情况很少了
location / {
proxy_pass http://tomcat:8080/
}
9.Proxy inverse Nginx
1. Ajoutez andy_test.conf au répertoire conf/conf.d dans le répertoire d'installation de nginx
touch andy_test.conf
2. Configurer l'hôte local
192.168.44.136 www.andy_test.com
3. Modifiez le fichier andy_test.conf et ajoutez le contenu suivant
server {
listen 80;
server_name www.andy_test.com;
default_type text/html;
charset utf-8;
location /{
proxy_pass http://192.168.44.136:8081;
}
}
10. Équilibrage de charge Nginx
1.Configuration de base
L'équilibrage de charge est utilisé pour sélectionner un serveur dans la liste de serveurs backend définie par le module "en amont" pour accepter les demandes des utilisateurs. Un module en amont le plus basique ressemble à ceci. Le serveur dans le module est la liste de serveurs :
#动态服务器组
upstream dynamicserver {
server 192.168.44.136:8081; #tomcat 1
server 192.168.44.136:8082; #tomcat 2
server 192.168.44.136:8083; #tomcat 3
}
Une fois la configuration du module en amont terminée, vous devez inverser le proxy pour l'accès spécifié à la liste des serveurs :
#其他页面反向代理到tomcat容器
location /{
proxy_pass http://dynamicserver;
}
Il s'agit de l'instance d'équilibrage de charge la plus basique, mais elle ne suffit pas à répondre aux besoins réels : actuellement le module amont du serveur Nginx supporte 6 modes de distribution. La configuration complète est la suivante
upstream dynamicserver {
server 192.168.44.136:8081; #tomcat 1
server 192.168.44.136:8082; #tomcat 2
server 192.168.44.136:8083; #tomcat 3
}
server {
server_name www.andy_test.com;
default_type text/html;
charset utf-8;
location /{
proxy_pass http://dynamicserver;
}
}
2. paramètres communs en amont
Description du paramètre
| serveur | Adresse du service inverse plus port |
|---|---|
| poids | Poids |
| échec_timeout | Utilisé conjointement avec max_fails. |
| max_fails | Définissez le nombre maximum d'échecs dans le délai défini par le paramètre fail_timeout. Si toutes les requêtes adressées au serveur échouent dans ce délai, le serveur sera considéré comme étant en panne. |
| max_conns | Nombre maximum de connexions autorisées |
| échec_time | La durée pendant laquelle le serveur sera considéré comme indisponible, la valeur par défaut est de 10 s |
| sauvegarde | Marquez ce serveur comme serveur de sauvegarde auquel les requêtes seront envoyées lorsque le serveur principal sera arrêté. |
| vers le bas | Marquer le serveur définitivement hors service |
| démarrage_lent | Lorsque le nœud revient, ne le rejoignez pas immédiatement |
3.负载均衡策略
在这里，只详细说明Nginx自带的负载均衡策略，第三方不多描述
| 负载策略 | 描述 |
|---|---|
| 轮询 | 默认方式 |
| weight | 权重方式 |
| ip_hash | 依据ip分配方式 |
| least_conn | 最少连接方式 |
| fair（第三方） | 响应时间方式 |
| url_hash（第三方） | 依据URL分配方式 |
1.轮询：最基本的配置方法，上面的例子就是轮询的方式，它是upstream模块默认的负载均衡默认策略，每个请求会按时间顺序逐一分配到不同的后端服务器
#动态服务器组
upstream dynamicserver {
server 192.168.44.136:8081; #tomcat 1
server 192.168.44.136:8082; #tomcat 2
server 192.168.44.136:8083; #tomcat 3
}
注意：
- 在轮询中，如果服务器down掉了，会自动剔除该服务器
- 缺省配置就是轮询策略
- 此策略适合服务器配置相当，无状态且短平快的服务使用
配置示例：
upstream dynamicserver {
server 192.168.44.136:8081; #tomcat 1
server 192.168.44.136:8082; #tomcat 2
server 192.168.44.136:8083; #tomcat 3
}
server {
server_name www.andy_test.com;
default_type text/html;
charset utf-8;
location /{
proxy_pass http://dynamicserver;
}
}
2.weight：权重方式，在轮询策略的基础上指定轮询的几率
#动态服务器组
upstream dynamicserver {
server 192.168.44.136:8081 weight=2;#tomcat 1
server 192.168.44.136:8082; #tomcat 2
server 192.168.44.136:8083; #tomcat 3
}
weight参数用于指定轮询几率，weight的默认值为1,；weight的数值与访问比率成正比，比如Tomcat 7.0被访问的几率为其他服务器的两倍
注意:
- 权重越高分配到需要处理的请求越多。
- 此策略比较适合服务器的硬件配置差别比较大的情况
3.ip_hash:指定负载均衡器按照基于客户端IP的分配方式，这个方法确保了相同的客户端的请求一直发送到相同的服务器，以保证session会话，这样每个访客都固定访问一个后端服务器，可以解决session不能跨服务器的问题
upstream dynamicserver {
#保证每个访客固定访问一个后端服务器
ip_hash;
server 192.168.44.136:8081;#tomcat 1
server 192.168.44.136:8082;#tomcat 2
server 192.168.44.136:8083;#tomcat 3
}
注意：
- 在nginx版本1.3.1之前，不能在ip_hash中使用权重（weight）
- ip_hash不能与backup同时使用
- 此策略适合有状态服务，比如session
- 当有服务器需要剔除，必须手动down掉
4,least_conn：把请求转发给连接数较少的后端服务器，轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高，这种情况下，least_conn这种方式就可以达到更好的负载均衡效果
upstream dynamicserver {
#把请求转发给连接数较少的后端服务器
least_conn;
server 192.168.44.136:8081;#tomcat 1
server 192.168.44.136:8082;#tomcat 2
server 192.168.44.136:8083;#tomcat 3
}
注意：此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况
3.负载均衡重试策略
基础失败重试：为了方便理解，使用了以下配置进行分析（proxy_next_upstream 没有特殊配置
upstream dynamicserver {
server 192.168.44.136:8081 fail_timeout=60s max_fails=3;
server 192.168.44.136:8082 fail_timeout=60s max_fails=3;
server 192.168.44.136:8083 fail_timeout=60s max_fails=3;
}
配置说明：max_fails=3 fail_timeout=60s代表在60秒内请求某一应用失败3次，认为该应用宕机，后等待60秒，这期间内不会再把新请求发送到宕机应用，而是直接发到正常的那一台，时间到后再有请求进来继续尝试连接宕机应用且仅尝试1次，如果还是失败，则继续等待60秒…以此循环，直到恢复
模拟异常：模拟后端异常的方式是直接将对应服务关闭，造成 connect refused 的情况，对应 error 错误
最初始阶段，所有服务器都正常，请求会按照轮询方式依次转发给 AB 两个 Server 处理。假设这时 A 节点服务崩溃，端口不通，则会出现这种情况：
- 请求 1 转到 A 异常，再重试到 B 正常处理，A fails +1
- 请求 2 转到 B 正常处理
- 请求 3 转到 A 异常，再重试到 B 正常处理，A fails +1 达到 max_fails 将被屏蔽 60s
- 屏蔽 A 的期间请求都只转给 B 处理，直到屏蔽到期后将 A 恢复重新加入存活列表，再按照这个逻辑执行
如果在 A 的屏蔽期还没结束时，B 节点的服务也崩溃，端口不通，则会出现：
- 请求 1 转到 B 异常，此时所有线上节点异常，会出现：
- AB 节点一次性恢复，都重新加入存活列表
- 请求转到 A 处理异常，再转到 B 处理异常
- 触发 no live upstreams 报错，返回 502 错误
- 所有节点再次一次性恢复，加入存活列表
- 请求 2 依次经过 AB 均无法正常处理， 触发 no live upstreams 报错，返回 502 错误
错误重试：有时候我们系统出现500等异常的情况下，希望nginx能够到其他的服务器进行重试，我们可以配置那些错误码才进行重试
配置说明：在nginx的配置文件中，proxy_next_upstream项定义了什么情况下进行重试，官网文档中给出的说明如下
Syntax: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | off ...;
Default: proxy_next_upstream error timeout;
Context: http, server, location
默认情况下，当请求服务器发生错误或超时时(error timeout)，会尝试到下一台服务器，还有一些其他的配置项如下
| 错误状态 | 描述 |
|---|---|
| error | 与服务器建立连接，向其传递请求或读取响应头时发生错误; |
| timeout | 在与服务器建立连接，向其传递请求或读取响应头时发生超时; |
| invalid_header | 服务器返回空的或无效的响应; |
| http_500 | 服务器返回代码为500的响应; |
| http_502 | 服务器返回代码为502的响应; |
| http_503 | 服务器返回代码为503的响应; |
| http_504 | 服务器返回代码504的响应; |
| http_403 | 服务器返回代码为403的响应; |
| http_404 | 服务器返回代码为404的响应; |
| http_429 | 服务器返回代码为429的响应（1.11.13）; |
| non_idempotent | 通常，请求与 非幂等 方法（POST，LOCK，PATCH）不传递到请求是否已被发送到上游服务器（1.9.13）的下一个服务器; 启用此选项显式允许重试此类请求; |
| off | 禁用将请求传递给下一个服务器 |
这里面我们配置了500等错误的时候会进行重试:
upstream dynamicserver {
server 192.168.44.136:8081 fail_timeout=60s max_fails=3; #tomcat 1
server 192.168.44.136:8082 fail_timeout=60s max_fails=3; #tomcat 2
}
server {
server_name www.andy_test.com;
default_type text/html;
charset utf-8;
location/{
proxy_pass http://dynamicserver;
#下一节点重试的错误状态
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
}
}
模拟异常：在正常的情况下如果500错误会直接出现异常页面，现在我们加入了以上500重试策略，重试错误的流程和上面流程是一样的
限制重试方式：默认配置是没有做重试机制进行限制的，也就是会尽可能去重试直至失败，Nginx 提供了以下两个参数来控制重试次数以及重试超时时间
- proxy_next_upstream_tries：设置重试次数，默认 0 表示无限制，该参数包含所有请求 upstream server 的次数，包括第一次后之后所有重试之和
- proxy_next_upstream_timeout：设置重试最大超时时间，默认 0 表示不限制，该参数指的是第一次连接时间加上后续重试连接时间，不包含连接上节点之后的处理时间
配置说明:
upstream dynamicserver {
server 192.168.44.136:9001 fail_timeout=60s max_fails=3; #Server A
server 192.168.44.136:9002 fail_timeout=60s max_fails=3; #Server B
}
server {
server_name www.andy_test.com;
default_type text/html;
charset utf-8;
location /{
proxy_pass http://dynamicserver;
# 连接超时时间是3s
proxy_connect_timeout 3s;
#表示在 6 秒内允许重试 3 次，只要超过其中任意一个设置，Nginx 会结束重试并返回客户端响应
proxy_next_upstream_timeout 6s;
proxy_next_upstream_tries 3;
}
}
backup 服务器：Nginx 支持设置备用节点，当所有线上节点都异常时启用备用节点，同时备用节点也会影响到失败重试的逻辑，因此单独列出来介绍
backup 处理逻辑：upstream 的配置中，可以通过 backup 指令来定义备用服务器，其含义如下
- 正常情况下，请求不会转到到 backup 服务器，包括失败重试的场景
- 当所有正常节点全部不可用时，backup 服务器生效，开始处理请求
- 一旦有正常节点恢复，就使用已经恢复的正常节点
- backup 服务器生效期间，不会存在所有正常节点一次性恢复的逻辑
- 如果全部 backup 服务器也异常，则会将所有节点一次性恢复，加入存活列表
- 如果全部节点（包括 backup）都异常了，则 Nginx 返回 502 错误
配置说明：
upstream dynamicserver {
server 192.168.44.136:8081; #Service A
server 192.168.44.136:8082; #Server B
server 192.168.44.136:8083 backup; #backup
}
server {
server_name www.andy_test.com;
default_type text/html;
charset utf-8;
location /{
proxy_pass http://dynamicserver;
}
}
在最初始阶段，所有服务器都正常，请求会按照轮询方式依次转发给 AB 两个节点处理，当只有 A 异常的情况下，与上文没有 backup 服务器场景处理方式一致，这里就不重复介绍了
假设在 A 的屏蔽期还没结束时，B 节点的服务也崩溃，端口不通，则会出现:
- 请求 1 转到 B 处理，异常，此时所有线上节点异常，会出现
- AB 节点一次性恢复，都重新加入存活列表
- 请求转到 A 处理异常，再重试到 B 处理异常，两者 fails 都 +1
- 因 AB 都异常，启用 backup 节点正常处理，并且 AB 节点一次性恢复，加入存活列表
- 请求 2 再依次经过 A、B 节点异常，转到 backup 处理，两者 fails 都达到 max_fails：
- AB 节点都将会被屏蔽 60s，并且不会一次性恢复
- backup 节点正式生效，接下来所有请求直接转到 backup 处理
- 直到 AB 节点的屏蔽到期后，重新加入存活列表
假设 AB 的屏蔽期都还没结束时，C 节点的服务也崩溃，端口不通，则会出现
- 请求 1 转到 C 异常，此时所有节点（包括 backup）都异常，会出现
- ABC 三个节点一次性恢复，加入存活列表
- 请求转到 A 处理异常，重试到 B 处理异常，最后重试到 C 处理异常
- 触发 no live upstreams 报错，返回 502 错误
- 所有节点再次一次性恢复，加入存活列表
- 请求 2 依次经过 AB 节点异常，重试到 C 异常，最终结果如上个步骤，返回 502 错误
十一.Nginx 常用案例
1. Fichiers statiques proxy :
server {
listen 10086;
server_name www.andy_test.com;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_redirect off;
}
location /data/ {
#这里是重点，就是代理这个文件夹
alias '/usr/local/data/';
expires 7d;
}
}
Accédez à http://localhost:10086/data/. Les ressources suivantes sont les ressources permettant d'accéder au dossier /usr/local/data.
2. Proxy inverse
server {
listen 80;
server_name www.adny_test.com;;
location / {
proxy_pass http://127.0.0.1:8080;
index index.html index.htm .jsp;
}
}
3. Configuration inter-domaines
server {
listen 80;
server_name www.andy_test.com;
if ( $host ~ (.*).andy_test.com){
set $domain $1;##记录二级域名值
}
#是否允许请求带有验证信息
add_header Access-Control-Allow-Credentials true;
#允许跨域访问的域名,可以是一个域的列表，也可以是通配符*
add_header Access-Control-Allow-Origin *;
#允许脚本访问的返回头
add_header Access-Control-Allow-Headers 'x-requested-with,content-type,Cache-Control,Pragma,Date,x-timestamp';
#允许使用的请求方法，以逗号隔开
add_header Access-Control-Allow-Methods 'POST,GET,OPTIONS,PUT,DELETE';
#允许自定义的头部，以逗号隔开,大小写不敏感
add_header Access-Control-Expose-Headers 'WWW-Authenticate,Server-Authorization';
#P3P支持跨域cookie操作
add_header P3P 'policyref="/w3c/p3p.xml", CP="NOI DSP PSAa OUR BUS IND ONL UNI COM NAV INT LOC"';
if ($request_method = 'OPTIONS') {
##OPTIONS类的请求，是跨域先验请求
return 204;##204代表ok
}
}