least_conn
Тема дорожной карты · Nginx
Алгоритм балансировки нагрузки least_conn в Nginx направляет каждый новый запрос к вышестоящему бэкенд-серверу с наименьшим числом активных соединений, что делает его лучшим выбором по сравнению с round-robin для нагрузок, где время обработки запросов существенно варьируется. least_conn активируется добавлением директивы внутри блока upstream: upstream backend { least_conn; server 10.0.0.1; server 10.0.0.2; server 10.0.0.3; } — и прозрачно сочетается с параметрами weight, max_fails и fail_timeout для отдельных серверов. В сценариях обратного прокси, где одни бэкенд-серверы мощнее других, сочетание least_conn с весами серверов — например, server 10.0.0.3 weight=2; — гарантирует, что более мощные узлы пропорционально принимают больше соединений, при этом алгоритм всё равно не перегружает ни один сервер. least_conn особенно эффективен для проксирования WebSocket, эндпоинтов с длинным опросом или любого сценария балансировки нагрузки Nginx, где соединения удерживаются открытыми длительное время, поскольку он естественным образом перераспределяет трафик от насыщенных воркеров. Для большинства продакшен-развёртываний Nginx с неоднородным временем ответа бэкенда least_conn является рекомендуемым методом балансировки нагрузки вместо round-robin по умолчанию.
Как это работает
least_conn распределяет трафик между upstream-backend. Методы: round-robin (дефолт), least_conn (наименьшее число активных соединений), ip_hash (sticky session по client IP), hash $request_uri consistent (consistent hashing для кешей). Помечайте backend как backup (backup) или down (down). Health checks: пассивный (помечает down после N сбоев через max_fails + fail_timeout); активный health check требует nginx-plus или third-party модулей.
Когда применять
least_conn лучше round-robin, когда время запросов варьируется (одни быстрые, другие медленные). ip_hash — только если backend реально нуждается в sticky session (stateless приложения нет). max_fails 3 fail_timeout 30s — для пометки нездоровых backend. Комбинируйте с health-эндпойнтом backend + реальным health check-тулом (Consul, k8s probes); пассивный health check грубый.
Типичные ошибки
Ловушки least_conn: ip_hash + клиенты за корпоративным NAT (все на один backend); нет таймаутов — зависший backend никогда не помечен down; round-robin на backend разной capacity (перегружают меньший); вообще нет health check (сбойный backend получает трафик до ручного вмешательства).