Что такое round robin: запросы по кругу и ограничения DNS-балансировки

Самый простой круг: A, B, C — и снова A

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

В настоящем продукте на последовательность влияют процессы, параллельные обращения, состояние пула и конкретная реализация. Поэтому запись A, B, C объясняет идею, а не обещает буквально такой порядок во всех журналах.

Что именно идёт по кругу: запрос или соединение

Тысяча HTTP-операций внутри одного долгого соединения и тысяча новых соединений — разные профили. Keep-alive, HTTP/2, длительные подключения и повторное использование связей могут влиять на видимую статистику. Сравнивайте счётчики именно того объекта, который балансируется.

Разницу уровней и путь обращения подробнее показывает статья о балансировщике нагрузки. Название алгоритма без описания режима ещё не говорит, как будут распределены пользователи.

Weighted round robin: узлы с разными весами

Если A имеет вес 2, а B — вес 1, целевое соотношение выборов при подходящих условиях составляет 2:1. В нашем учебном симуляторе это реализовано повторяющимися слотами A, A, B. За девять выборов получится шесть у A и три у B.

Реальные продукты могут использовать более плавное распределение. Одинаковые итоговые доли не требуют одинаковой короткой последовательности. У HAProxy и NGINX веса рассматриваются в контексте собственных алгоритмов и ограничений.

Вес — не автоматический датчик свободной мощности. Если указать 2 для слабого сервера, он не станет производительнее. Долю назначают по измерениям и проверяют при реальных типах обращений, а не только по числу ядер в описании ВМ.

Равное число запросов — разная работа серверов

Условный пример: A получил десять коротких запросов по 20 мс, B — десять тяжёлых по 500 мс. Сумма длительностей составляет 200 мс против 5 000 мс. Число запросов одинаковое, условная сумма времени — отличается в 25 раз.

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

• Запросы могут различаться по данным, SQL, размеру файлов и работе кэша.
• Узлы могут конкурировать за общий диск, сеть или СУБД.
• Одно длинное соединение может держать ресурсы дольше множества коротких.
• Ошибки и повторы способны добавлять работу, которую не видно в простом счётчике успешных ответов.

Когда сравнивать с least connections и хешированием

Round robin часто удобен как понятная отправная точка для похожих узлов и сравнительно однородного трафика. Для долгих соединений и неодинаковой работы проверяют альтернативы. Алгоритмы описаны в руководстве NGINX и HAProxy Backends.

Выбор подтверждают задержками, ошибками, очередями и остаточной мощностью при отказе. Один удачный средний показатель не объясняет жалобы тех пользователей, чьи операции попали в длинный хвост.

Круговая очередь не узнаёт сама, что сервер сломан

Алгоритм выбирает участника из того набора, который система считает подходящим. Чтобы исключить неработающий узел, нужны проверки, обработка ошибок или другой предусмотренный механизм. Это отдельная часть конфигурации.

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

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

Почему один пользователь может всё время попадать на A

• Persistence: cookie или другой механизм сохраняет привязку.
• Долгое соединение: получатель уже выбран на уровне транспорта.
• Состав пула: B и C могут быть исключены проверками или административным состоянием.
• Несколько процессов / экземпляров: их локальные состояния и наблюдаемые выборки могут различаться.
• Короткое наблюдение: несколько ответов недостаточны для вывода о долгосрочном распределении.

Сначала проверьте режим, привязку, готовность и журналы, затем меняйте алгоритм. Если приложение хранит сеанс только на одном узле, отключение привязки ради красивой равномерности способно выбросить пользователя из системы.

DNS round robin: адреса в ответе, а не диспетчер каждого HTTP-запроса

У имени может быть несколько A-записей. DNS-сервер может менять порядок их выдачи, а клиент и резолвер дальше обрабатывают ответ по собственным правилам. DNS при этом не сидит между каждым HTTP-запросом и приложением.

Условная запись зоны ниже показывает набор адресов. Это документальные адреса для примера, не инструкция менять рабочую DNS-зону:

portal.example.test. 300 IN A 192.0.2.10
portal.example.test. 300 IN A 192.0.2.11
portal.example.test. 300 IN A 192.0.2.12

Несколько A-записей не задают веса 2:1 и не проверяют готовность HTTPS. Дублирование одинаковой A-записи не является надёжным способом задать вес: одинаковые записи набора не следует считать отдельными слотами.

Историческая идея описана в RFC 1794, а ограничения изменения порядка — в руководстве BIND 9. Конкретные настройки сервера и поведение клиента проверяют отдельно.

Кэш, TTL и соединения: почему смена DNS не мгновенная

TTL связан со сроком хранения DNS-данных в кэше. Он не является таймером проверки приложения и не заставляет существующее TCP-соединение закрыться. После DNS-выбора клиент способен долго обращаться к одному адресу по уже установленному соединению.

Набор ответов проходит через резолвер и локальные механизмы кэширования. Их наблюдаемое поведение и выбор адреса влияют на распределение. Поэтому несколько сотрудников за одним резолвером нельзя считать независимыми чередующимися DNS-опросами на каждый клик.

Правила TTL рассматриваются в RFC 2181. При определённых условиях резолверы с поддержкой serve-stale могут возвращать ранее истёкшие данные для устойчивости разрешения имён — это отдельный механизм RFC 8767, а не правило для каждого клиента.

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

Если один DNS-адрес недоступен, кто его исключит?

Обычный набор A-записей не знает, принимает ли приложение соединения. Недоступный адрес может оставаться в ответе. Некоторые клиенты пробуют другой, другие проявляют иное поведение или задержку; рассчитывать на одинаковое восстановление всех программ нельзя.

Для локального балансировщика выбор получателя и health checks находятся ближе к рабочему запросу. Это тоже не абсолютная гарантия: остаются время обнаружения, сам входной слой, данные и сеть. Сравнивайте полный путь, а не только название алгоритма.

Где уместен DNS, а где нужен балансировщик

• Нужно управлять HTTP-маршрутами, TLS и проверками узлов: рассматривают подходящий прокси/балансировщик.
• Нужно выбирать площадку или внешний вход по DNS: изучают DNS-схему с её кэшами, мониторингом и возможностями услуги.
• Нужно распределять обычную однородную работу между похожими узлами: round robin может быть простой базовой моделью.
• Нужны привязка, долгие соединения или сложная разница нагрузки: сравнивают дополнительные механизмы и алгоритмы.

DNS и балансировщик могут работать вместе: DNS приводит клиента к доступному входу, а тот выбирает внутренний сервер. При этом надо резервировать сам вход, а не ставить единственный балансировщик и объявлять всю систему устойчивой.

Локальный симулятор: увидим последовательность сами

В архиве ниже лежит round-robin-demo.py. Нужен Python 3; внешние библиотеки не требуются. Программа не открывает порты, не делает HTTP- или DNS-запросов и не меняет настройки: она выводит JSON с последовательностью и счётчиками.

Команды показаны для Linux/macOS с python3. На Windows используйте доступный в вашей системе Python 3. Запускайте из каталога распакованного архива.

python3 round-robin-demo.py --servers A:1 B:1 C:1 --requests 12

--servers задаёт имена и веса, --requests — количество учебных выборов. В выводе ищите sequence и counts. Для этой команды программа даёт четыре выбора каждому участнику:

{
  "A": 4,
  "B": 4,
  "C": 4
}

Это выполненный локальный расчёт модели, а не измерение скорости серверов или доказательство работы HAProxy.

Меняем веса и вручную исключаем B

python3 round-robin-demo.py --servers A:2 B:1 --requests 9

Модель повторяет слоты A, A, B. Итог девяти выборов — A: 6, B: 3. Это простая учебная реализация weighted round robin, а не копия плавного алгоритма конкретного вендора.

python3 round-robin-demo.py --servers A:1 B:1 C:1 --requests 12 --down B

--down B вручную удаляет B из набора подходящих. За 12 выборов A и C получают по шесть, B — ноль. Программа не обнаруживала отказ: пользователь передал готовое решение о состоянии участника.

В реальном проекте такое решение дают проверки, ошибки или оператор. Обозначение «B выключен» в симуляторе не подтверждает, что на вашей сети настроен механизм исключения. Все неподходящие участники приводят к явной ошибке модели, а не к отправке запросов случайному адресу.

Как смотреть DNS-ответ и не перепутать его с HTTP

Ниже используются portal.example.test и 192.0.2.53 как подстановки. Для опыта задайте имя и DNS-сервер своего согласованного контура. Реальные DNS- и HTTP-проверки вашей инфраструктуры при подготовке статьи не выполнялись.

Linux с dig

dig portal.example.test A +noall +answer

+noall +answer оставляет секцию ответа, где видны адреса и TTL. +short удобен для списка, но скрывает часть контекста. Повтор запроса к одному кэширующему резолверу не обязан показывать ротацию авторитетного сервера.

dig @192.0.2.53 portal.example.test A +noall +answer

@ задаёт конкретный DNS-сервер. Сравнивайте его ответ с ответом штатного резолвера; учитывайте роль сервера, зону и кэш. Описание ключей есть в руководстве dig.

Windows PowerShell

Resolve-DnsName -Name portal.example.test -Type A -Server 192.0.2.53 -DnsOnly -NoHostsFile

Команда запрашивает A-записи через указанный сервер; -DnsOnly оставляет DNS, -NoHostsFile исключает файл hosts. Параметры описаны у Microsoft. Изучайте адреса и TTL в результате. Это просмотр DNS, а не проверка доступности веб-приложения.

HTTP через существующий тестовый вход

for request_no in $(seq 1 10); do
    curl --noproxy '*' --silent --show-error --max-time 3 http://127.0.0.1:18080/
done

Для сравнения backend нужны их различимые ответы или защищённые журналы. В учебной статье о HAProxy вход работает на 127.0.0.1:18080: выполнить эту серию можно только после запуска того стенда. Наличие нескольких DNS-адресов не является результатом этой HTTP-проверки.

Три понятные ситуации из эксплуатации

Что измерять вместо одной красивой пропорции 50/50

• Выборы и работа: число запросов и соединений по узлам, длительность, активные соединения и очереди.
• Качество: ошибки, таймауты, повторные операции, p95/p99 вместе со средним.
• Ресурсы: CPU, память, диски, сеть и конкуренция за общую базу.
• Состояния: health checks, административный вывод, возврат, веса и история изменений.
• Пользователь: вход, сохранность сеанса, файл, документ и работа после переключения.

Сравнение проводят при одинаковом профиле обращений и данных. Короткий учебный цикл не является нагрузочным испытанием. Для расследования сохраняют время, идентификатор запроса, выбранный backend и связь с изменениями; чувствительные данные в журналы без необходимости не добавляют.

Семь вопросов перед выбором схемы

1. Распределяем запросы, соединения или DNS-адреса?
2. Какие узлы действительно готовы и кто это проверяет?
3. Нужна ли привязка пользователя и где хранится состояние?
4. Однородны ли операции и чем подтверждены веса?
5. Выдержит ли оставшаяся система нагрузку при отказе?
6. Какие кэши, TTL и долгие соединения влияют на переключение?
7. Чем подтвердим результат: журналами, операцией, замером, восстановлением?

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

Симулятор и карточка проверки

Поможем выбрать и проверить распределение нагрузки

Вопросы и ответы