roundrobin, leastconn, hash, uri, hdr — выбор и применение
Выбор правильного алгоритма балансировки критичен для производительности и корректной работы приложения.
| Алгоритм | 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 | Рандомизация | Нет |
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
...
Преимущества:
Недостатки:
Когда использовать:
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 активных соединений
Преимущества:
Недостатки:
Когда использовать:
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Как работает:
Преимущества:
Недостатки:
Когда использовать:
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 (всегда тот же)
Преимущества:
Недостатки:
Когда использовать:
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
Преимущества:
Недостатки:
Когда использовать:
backend api_servers
balance uri whole
server api1 192.168.1.10:8080 check
server api2 192.168.1.11:8080 checkПараметры:
whole — хэш всего URIpath — только path (без query string)query — только query stringbackend 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
Преимущества:
Недостатки:
Когда использовать:
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
Преимущества:
Недостатки:
Когда использовать:
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 checkFallback на IP если header нет.
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Как работает:
Преимущества:
Недостатки:
Когда использовать:
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Преимущества:
Когда использовать:
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Распределение:
Когда использовать:
# Изменить вес сервера
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Использование:
┌─────────────────┐
│ Есть сессии? │
└────────┬────────┘
│
┌────────────────┼────────────────┐
│ NO │ │ YES
▼ ▼
┌──────────────┐ ┌──────────────┐
│ Длинные │ │ Cookies? │
│ соединения? │ └──────┬───────┘
└──────┬───────┘ │
│ │
┌──────┴───────┐ ┌────────┼────────┐
│ YES │ NO │ YES │ │ NO
▼ ▼ ▼ ▼
┌────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐
│leastconn│ │roundrobin│ │cookie │ │source/hash │
└────────┘ └──────────┘ │stickiness│ │(IP based) │
└──────────┘ └────────────┘
# Веб-серверы (короткие запросы)
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Изучим ACL (Access Control Lists) для условной маршрутизации запросов.
Вопросы ещё не добавлены
Вопросы для этой подтемы ещё не добавлены.