Understanding Nginx Load Balancing: Compare 4 Common Scheduling Algorithms

Nginx is a core component of large‑scale architectures. This article breaks down the principles behind Nginx load balancing and compares four mainstream scheduling algorithms.

1. Round Robin distributes incoming requests sequentially across backend servers in a circular order. It is simple to implement, provides even distribution when server performance and request latency are similar, and is easy to understand. However, it ignores the actual load of each server, leading to imbalance if request processing times vary or servers differ in capacity.

<ol><li>Request 1 → Server A</li><li>Request 2 → Server B</li><li>Request 3 → Server C</li><li>Request 4 → Server A</li><li>…</li></ol>

Pros: simple, uniform distribution, easy to understand. Cons: does not consider real‑time server load, causing potential overload on slower nodes.

2. Weighted Round Robin extends Round Robin by assigning a weight to each backend server based on its capacity. Nginx then distributes requests proportionally to these weights. For example, a stronger server can be given weight 3 while a weaker one gets weight 1, resulting in a dispatch sequence such as A A A B A A A B …. This approach better utilizes heterogeneous resources but the weights are static; they cannot reflect instantaneous pressure, so traffic spikes may still cause localized congestion.

<ol><li>A (weight 3) B (weight 1)</li><li>Scheduling sequence: A A A B A A A B …</li></ol>

Advantages: adapts to heterogeneous clusters, more rational resource use. Disadvantages: static configuration, cannot react to rapid load changes.

3. IP Hash hashes the client’s IP address and maps the same IP to a specific backend server, providing strong session stickiness. This is useful when session state is stored locally or when a distributed session store is unavailable. The flow is Client IP → hash → Server A/B …. It prevents session loss caused by frequent backend switches. However, if a backend fails, the mapping changes for affected users, and large numbers of clients behind a single NAT may cause traffic skew.

<ol><li>IP1 → hash → Server A</li><li>IP2 → hash → Server B</li></ol>

Pros: strong session affinity. Cons: mapping changes on server failure; NAT or corporate networks can lead to uneven load.

4. Least Connections routes each request to the server with the fewest active connections at that moment. Example: servers A (10 connections) and B (3 connections) receive a new request, which is sent to B. This algorithm reflects real‑time processing pressure, making it suitable for workloads with highly variable request latency, such as file downloads, real‑time communication, or APIs with fluctuating response times. It reduces the risk of a single server being overwhelmed. The trade‑off is higher algorithmic complexity and the need to maintain connection‑count state; if connection count does not correlate with CPU or memory usage, decisions may be sub‑optimal.

<ol><li>A (10 connections) B (3 connections)</li><li>New request → B</li></ol>

Advantages: dynamic load awareness, better for long‑lived connections. Disadvantages: increased complexity, possible mismatch with actual resource usage.