У тебя есть 3 сервера. Приходит 100 запросов. Как их распределить? Вот возможные варианты:

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

🔸Round Robin (циклический)

- Запрос 1 —> на сервер A
- Запрос 2 —> на сервер B
- Запрос 3 —> на сервер C
- Запрос 4 —> снова на сервер A
- И так по кругу бесконечно

Когда использовать: все сервера одинаковые, запросы примерно равны по времени обработки. Самый простой вариант.

🔸Weighted Round Robin (взвешенный циклический)

- Сервер A: 4 ядра, вес 4
- Сервер B: 8 ядер, вес 8
- Сервер C: 4 ядра, вес 4
- Из каждых 16 запросов: A получает 4, B — 8, C — 4

Когда использовать: мощности серверов разные, нужно распределять нагрузку пропорционально.

🔸Least Connections (наименьшее количество соединений)

- Сервер A: 50 активных соединений
- Сервер B: 30 активных соединений
- Сервер C: 45 активных соединений
- Следующий запрос уходит на сервер B (у него меньше всего соединений)

Когда использовать: запросы обрабатываются разное время, есть долгоживущие соединения, например WebSocket.

🔸Weighted Least Connections (взвешенный по соединениям)

- Сервер A: 50 соединений, 4 ядра → соотношение 12.5
- Сервер B: 30 соединений, 8 ядер → соотношение 3.75
- Сервер C: 45 соединений, 4 ядра → соотношение 11.25
- Следующий запрос идёт на сервер B (самое низкое соотношение)

Когда использовать: сервера разной мощности, при этом соединения держатся долго.

🔸IP Hash (хеш по IP)

- IP пользователя: 192.168.1.100
- Этот IP хешируется и всегда маршрутизируется на сервер B
- Один и тот же пользователь всегда попадает на один и тот же сервер

Когда использовать: нужна привязка сессии к конкретному серверу, нет общего session storage. Sticky sessions.

🔸Least Response Time (наименьшее время отклика)

- Сервер A: средний отклик 200 мс
- Сервер B: 150 мс
- Сервер C: 300 мс
- Следующий запрос уходит на сервер B (самый быстрый)

Когда использовать: производительность серверов разная, например, для чтения из реплик БД с разным lag.

🔸Random (случайное распределение)

- Просто выбирается случайный сервер
- Ничего отслеживать не нужно
- На больших масштабах работает удивительно неплохо

Когда использовать: простые распределённые системы, stateless-сервисы, когда учёт состояния не оправдан.

В большинстве продакшн-систем хорошо себя показывает вариант Least Connections с весами.

👉 Java Portal