weight
Тема дорожной карты · Nginx
Параметр weight в блоке upstream Nginx модифицирует алгоритм балансировки нагрузки round-robin по умолчанию, распределяя трафик пропорционально между бэкенд-серверами с разными мощностями, позволяя операторам направлять больше запросов на мощные серверы и меньше — на слабые. Сервер, настроенный с server backend1 weight=5, получит в пять раз больше запросов, чем сервер, объявленный с server backend2 weight=1, что делает взвешенную балансировку нагрузки идеальной для гетерогенных upstream-окружений, где узлы бэкенда различаются по CPU, памяти или мощности обработки соединений. Взвешенная балансировка нагрузки в Nginx не имеет состояния и пересчитывается для каждого запроса, поэтому она естественно сочетается с другими параметрами upstream — max_fails, fail_timeout и backup — для построения надёжных взвешенных конфигураций переключения при отказе. Когда все серверы в блоке upstream имеют одинаковые веса (значение по умолчанию weight=1), Nginx возвращается к стандартной балансировке round-robin без вычислительных накладных расходов. Настройка значений weight на основе наблюдаемых метрик пропускной способности бэкенда — собранных, например, через nginx-exporter и Prometheus — позволяет операторам непрерывно оптимизировать распределение нагрузки без изменения базовой архитектуры обратного прокси Nginx.
Как это работает
weight распределяет трафик между 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 грубый.
Типичные ошибки
Ловушки weight: ip_hash + клиенты за корпоративным NAT (все на один backend); нет таймаутов — зависший backend никогда не помечен down; round-robin на backend разной capacity (перегружают меньший); вообще нет health check (сбойный backend получает трафик до ручного вмешательства).