Quels sont les principaux scénarios d'application de Nginx ?
王林
Libérer: 2023-05-12 09:07:11
avant
2029 Les gens l'ont consulté
Que peut faire Nginx ? Les éléments que les modules tiers peuvent gérer, voici une description détaillée de la façon d'exécuter chaque fonction
Le proxy inverse devrait être la chose la plus courante que fait Nginx. provient de l'Encyclopédie Baidu Argument : La méthode du proxy inverse consiste à utiliser un serveur proxy pour accepter les demandes de connexion sur Internet, puis à transmettre les demandes au serveur sur le réseau interne et à renvoyer les résultats obtenus du serveur au client demandant une connexion. sur Internet, le serveur proxy apparaît actuellement comme un serveur proxy inverse pour le monde extérieur. Pour faire simple, le serveur réel n'est pas directement accessible par le réseau externe, un serveur proxy est donc nécessaire. Le serveur proxy est accessible par le réseau externe et se trouve dans le même environnement réseau que le serveur réel. peut également être le même serveur et le même port. Collez ci-dessous un code simple pour implémenter le proxy inverse
Enregistrez le fichier de configuration et démarrez Nginx, de sorte que lorsque nous accédons à localhost, cela équivaut à accéder à localhost :8080Équilibrage de chargeL'équilibrage de charge est également couramment utilisé dans Nginx As une fonction, l'équilibrage de charge signifie attribuer l'exécution à plusieurs unités opérationnelles, telles que des serveurs Web, des serveurs FTP, des serveurs d'applications clés d'entreprise et d'autres serveurs critiques, etc., afin d'accomplir conjointement des tâches de travail. Pour faire simple, lorsqu'il y a deux serveurs ou plus, les requêtes sont distribuées de manière aléatoire aux serveurs désignés pour être traitées selon des règles. La configuration de l'équilibrage de charge nécessite généralement la configuration d'un proxy inverse en même temps et passe à l'équilibrage de charge via l'inverse. procuration. Nginx prend actuellement en charge 3 stratégies d'équilibrage de charge intégrées, ainsi que 2 stratégies tierces couramment utilisées. 1. RR (par défaut)Chaque requête est attribuée à différents serveurs backend un par un par ordre chronologique. Si le serveur backend tombe en panne, il peut être automatiquement éliminé. Configuration simple
upstream test {
server localhost:8080;
server localhost:8081;
}
server {
listen 81;
server_name localhost;
client_max_body_size 1024M;
location / {
proxy_pass http://test;
proxy_set_header Host $host:$server_port;
}
}
Copier après la connexion
Le code de base de l'équilibrage de charge est
upstream test {
server localhost:8080;
server localhost:8081;
}
Copier après la connexion
Ici, j'ai configuré 2 serveurs, bien sûr, c'est en fait un, mais le port est différent, et le serveur 8081 n'existe pas, ce qui signifie que l'accès est non, mais lorsque nous accéderons à http://localhost, il n'y aura aucun problème. Il passera à http://localhost:8080 par défaut, car Nginx déterminera automatiquement l'état du serveur si le serveur est inaccessible. le serveur se bloque), il ne passera pas à ce serveur, ce qui évite également la situation où un serveur se bloque et affecte l'utilisation. Puisque Nginx utilise par défaut la politique RR, nous n'avons besoin d'aucun autre paramètre. 2. PoidsSpécifie la probabilité d'interrogation. Le poids est proportionnel au taux d'accès et est utilisé lorsque les performances du serveur back-end sont inégales. Par exemple
upstream test {
server localhost:8080 weight=9;
server localhost:8081 weight=1;
}
Copier après la connexion
Généralement, seulement 1 fois sur 10 accédera à 8081, et 9 fois accédera à 80803, ip_hashLes deux méthodes ci-dessus ont un problème, c'est-à-dire que la prochaine requête arrive A ce moment, la requête peut être distribué sur un autre serveur. Lorsque notre programme n'est pas apatride (en utilisant une session pour enregistrer les données), il y aura un gros problème à ce moment-là, par exemple, si les informations de connexion sont enregistrées dans la session, passez à une autre. serveur, vous devez vous reconnecter, donc souvent nous avons besoin qu'un client accède à un seul serveur, alors nous devons utiliser ip_hash. Chaque requête de ip_hash est allouée en fonction du résultat de hachage de l'adresse IP consultée, de sorte que chaque visiteur soit. corrigé L'accès à un serveur backend peut résoudre les problèmes de session.
upstream test {
ip_hash;
server localhost:8080;
server localhost:8081;
}
Copier après la connexion
4. équitable (tiers)Attribuez les demandes en fonction du temps de réponse du serveur backend, et celles avec des temps de réponse courts seront attribuées en premier.
upstream backend {
fair;
server localhost:8080;
server localhost:8081;
}
Copier après la connexion
5. url_hash (tiers) Distribuez les requêtes en fonction du résultat de hachage de l'URL consultée, afin que chaque URL soit dirigée vers le même serveur back-end. C'est plus efficace lorsque le serveur back-end est mis en cache. . Ajoutez une instruction de hachage en amont. D'autres paramètres tels que le poids ne peuvent pas être écrits dans l'instruction du serveur. hash_method est l'algorithme de hachage utilisé
upstream backend {
hash $request_uri;
hash_method crc32;
server localhost:8080;
server localhost:8081;
}
Copier après la connexion
Les cinq méthodes d'équilibrage de charge ci-dessus peuvent être utilisées dans différentes situations, vous pouvez donc choisir quelle stratégie. à utiliser en fonction du mode de situation réel, mais fair et url_hash doivent installer des modules tiers avant de pouvoir être utilisés. Puisque cet article présente principalement ce que Nginx peut faire, l'installation de modules tiers pour Nginx ne sera pas introduite dans. cet articleServeur HTTPNginx lui-même est également un serveur de ressources statiques. Lorsqu'il n'y a que des ressources statiques, vous pouvez utiliser Nginx comme serveur. En même temps, il est également très populaire maintenant de séparer les ressources statiques des ressources statiques. , qui peut être réalisé via Nginx. Tout d'abord, jetons un coup d'œil à Nginx en tant que serveur de ressources statiques
.
server {
listen 80;
server_name localhost;
client_max_body_size 1024M;
location / {
root e:\wwwroot;
index index.html;
}
}
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn