0Pricing
API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) · Lekcja

Ważone równoważenie obciążenia i serwery zapasowe

Rozdzielaj ruch nierównomiernie między serwery za pomocą wag oraz dodawaj serwery zapasowe, które przejmują ruch dopiero po awarii głównej puli.

Ważone równoważenie obciążenia i serwery zapasowe to bezpłatna lekcja API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway), a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

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; done

Quick Check

A server is marked backup. When does it receive requests?

Recap

You learned to fine-tune traffic distribution:

  • weight=N biases traffic toward stronger servers
  • Weights are relative and apply to round robin and least_conn
  • backup servers activate only when primaries fail
  • down, max_fails, and max_conns control availability

Together these give you precise control over an uneven server fleet.

Często zadawane pytania

Czy lekcja „Ważone równoważenie obciążenia i serwery zapasowe” jest bezpłatna?

Tak — pełny tekst „Ważone równoważenie obciążenia i serwery zapasowe” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway), przejdź na CoddyKit PRO. Kurs API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) zawiera 4 lekcji w sumie.

Co nauczysz się w „Ważone równoważenie obciążenia i serwery zapasowe”?

Rozdzielaj ruch nierównomiernie między serwery za pomocą wag oraz dodawaj serwery zapasowe, które przejmują ruch dopiero po awarii głównej puli. Ćwiczysz API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)?

Nie wymagamy żadnego doświadczenia. API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Ważone równoważenie obciążenia i serwery zapasowe”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)?

Tak. Każda lekcja API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Algorytmy równoważenia obciążenia
  2. Kontrole stanu i monitorowanie serwerów
  3. Sesje trwałe i utrzymywanie sesji
  4. Ważone równoważenie obciążenia i serwery zapasowe
← Powrót do API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)