Алгоритм балансировки стоит выбирать по поведению workload, а не по популярности названия.
Глава помогает сравнить Round Robin, Least Connections и Consistent Hashing через длину запросов, skew нагрузки, state affinity, hot keys и цену перераспределения трафика при изменении пула инстансов.
Для system design interview эта тема особенно полезна тем, что переводит разговор из уровня "какой алгоритм взять" в уровень "какой профиль трафика мы на самом деле защищаем и что сломается при неверном выборе".
Практическая польза главы
Алгоритм по workload
Сопоставляйте алгоритм (RR/LC/Hash) с профилем нагрузки, длительностью сессий и требованиями к affinity.
Цена выбора
Проговаривайте издержки: uneven load, hot spots, сложность rebalance и поведение при падении нод.
Наблюдаемость
Определяйте метрики справедливости распределения и ранние сигналы, что алгоритм нужно сменить или дополнить.
Interview trade-offs
Показывайте, как выбор алгоритма меняется при переходе от stateless API к stateful/realtime сценариям.
Reference
Envoy Load Balancing
Практическое описание алгоритмов балансировки и сценариев применения.
Алгоритм балансировки напрямую влияет на latency, устойчивость и эффективность использования ресурсов. Один и тот же пул инстансов может работать по-разному в зависимости от того, выбираете ли вы равномерное распределение, адаптацию к текущей нагрузке или маршрутизацию по ключу.
Равномерность
Round Robin держит базовую равномерность, если узлы близки по мощности.
Адаптация к нагрузке
Least Connections быстрее реагирует на mix коротких и длинных запросов.
Key locality
Consistent Hashing уменьшает cache misses и снижает remap при изменениях пула.
Устойчивость
Комбинируйте алгоритм с health checks, slow-start и draining на каждом rollout.
Плейбук выбора алгоритма
Зафиксируйте профиль трафика
Шаг 1Определите длину запросов, burst-поведение и долю stateful операций.
Сопоставьте алгоритм и workload
Шаг 2Round Robin для простого пула, Least Connections для mixed latency, Consistent Hashing для key locality.
Проверьте деградационные сценарии
Шаг 3Смоделируйте shutdown/degraded node и оцените p95/p99, retry storm, remap ключей.
Закрепите operational guardrails
Шаг 4Включите health policy, slow-start, draining и алерты по saturation/hot keys.
Базовые алгоритмы и визуализация
Визуализация показывает, как один и тот же поток запросов распределяется по-разному в зависимости от выбранного алгоритма.
Round Robin
Запросы распределяются по серверам по кругу: S1 -> S2 -> S3 -> S1.
Плюсы
- Очень простая реализация и предсказуемое поведение.
- Хорошо подходит для stateless backend с одинаковыми узлами.
- Низкий runtime overhead у балансировщика.
Ограничения
- Не учитывает текущую загрузку и медленные узлы.
- При неоднородных серверах может ухудшать latency.
Request Queue
Load Balancer
Round Robin
Server A
Server B
Server C
Готово к симуляции. Запусти авто-режим или сделай один шаг.
Последнее решение: —
Сравнение и trade-offs
Выбирайте алгоритм не по “популярности”, а по фактическому профилю workload и требованиям к state/locality.
| Algorithm | State awareness | Failover behavior | Balancing quality | Complexity | Best fit |
|---|---|---|---|---|---|
| Round Robin | Нет | Простое исключение узла | Средняя | Низкая | Stateless, homogeneous pool |
| Least Connections | Active connections | Хорошо при burst + long-lived connections | Высокая | Средняя | Mixed latency workload |
| Consistent Hashing | Key-aware routing | Частичный remap на соседние узлы | Зависит от virtual nodes | Высокая | Stateful/cache-sensitive traffic |
Практика выбора
Быстрые правила
- Начинайте с Round Robin для простых stateless API.
- Переходите на Least Connections при длинных или неравномерных запросах.
- Используйте Consistent Hashing, когда важны locality и sticky state.
- Проверяйте решение на пиковом профиле, а не только на среднем трафике.
Частые ошибки
- Выбирать алгоритм без анализа профиля трафика (длина запросов, burst, key skew).
- Использовать Consistent Hashing без virtual nodes и мониторинга hot keys.
- Игнорировать health checks и slow-start для новых инстансов.
- Считать active connections единственной метрикой загрузки без CPU/RPS/p99 latency.
- Смешивать sticky и non-sticky маршрутизацию без явной политики fallback.
Мини-чеклист перед продом
Связанные главы
- Балансировка трафика (Load Balancing) - даёт архитектурный контекст L4/L7, health checks и GSLB, поверх которого выбираются конкретные алгоритмы.
- Принципы проектирования масштабируемых систем - объясняет, как распределение трафика связано с latency, throughput и общими scalability trade-offs.
- Service Discovery - показывает, как поддерживать актуальный пул инстансов, на который алгоритм принимает решения.
- Service Mesh Architecture - переносит алгоритмы балансировки в сервис-сервис трафик и дополняет их retry/outlier detection политиками.
- Стратегии кэширования - помогает разбирать key locality и hot-key эффекты, критичные для consistent hashing.
- Multi-region / Global Systems - добавляет региональный слой распределения трафика и стратегию failover между площадками.
- API Gateway (routing и balancing) - показывает прикладной сценарий, где алгоритмы балансировки используются вместе с L7 routing-политиками.