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

⚙️ 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 Естественно про каждый вид балансировки стоит почитать отдельно, все тонкости не уместятся ни в одну шпаргалку ✍️