> Какие алгоритмы балансировки существуют (Go)

Короткий ответ

Балансировка в распределённых системах решает задачу распределения нагрузки между узлами. Основные алгоритмы: round-robin, weighted round-robin, least connections, weighted least connections, consistent hashing, least response time, random с весами, а также алгоритмы на основе очередей (например, LIFO/FIFO с ограничениями). Для Go-бэкенда важно учитывать, что алгоритм должен быть эффективным при конкурентном доступе и минимизировать блокировки.

Подробное объяснение

Алгоритмы балансировки делятся на статические и динамические. Статические не учитывают текущее состояние узлов: round-robin, random, IP-hash. Динамические используют метрики: количество активных соединений, время ответа, загрузку CPU.

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

Consistent hashing критичен для кэширующих систем: минимизирует перераспределение ключей при добавлении/удалении узлов. Least response time требует сбора метрик времени ответа, что добавляет накладные расходы, но даёт адаптивность.

В Go-реализациях важно учитывать: атомарные счётчики вместо мьютексов, использование sync/atomic для счётчиков соединений, избегание аллокаций в горячем пути. Для consistent hashing часто используют кольцо с виртуальными узлами - это снижает дисбаланс при малом числе реальных узлов.

На практике

Для Go-бэкенда выбор алгоритма зависит от сценария:

• Если запросы короткие и однотипные - round-robin или random.
• Если есть долгоживущие соединения (WebSocket, gRPC stream) - least connections.
• Если нужна привязка клиента к узлу (сессии, кэш) - consistent hashing или IP-hash.
• Если узлы разной мощности - weighted варианты.

Важно помнить про health checks: алгоритм должен исключать недоступные узлы. В Go для этого часто используют atomic.Value для хранения списка активных узлов и обновляют его через фоновую горутину.

Также стоит учитывать, что балансировка на клиенте (в коде сервиса) отличается от балансировки на отдельном LB. Для клиентской балансировки в Go обычно используют библиотеки типа grpc-go с встроенными политиками, но для собственных реализаций лучше использовать sync/atomic и избегать блокировок.

Пример кода

Реализация weighted round-robin с атомарным счётчиком:

GO
type WeightedRoundRobin struct {
    nodes []*node
    mu    sync.Mutex // только для обновления списка
}

type node struct {
    addr   string
    weight int
    current int
}

func (w *WeightedRoundRobin) Next() string {
    w.mu.Lock()
    defer w.mu.Unlock()
    
    total := 0
    for _, n := range w.nodes {
        total += n.weight
    }
    
    // smooth weighted round-robin
    var best *node
    for _, n := range w.nodes {
        n.current += n.weight
        if best == nil || n.current > best.current {
            best = n
        }
    }
    best.current -= total
    return best.addr
}

Для least connections:

GO
type LeastConnections struct {
    nodes []*atomicNode
}

type atomicNode struct {
    addr   string
    conns  int64 // atomic
}

func (l *LeastConnections) Next() string {
    var best *atomicNode
    min := int64(^uint64(0) >> 1)
    for _, n := range l.nodes {
        c := atomic.LoadInt64(&n.conns)
        if c < min {
            min = c
            best = n
        }
    }
    atomic.AddInt64(&best.conns, 1)
    return best.addr
}

Как отвечать на собеседовании

Начните с классификации: статические vs динамические. Затем перечислите основные алгоритмы и их trade-off. Для senior-позиции важно показать понимание, когда какой алгоритм применять, а не просто перечислить названия.

Обязательно упомяните consistent hashing и его роль в кэшировании. Расскажите про виртуальные узлы и почему они нужны.

Для Go-специфики: упомяните sync/atomic, избегание мьютексов в горячем пути, использование atomic.Value для атомарной замены списка узлов. Если спросят про реализацию - покажите код, как выше.

Хорошо добавить про health checks и как они интегрируются с алгоритмом: например, фоновый poller обновляет список активных узлов.

Что проверяет интервьюер

Интервьюер оценивает:

• Понимание trade-off между алгоритмами, а не заучивание названий.
• Умение выбрать алгоритм под конкретный сценарий (долгие соединения, кэш, разная мощность).
• Знание особенностей реализации в Go: конкурентность, атомарность, производительность.
• Понимание consistent hashing и его применения.
• Умение рассуждать о масштабировании и отказоустойчивости.

Для senior-уровня важно, чтобы вы могли обосновать выбор и указать недостатки каждого подхода.

Типичные ошибки

• Перечисление алгоритмов без объяснения, когда их применять.
• Забывают про weighted варианты и их необходимость.
• Не упоминают consistent hashing - это критично для senior.
• Предлагают использовать мьютексы для счётчиков в Go - это антипаттерн.
• Не учитывают health checks и то, как алгоритм реагирует на недоступные узлы.
• Путают client-side и server-side балансировку.
• Не упоминают про виртуальные узлы в consistent hashing.