Répartition de charge pondérée et serveurs de secours
Répartissez inégalement le trafic entre les serveurs à l’aide de pondérations et ajoutez des serveurs de secours qui ne prennent le relais qu’en cas de défaillance du pool principal.
Répartition de charge pondérée et serveurs de secours est une leçon API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway), et ta progression se synchronise sur le web et l'application CoddyKit. Le cours API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
When Servers Are Not Equal
Real upstream pools often mix machines of different capacity. A new 16-core server should not get the same share as an old 4-core box.
Nginx lets you bias traffic with weights so stronger servers handle more requests.
The weight Parameter
Add weight=N to a server. The default weight is 1. A server with weight=3 receives roughly three times as many requests as a weight=1 server.
upstream app {
server 10.0.0.1 weight=3;
server 10.0.0.2 weight=1;
}How the Ratio Works
With weights 3 and 1, out of every 4 requests, 3 go to the first server and 1 to the second. Weights are relative, so 6 and 2 produce the same split as 3 and 1.
Weights with Other Algorithms
Weights work with round robin (the default) and least connections. They do not apply to ip_hash, which selects a server purely from the client IP.
upstream app {
least_conn;
server 10.0.0.1 weight=5;
server 10.0.0.2 weight=2;
}Introducing Backup Servers
A server marked backup receives no traffic while any primary server is available. It activates only when all primaries are down or unreachable.
upstream app {
server 10.0.0.1;
server 10.0.0.2;
server 10.0.0.9 backup;
}Why Use a Backup
Backups give you a graceful fallback, for example a maintenance page server or a secondary data center, without sending it normal traffic during healthy operation.
Marking a Server Down
Use down to permanently remove a server from rotation, handy during planned maintenance without deleting the line.
upstream app {
server 10.0.0.1;
server 10.0.0.2 down;
}Failure Detection Parameters
max_fails sets how many failed attempts mark a server unavailable, and fail_timeout sets the window and how long it stays out.
server 10.0.0.1 max_fails=3 fail_timeout=30s;Combining Weight and Backup
You can mix weights for primaries and keep a single backup for the whole pool. The backup ignores weight until it is the only option.
upstream app {
server 10.0.0.1 weight=4;
server 10.0.0.2 weight=1;
server 10.0.0.9 backup;
}Limiting Connections
The max_conns parameter caps simultaneous connections to a server, protecting a weaker box even if its weight is high.
server 10.0.0.2 weight=2 max_conns=100;Testing the Distribution
Fire many requests and check your access logs per upstream to confirm the ratio matches the weights. Adjust weights based on observed CPU and latency.
for i in $(seq 1 100); do curl -s http://localhost/ > /dev/null; doneQuick Check
A server is marked backup. When does it receive requests?
Recap
You learned to fine-tune traffic distribution:
weight=Nbiases traffic toward stronger servers- Weights are relative and apply to round robin and least_conn
backupservers activate only when primaries faildown,max_fails, andmax_connscontrol availability
Together these give you precise control over an uneven server fleet.
Questions Fréquemment Posées
La leçon « Répartition de charge pondérée et serveurs de secours » est-elle gratuite ?
Oui — le texte complet de « Répartition de charge pondérée et serveurs de secours » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway), passe à CoddyKit PRO. Le cours API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Répartition de charge pondérée et serveurs de secours » ?
Répartissez inégalement le trafic entre les serveurs à l’aide de pondérations et ajoutez des serveurs de secours qui ne prennent le relais qu’en cas de défaillance du pool principal. Tu pratiques API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ?
Aucune expérience préalable n'est requise. API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.
Combien de temps prend la leçon « Répartition de charge pondérée et serveurs de secours » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ?
Oui. Chaque leçon API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Algorithmes d’équilibrage de charge
- Vérifications d’état et supervision des serveurs
- Sessions persistantes et affinité de session
- Répartition de charge pondérée et serveurs de secours