Алгоритмы балансировки нагрузки: Round Robin, Least Connections и другие

Балансировка нагрузки распределяет входящий сетевой трафик между несколькими серверами, чтобы ни один из них не был перегружен. Алгоритм распределения напрямую влияет на производительность приложения, надёжность и использование ресурсов. Выбор правильного алгоритма зависит от паттернов трафика, возможностей серверов и архитектуры приложения.

Зачем нужна балансировка нагрузки

Без балансировки нагрузки один сервер обрабатывает все запросы — это единая точка отказа и ограничение масштабирования. Балансировщики решают эту проблему, направляя запросы в пул бэкенд-серверов по алгоритму распределения. Преимущества:

• Высокая доступность — при отказе одного сервера трафик перенаправляется на здоровые
• Масштабируемость — добавляйте серверы для обработки возросшей нагрузки
• Производительность — распределение работы сокращает время ответа
• Обслуживание — выводите серверы на обновление без простоя

Статические алгоритмы

Статические алгоритмы принимают решения о маршрутизации без учёта текущего состояния серверов. Они просты, предсказуемы и имеют минимальные накладные расходы.

Round Robin

Простейший алгоритм. Запросы распределяются последовательно по пулу серверов: первый запрос — Серверу 1, второй — Серверу 2, и так далее по кругу.

# Nginx round robin (поведение по умолчанию)
upstream backend {
    server 10.0.1.1:8080;
    server 10.0.1.2:8080;
    server 10.0.1.3:8080;
}

Подходит для: серверов с одинаковым оборудованием и stateless-приложений, где каждый запрос занимает примерно одинаковое время.

Ограничения: не учитывает различия в мощности серверов или текущую нагрузку.

Weighted Round Robin

Расширение round robin, где каждому серверу назначается вес пропорционально его мощности. Сервер с весом 5 получает в пять раз больше запросов, чем сервер с весом 1.

# Nginx weighted round robin
upstream backend {
    server 10.0.1.1:8080 weight=5;  # Мощный сервер
    server 10.0.1.2:8080 weight=3;  # Средний сервер
    server 10.0.1.3:8080 weight=1;  # Малый сервер
}

Подходит для: гетерогенных пулов серверов с различными характеристиками CPU, памяти или сети.

IP Hash

Хеш IP геолокацию клиента определяет, какой сервер обработает запрос. Один и тот же IP всегда направляется на один сервер (пока пул не изменится).

# Nginx IP hash
upstream backend {
    ip_hash;
    server 10.0.1.1:8080;
    server 10.0.1.2:8080;
    server 10.0.1.3:8080;
}

Подходит для: приложений с привязкой сессий (sticky sessions) без использования cookie или токенов.

Ограничения: клиенты за NAT или корпоративным прокси делят один IP, вызывая неравномерное распределение.

Динамические алгоритмы

Динамические алгоритмы учитывают текущее состояние серверов при принятии решений. Они адаптируются к условиям в реальном времени, но требуют больше ресурсов для отслеживания.

Least Connections

Направляет каждый новый запрос на сервер с наименьшим числом активных соединений. Естественно адаптируется к различиям во времени обработки — серверы с медленными запросами накапливают соединения и получают меньше новых.

# Nginx least connections
upstream backend {
    least_conn;
    server 10.0.1.1:8080;
    server 10.0.1.2:8080;
    server 10.0.1.3:8080;
}

Подходит для: приложений с переменным временем обработки запросов — API документацию, где одни эндпоинты быстрые, а другие включают базу данных или внешние сервисы.

Weighted Least Connections

Сочетает least connections с весами серверов. Решение о маршрутизации учитывает и количество активных соединений, и вес каждого сервера.

# HAProxy weighted least connections
backend app_servers
    balance leastconn
    server srv1 10.0.1.1:8080 weight 5 check
    server srv2 10.0.1.2:8080 weight 3 check
    server srv3 10.0.1.3:8080 weight 1 check

Least Response Time

Направляет запросы на сервер с минимальным временем ответа и наименьшим числом соединений. Требует от балансировщика активного измерения времени ответа бэкендов.

Подходит для: приложений, критичных к задержке, где важна стабильность времени ответа.

Random with Two Choices

Выбирает два случайных сервера и отправляет запрос на тот, у которого меньше соединений. Обеспечивает близкое к оптимальному распределение с минимальными вычислительными затратами — идеально для распределённых балансировщиков.

Сравнение алгоритмов

Проверки здоровья

Независимо от алгоритма, проверки здоровья обязательны — они гарантируют, что трафик направляется только на работающие серверы:

• Пассивные проверки — балансировщик помечает сервер как недоступный после серии сбоев
• Активные проверки — балансировщик периодически отправляет зондирующие запросы

# HAProxy активные проверки здоровья
backend app_servers
    balance roundrobin
    option httpchk GET /health
    http-check expect status 200
    server srv1 10.0.1.1:8080 check inter 5s fall 3 rise 2
    server srv2 10.0.1.2:8080 check inter 5s fall 3 rise 2

Как выбрать алгоритм

• Одинаковые серверы, однородные запросы → Round Robin
• Разная мощность серверов → Weighted Round Robin
• Переменное время обработки → Least Connections
• Нужна привязка сессий → IP Hash или cookie-based
• Критична задержка → Least Response Time
• Распределённая / мультирегиональная система → Random with Two Choices

Итоги

Алгоритмы балансировки нагрузки варьируются от простого round robin до динамических методов, адаптирующихся к текущему состоянию серверов. Оптимальный выбор зависит от однородности серверов, паттернов запросов, требований к сессиям и чувствительности к задержке. На практике least connections — хороший вариант по умолчанию для большинства веб-приложений, так как он естественно адаптируется к переменным нагрузкам без ручной настройки весов.