Алгоритмы балансировки — HAProxy Expert: От основ

Алгоритмы балансировки HAProxy

Выбор правильного алгоритма балансировки критичен для производительности и корректной работы приложения.

#Обзор алгоритмов

Алгоритм	Layer	Use Case	Session Affinity
roundrobin	L4/L7	Универсальный	Нет
leastconn	L4/L7	Длительные соединения	Нет
first	L4/L7	Минимизация активных серверов	Нет
source	L4	Сессионность по IP	Да
uri	L7	Кэширование, CDN	Да
url_param	L7	Сессионность по параметру	Да
hdr	L7	Сессионность по header	Да
random	L4/L7	Рандомизация	Нет

#roundrobin

backend web_servers
    balance roundrobin
    server web1 192.168.1.10:8080 check
    server web2 192.168.1.11:8080 check
    server web3 192.168.1.12:8080 check

Как работает:

Запрос 1 → web1
Запрос 2 → web2
Запрос 3 → web3
Запрос 4 → web1
Запрос 5 → web2
...

Преимущества:

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

Недостатки:

❌ Не учитывает загрузку серверов
❌ Не подходит для длительных соединений
❌ Проблемы при разной мощности серверов

Когда использовать:

Веб-серверы с одинаковой мощностью
Короткие запросы (HTTP GET/POST)
Stateless приложения

#leastconn

backend db_servers
    balance leastconn
    server db1 192.168.1.10:3306 check
    server db2 192.168.1.11:3306 check
    server db3 192.168.1.12:3306 check

Как работает:

Сервер 1: 5 активных соединений
Сервер 2: 2 активных соединения  ← Новый запрос сюда
Сервер 3: 8 активных соединений

Преимущества:

✅ Учитывает реальную загрузку серверов
✅ Идеально для длительных соединений
✅ Автоматический баланс при разной нагрузке

Недостатки:

❌ overhead на подсчёт соединений
❌ Может «гонять» запросы при equal load

Когда использовать:

Базы данных (MySQL, PostgreSQL)
WebSocket соединения
Long polling
FTP серверы

#first

backend api_servers
    balance first
    server api1 192.168.1.10:8080 check
    server api2 192.168.1.11:8080 check
    server api3 192.168.1.12:8080 check

Как работает:

Использует первый сервер с доступными соединениями
Остальные серверы — резерв
Минимизирует количество активных серверов

Преимущества:

✅ Экономия ресурсов (меньше активных серверов)
✅ Хорошо для autoscaling групп

Недостатки:

❌ Неравномерная нагрузка
❌ Первый сервер может быть перегружен

Когда использовать:

Autoscaling группы (экономия денег)
Резервные серверы
Development среды

#source (IP Hash)

backend web_servers
    balance source
    server web1 192.168.1.10:8080 check
    server web2 192.168.1.11:8080 check
    server web3 192.168.1.12:8080 check

Как работает:

Клиент 192.168.1.100 → hash → web2
Клиент 192.168.1.101 → hash → web1
Клиент 192.168.1.100 → hash → web2 (всегда тот же)

Преимущества:

✅ Session affinity без cookies
✅ Клиент всегда на одном сервере

Недостатки:

❌ Неравномерность при NAT (один IP для многих)
❌ Проблемы при добавлении/удалении серверов

Когда использовать:

Приложения с сессиями в памяти сервера
Когда нельзя использовать cookies
UDP трафик

#uri

backend cache_servers
    balance uri
    server cache1 192.168.1.10:6379 check
    server cache2 192.168.1.11:6379 check
    server cache3 192.168.1.12:6379 check

Как работает:

GET /images/logo.png → hash → cache2
GET /images/logo.png → hash → cache2 (всегда тот же)
GET /css/style.css   → hash → cache1

Преимущества:

✅ Один URI всегда на одном сервере
✅ Эффективное кэширование
✅ Распределение по consistent hash

Недостатки:

❌ Проблемы при изменении числа серверов
❌ Hot spots для популярных URI

Когда использовать:

Кэш серверы (Redis, Memcached)
CDN edge серверы
Static content

#uri с параметрами

backend api_servers
    balance uri whole
    server api1 192.168.1.10:8080 check
    server api2 192.168.1.11:8080 check

Параметры:

whole — хэш всего URI
path — только path (без query string)
query — только query string

#url_param

backend api_servers
    balance url_param session_id
    server api1 192.168.1.10:8080 check
    server api2 192.168.1.11:8080 check

Как работает:

GET /api/data?session_id=abc123 → hash → web2
GET /api/data?session_id=abc123 → hash → web2
GET /api/data?session_id=xyz789 → hash → web1

Преимущества:

✅ Сессионность по параметру URL
✅ Работает без cookies

Недостатки:

❌ Параметр должен быть в каждом запросе
❌ Не работает для POST без query string

Когда использовать:

Legacy приложения с session в URL
API с API key в query string

#hdr (Header Hash)

backend api_servers
    balance hdr(X-User-ID)
    server api1 192.168.1.10:8080 check
    server api2 192.168.1.11:8080 check

Как работает:

X-User-ID: 12345 → hash → web2
X-User-ID: 12345 → hash → web2
X-User-ID: 67890 → hash → web1

Преимущества:

✅ Гибкая сессионность по любому header
✅ Работает с кастомными заголовками

Недостатки:

❌ Header должен присутствовать
❌ Не работает для анонимных запросов

Когда использовать:

Микросервисы с user ID в header
JWT токены в header
API key аутентификация

#hdr с fallback

backend api_servers
    balance hdr(X-User-ID)
    http-request set-header X-User-ID %[src] if !{ hdr(X-User-ID) }
    server api1 192.168.1.10:8080 check
    server api2 192.168.1.11:8080 check

Fallback на IP если header нет.

#random

backend web_servers
    balance random
    server web1 192.168.1.10:8080 check
    server web2 192.168.1.11:8080 check
    server web3 192.168.1.12:8080 check

Как работает:

Случайный выбор сервера
Равномерное распределение в долгосроке

Преимущества:

✅ Простота
✅ Нет hot spots при равномерном трафике

Недостатки:

❌ Непредсказуемость
❌ Проблемы с отладкой

Когда использовать:

Тестирование
Stateless сервисы
A/B тестирование (в сочетании с ACL)

#Consistent Hashing

backend cache_servers
    balance consistent-hash
    hash-type consistent
    server cache1 192.168.1.10:6379 check
    server cache2 192.168.1.11:6379 check
    server cache3 192.168.1.12:6379 check

Преимущества:

✅ Минимальное перераспределение при изменении числа серверов
✅ Подходит для distributed cache

Когда использовать:

Distributed кэши (Redis Cluster, Memcached)
Sharded базы данных
Когда важна стабильность hash mapping

#Weighted балансировка

backend web_servers
    balance roundrobin
    server web1 192.168.1.10:8080 check weight 10
    server web2 192.168.1.11:8080 check weight 5
    server web3 192.168.1.12:8080 check weight 5

Распределение:

web1: 50% трафика (10/20)
web2: 25% трафика (5/20)
web3: 25% трафика (5/20)

Когда использовать:

Серверы разной мощности
Постепенный ввод новых серверов
Canary deployment

#Dynamic Weight с Stats Socket

# Изменить вес сервера
echo "set server web_servers/web1 weight 75" | socat /var/run/haproxy/admin.sock stdio

# Показать веса
echo "show servers state" | socat /var/run/haproxy/admin.sock stdio

Использование:

Canary deployment (постепенное увеличение веса)
Maintenance mode (вес → 0)
A/B тестирование

#Выбор алгоритма: Decision Tree

                    ┌─────────────────┐
                    │ Есть сессии?    │
                    └────────┬────────┘
                             │
            ┌────────────────┼────────────────┐
            │ NO             │                │ YES
            ▼                                 ▼
    ┌──────────────┐                  ┌──────────────┐
    │ Длинные      │                  │ Cookies?     │
    │ соединения?  │                  └──────┬───────┘
    └──────┬───────┘                         │
           │                                 │
    ┌──────┴───────┐                ┌────────┼────────┐
    │ YES          │ NO             │ YES    │        │ NO
    ▼              ▼                ▼               ▼
┌────────┐   ┌──────────┐    ┌──────────┐   ┌────────────┐
│leastconn│  │roundrobin│    │cookie    │   │source/hash │
└────────┘   └──────────┘    │stickiness│   │(IP based)  │
                             └──────────┘   └────────────┘

#Full Example

# Веб-серверы (короткие запросы)
backend web_servers
    balance roundrobin
    server web1 192.168.1.10:8080 check weight 10
    server web2 192.168.1.11:8080 check weight 10
    server web3 192.168.1.12:8080 check weight 5 backup

# API (сессии)
backend api_servers
    balance leastconn
    cookie SERVERID insert indirect nocache
    server api1 192.168.1.20:8080 check cookie api1 weight 10
    server api2 192.168.1.21:8080 check cookie api2 weight 10

# Кэш (consistent hashing)
backend cache_servers
    balance consistent-hash
    hash-type consistent
    server cache1 192.168.1.30:6379 check
    server cache2 192.168.1.31:6379 check

# Базы данных
backend db_servers
    balance leastconn
    mode tcp
    server db1 192.168.1.40:3306 check
    server db2 192.168.1.41:3306 check

Алгоритм

Layer

Use Case

Session Affinity

roundrobin

L4/L7

Универсальный

Нет

leastconn

L4/L7

Длительные соединения

Нет

first

L4/L7

Минимизация активных серверов

Нет

source

Сессионность по IP

Да

uri

Кэширование, CDN

Да

url_param

Сессионность по параметру

Да

hdr

Сессионность по header

Да

random

L4/L7

Рандомизация

Нет

Сервер 1: 5 активных соединений Сервер 2: 2 активных соединения ← Новый запрос сюда Сервер 3: 8 активных соединений

┌─────────────────┐ │ Есть сессии? │ └────────┬────────┘ │ ┌────────────────┼────────────────┐ │ NO │ │ YES ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ Длинные │ │ Cookies? │ │ соединения? │ └──────┬───────┘ └──────┬───────┘ │ │ │ ┌──────┴───────┐ ┌────────┼────────┐ │ YES │ NO │ YES │ │ NO ▼ ▼ ▼ ▼ ┌────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ │leastconn│ │roundrobin│ │cookie │ │source/hash │ └────────┘ └──────────┘ │stickiness│ │(IP based) │ └──────────┘ └────────────┘