Ответ
Round Robin (RR) — простейший алгоритм балансировки нагрузки, при котором входящие запросы распределяются по списку бэкенд-серверов строго по порядку, циклически. После отправки запроса на последний сервер в списке алгоритм возвращается к первому.
Конфигурация в Nginx (используется по умолчанию для upstream):
http {
upstream backend_pool {
# Сервера получают запросы по очереди: 1, 2, 3, 1, 2, 3...
server backend01.example.com:8080;
server backend02.example.com:8080;
server backend03.example.com:8080;
# Параметры для проверки здоровья (health check) критически важны с RR
# Балансировщик будет исключать "unhealthy" сервера из цикла
}
server {
listen 80;
location / {
proxy_pass http://backend_pool;
}
}
}
Плюсы с точки зрения DevOps:
- Предельная простота и предсказуемость.
- Гарантированная равномерность в долгосрочной перспективе при одинаковых запросах.
- Низкие накладные расходы, не требует сбора метрик с бэкендов.
Ограничения и минусы:
- Не учитывает: текущую загрузку CPU/RAM серверов, время ответа, количество активных соединений. Медленный или перегруженный сервер получит столько же запросов, сколько и быстрый.
- Не подходит для stateful-сервисов, если sticky session не настроена отдельно. Последовательные запросы от одного пользователя будут попадать на разные сервера.
- Проблема с «тяжёлыми» запросами: Один долгий запрос на сервере не помешает RR направить на него следующий, что может усугубить его загрузку.
Когда использовать: Для пула однородных (identical) бэкенд-серверов, обрабатывающих stateless-запросы примерно одинаковой сложности. Часто является отправной точкой, от которой переходят к более интеллектуальным алгоритмам (Least Connections, Weighted Round Robin) по мере роста сложности системы.