⚖️ System Design: Балансировщик нагрузки (Load Balancer). Как не уронить сервера?
В прошлом посте мы поняли, что один сервер не справляется, и запустили еще три таких же. Но как пользователи узнают, к какому из них подключаться? Не выдавать же им три разных IP-адреса!
Здесь на сцену выходит Load Balancer (LB) - регулировщик вашего трафика.
LB становится единственной точкой входа. Он принимает на себя все запросы от пользователей и по-умному раскидывает их по вашим серверам. Но как именно он решает, куда отправить следующий запрос? Для этого есть алгоритмы.
🧠 Главные алгоритмы балансировки
1. Round Robin (Карусель)
Самый простой и популярный по умолчанию. Запросы раздаются по кругу: первому серверу, второму, третьему, снова первому.
• Плюсы: Легко настроить, нулевая нагрузка на сам LB.
• Минусы: Слепой алгоритм. Если 1-й сервер завис, генерируя тяжелый отчет, а 2-й свободен, LB всё равно кинет им запросы поровну. 1-й сервер умрет окончательно.
2. Least Connections (Кто свободнее?)
LB работает как умный менеджер: он считает, сколько активных соединений висит на каждом сервере прямо сейчас. Новый запрос летит туда, где меньше всего работы.
• Идеально для: Приложений с долгими соединениями (чаты на WebSockets, потоковая передача видео, скачивание файлов).
3. IP Hash (Липкие сессии / Sticky Sessions)
LB берет IP-адрес пользователя, прогоняет через хэш-функцию и привязывает этот IP к конкретному серверу.
• Зачем нужно: Если ваше (легаси) приложение хранит корзину товаров в оперативной памяти конкретного сервера, вам критически важно, чтобы юзер всегда попадал на один и тот же сервер. Иначе на следующем клике его корзина "опустеет".
• Современный совет: Старайтесь избегать Sticky Sessions. Храните сессии в Redis, чтобы любой сервер мог обработать любой запрос.
4. Weighted алгоритмы (Система весов)
У вас в кластере два сервера: новый 32-ядерный монстр и старенькая 4-ядерная виртуалка. Если включить обычный Round Robin, старый сервер сгорит.
Вы задаете им "веса" (например, 8 и 1). Теперь мощный сервер будет получать 8 запросов на каждый 1 запрос к слабому.
🛠 Суперспособности балансировщиков
LB - это не только про алгоритмы. У него есть еще две критически важные функции:
• 🩺 Health Checks (Проверка пульса): Балансировщик постоянно "пингует" свои сервера (например, запрашивает
• 🔒 SSL Termination: Расшифровка HTTPS-трафика отнимает много ресурсов процессора. Балансировщик может взять эту тяжелую криптографию на себя. Он расшифровывает запрос, а дальше внутри вашей приватной (безопасной) сети общается с серверами по быстрому и легкому HTTP.
#SystemDesign #Backend #LoadBalancer #Architecture #DevOps
👉 @java_geek
В прошлом посте мы поняли, что один сервер не справляется, и запустили еще три таких же. Но как пользователи узнают, к какому из них подключаться? Не выдавать же им три разных IP-адреса!
Здесь на сцену выходит Load Balancer (LB) - регулировщик вашего трафика.
LB становится единственной точкой входа. Он принимает на себя все запросы от пользователей и по-умному раскидывает их по вашим серверам. Но как именно он решает, куда отправить следующий запрос? Для этого есть алгоритмы.
🧠 Главные алгоритмы балансировки
1. Round Robin (Карусель)
Самый простой и популярный по умолчанию. Запросы раздаются по кругу: первому серверу, второму, третьему, снова первому.
• Плюсы: Легко настроить, нулевая нагрузка на сам LB.
• Минусы: Слепой алгоритм. Если 1-й сервер завис, генерируя тяжелый отчет, а 2-й свободен, LB всё равно кинет им запросы поровну. 1-й сервер умрет окончательно.
2. Least Connections (Кто свободнее?)
LB работает как умный менеджер: он считает, сколько активных соединений висит на каждом сервере прямо сейчас. Новый запрос летит туда, где меньше всего работы.
• Идеально для: Приложений с долгими соединениями (чаты на WebSockets, потоковая передача видео, скачивание файлов).
3. IP Hash (Липкие сессии / Sticky Sessions)
LB берет IP-адрес пользователя, прогоняет через хэш-функцию и привязывает этот IP к конкретному серверу.
• Зачем нужно: Если ваше (легаси) приложение хранит корзину товаров в оперативной памяти конкретного сервера, вам критически важно, чтобы юзер всегда попадал на один и тот же сервер. Иначе на следующем клике его корзина "опустеет".
• Современный совет: Старайтесь избегать Sticky Sessions. Храните сессии в Redis, чтобы любой сервер мог обработать любой запрос.
4. Weighted алгоритмы (Система весов)
У вас в кластере два сервера: новый 32-ядерный монстр и старенькая 4-ядерная виртуалка. Если включить обычный Round Robin, старый сервер сгорит.
Вы задаете им "веса" (например, 8 и 1). Теперь мощный сервер будет получать 8 запросов на каждый 1 запрос к слабому.
🛠 Суперспособности балансировщиков
LB - это не только про алгоритмы. У него есть еще две критически важные функции:
• 🩺 Health Checks (Проверка пульса): Балансировщик постоянно "пингует" свои сервера (например, запрашивает
/health). Если сервер не ответил 3 раза подряд, LB помечает его как "мертвый" и перестает слать на него трафик. Пользователи даже не заметят, что один из серверов сгорел.• 🔒 SSL Termination: Расшифровка HTTPS-трафика отнимает много ресурсов процессора. Балансировщик может взять эту тяжелую криптографию на себя. Он расшифровывает запрос, а дальше внутри вашей приватной (безопасной) сети общается с серверами по быстрому и легкому HTTP.
#SystemDesign #Backend #LoadBalancer #Architecture #DevOps
👉 @java_geek
❤3👍2