Ответ
В DevOps-практике я работал со следующими методами балансировки трафика, настраивая их в Nginx, HAProxy и облачных балансировщиках (AWS ALB/NLB, GCP Cloud Load Balancing):
1. Round Robin Запросы распределяются по серверам по очереди. Простая настройка, но не учитывает текущую нагрузку на серверы.
upstream backend {
server backend1.example.com;
server backend2.example.com;
}
2. Least Connections Новый запрос направляется на сервер с наименьшим количеством активных соединений. Идеально подходит для долгих соединений (WebSocket, long-polling).
upstream backend {
least_conn;
server backend1.example.com;
server backend2.example.com;
}
3. IP Hash IP-адрес клиента хешируется для определения сервера. Один и тот же клиент всегда попадает на один сервер, что обеспечивает поддержку sticky-сессий без внешнего хранилища сессий.
4. Weighted методы (Round Robin/Least Connections) Серверам назначаются веса в зависимости от их мощности (CPU, RAM). Например, более мощный сервер получает вес 3, а менее мощный — 1.
upstream backend {
server backend1.example.com weight=3;
server backend2.example.com weight=1;
}
5. Географическая балансировка (Geo-based) В облачных провайдерах (AWS Route 53, Cloudflare) трафик направляется на ближайший к пользователю регион на основе его DNS-запроса, что снижает задержку.
Выбор метода зависит от архитектуры приложения. Для stateless-сервисов подходит Least Connections, для stateful — IP Hash или использование внешнего хранилища сессий (Redis) с любым методом балансировки.