Даем шпаргалку по балансировке трафика между серверами, которая помогает разделять трафик, масштабировать приложения, улучшать производительность и доступность. Алгоритм выбирает, на какой сервер уйдёт следующий запрос. Выбор зависит от архитектуры приложения и характера нагрузки.
⚪️Round Robin
Запросы идут по очереди: сервер A → B → C → A → ... Подходит, если серверы одинаковые по мощности, а запросы примерно равной длительности. REST API без состояния — типичный кейс.
⚪️Stickу Round Robin
Это Round Robin с памятью. Sticky добавляет привязку: первый запрос от клиента распределяется по Round Robin, но потом все следующие его запросы идут на тот же сервер. Обычно через cookie или IP. Нужно там, где сессия хранится на сервере — старые PHP-приложения, корзины без Redis, любой стейт in-memory. Если такого клиента пустить на другой сервер, он потеряет сессию и вылетит из-под авторизации.
⚪️Weighted Round Robin
То же, что Round Robin, но с весами. Сервер с весом 0,8 получает 80% запросов. Используют при постепенном масштабировании: новый сервер входит с весом 0,1, растёт по мере проверки.
⚪️IP / URL Hash
Клиент по IP-адресу привязывается к конкретному серверу. Пока IP не меняется — пользователь всегда попадает на один бэкенд. Нужен, если сессия хранится in-memory (старые PHP-приложения, некоторые WebSocket-серверы). У URL Hash та же логика, но хэш считается по URL. Полезно для кэширующих серверов: один и тот же URL всегда идёт на один сервер — кэш не дублируется.
⚪️Least Connections
Новый запрос идёт на сервер с наименьшим числом активных соединений. Работает там, где запросы живут по-разному: один занимает 10 мс, другой — 30 секунд. WebSocket-соединения, SSH-туннели — сюда.
⚪️Least Response Time
Трафик направляется туда, где сервер отвечает быстрее прямо сейчас. Балансировщик замеряет latency в реальном времени. Полезно при неравномерной нагрузке: перегретый сервер получает меньше запросов, пока не восстановится.
Для тех, кто хочет изучить тему подробнее, написали статью — рассказали, какие есть виды балансировки нагрузки, каким проектам подходят, как применять.
👈 Читать статью
@DevOpsKaz 😛