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

⚙️ Round Robin (RR)
Раздаёт запросы по очереди — 1→2→3→1...

✅ Простота и скорость
✅ Работает «из коробки» почти везде
❌ Не учитывает загрузку сервера
❌ Если железо на серверах разное — слабый сервер захлебнётся, пока более мощные будут простаивать
❌ Не учитывает сложность запросов. На один сервер может упасть десяток долгих POST-запросов, пока другие получат простой GET и будут простаивать

Где есть: везде (nginx, haproxy и т.д.)

⚙️ Weighted Round Robin (WRR)
То же самое, что и RR, только с возможностью указать “вес” сервера. На мощный сервер — 3 запроса, на слабый — один запрос.

✅ Учитывает разную мощность железа
❌ Вес статичен
❌ Легко забыть обновить веса в конфиге при изменениях
❌ Также не учитывает сложность запросов

Где есть: везде (nginx, haproxy и т.д.)

⚙️ Least Connections (LC)
Направляет трафик туда, где меньше активных соединений

✅ Учитывает текущую "загруженность"
✅ Идеально для долгих сессий (WebSocket, RDP)
❌ Не различает лёгкие и тяжёлые соединения
❌ Игнорирует мощность железа

Где есть: haproxy, traefik

⚙️ Least Response Time (LRT)
Измеряет время ответа сервера и шлёт туда, где быстрее

✅ Умный выбор по реальной скорости
✅ Быстро реагирует на "тормоза"
❌ Чувствителен к сетевым "скачкам"
❌ Нужно заморочиться с health check’ами

Где есть: haproxy (встроенно), nginx (с Lua/расширениями)

⚙️ IP Hash
Клиенты с одного IP всегда попадают на один сервер

✅ Простая привязка сессии без кук
✅ Подходит для stateful-приложений
❌ Перегрузка, если много клиентов за одним NAT
❌ Удаление сервера = обрыв сессий

Где есть: nginx, haproxy

⚙️ Resource-Based (Адаптивная)
Агенты на серверах следят за CPU, RAM, I/O и передают данные балансировщику.

✅ Максимальная точность по загрузке
❌ Требует настройки агентов, метрик и логики

Где есть: traefik, haproxy (Lua), кастомный nginx

Отдельно стоит упомянуть health check’и. Если TCP-порт открыт — это ещё не значит, что всё работает. Надежнее использовать HTTP/HTTPS-запрос на специальный endpoint (например, /health) с проверкой внутренних зависимостей (доступность базы, очередей, кеша и т.д.). Это создаёт дополнительную нагрузку, поэтому настройке нужно уделить внимание — частота, таймауты, и какие компоненты действительно критичны.

P.S Естественно про каждый вид балансировки стоит почитать отдельно, все тонкости не уместятся ни в одну шпаргалку ✍️