Алгоритмы балансировки нагрузки

Краткое руководство по распределению трафика между серверами. Правильный выбор алгоритма позволяет масштабировать приложение, повышать производительность и обеспечивать высокую доступность.

Round Robin

Запросы распределяются последовательно: сервер A → B → C → A → … Подходит, когда серверы имеют одинаковую мощность, а длительность запросов примерно одинаковая. Типичный пример — stateless REST‑API.

Sticky Round Robin

Это вариант Round Robin с «прилипанием». Первый запрос клиента обслуживается по обычному круговому алгоритму, а все последующие запросы от того же клиента направляются на тот же сервер. Привязка обычно реализуется через cookie или IP‑адрес. Требуется, когда сессия хранится в памяти сервера (старые PHP‑приложения, корзины без Redis и т.п.). Перенаправление клиента на другой сервер приведёт к потере сессии.

Weighted Round Robin

Классический Round Robin, но каждый сервер получает вес. Сервер с весом 0.8 обрабатывает 80 % запросов. Позволяет вводить новые узлы постепенно: новый сервер стартует с небольшим весом (например 0.1) и постепенно увеличивается по мере проверки.

IP / URL Hash

Для клиента вычисляется хеш по IP‑адресу (или URL) и на его основе выбирается бекенд. Пока IP не меняется, пользователь всегда попадает на один и тот же сервер. Подходит, если сессия хранится в памяти (старые PHP‑приложения, WebSocket‑серверы). Хеш по URL полезен для кэширующих серверов: один и тот же URL всегда направляется на один бекенд, что исключает дублирование кэша.

Least Connections

Запрос направляется на сервер с наименьшим числом активных соединений. Эффективно при сильно разнородных длительностях запросов (от 10 мс до 30 сек). Применяется для WebSocket‑соединений, SSH‑туннелей и аналогичных сценариев.

Least Response Time

Трафик отправляется туда, где сервер отвечает быстрее в данный момент. Балансировщик измеряет latency в реальном времени. Позволяет уменьшить нагрузку на перегретый сервер, пока он не восстановится.