Предисловие

Прокси-функции и функции балансировки нагрузки Nginx используются чаще всего. Базовый синтаксис и конфигурация nginx уже были описаны вПодробная конфигурация Nginx. Эта статья сразу переходит к делу: сначала описываются конфигурации, связанные с прокси, затем подробно объясняется балансировка нагрузки.

Замечания по настройке прокси-сервиса Nginx

1. Задать адрес перенаправления для страницы 404

error_page 404 https://www.runnob.com; #错误页
proxy_intercept_errors on;    #如果被代理服务器返回的状态码为400或者大于400，设置的error_page配置起作用。默认为off.

2. Если наш прокси разрешает только один из методов запроса GET или POST

proxy_method get;    #支持客户端的请求方法。post/get；

3. Задать поддерживаемую версию протокола HTTP

proxy_http_version 1.0 ; #Nginx服务器提供代理服务的http协议版本1.0，1.1，默认设置为1.0版本

4. Если ваш сервер nginx выступает в качестве прокси для двух веб-серверов, использующих алгоритм балансировки нагрузки round-robin, то когда IIS на одной из ваших машин выключен, то есть веб-служба недоступна, сервер nginx всё равно будет распределять запросы к этому недоступному веб-серверу. Если время ответа при соединении слишком велико, страница клиента будет продолжать ждать ответа, что значительно ухудшает пользовательский опыт. Как избежать этой ситуации? Здесь я привёл диаграмму, иллюстрирующую проблему.

Если web2 в конфигурации балансировки нагрузки столкнётся с такой ситуацией, nginx сначала запросит web1, но при неправильной конфигурации nginx продолжит распределять запросы к web2 и будет ждать ответа web2, пока не истечёт время ожидания ответа, затем перераспределит запрос к web1. Если время ответа слишком велико, пользователь будет ждать ещё дольше.

Следующая конфигурация — одно из решений.

proxy_connect_timeout 1;   #nginx服务器与被代理的服务器建立连接的超时时间，默认60秒
proxy_read_timeout 1; #nginx服务器想被代理服务器组发出read请求后，等待响应的超时间，默认为60秒。
proxy_send_timeout 1; #nginx服务器想被代理服务器组发出write请求后，等待响应的超时间，默认为60秒。
proxy_ignore_client_abort on;  #客户端断网时，nginx服务器是否终端对被代理服务器的请求。默认为off.

5. Если вы используете директиву upstream для настройки группы серверов в качестве проксируемых серверов, алгоритм доступа среди серверов следует настроенным правилам балансировки нагрузки. Кроме того, эту директиву можно использовать для настройки того, при каких аномальных условиях запросы следует поочерёдно передавать следующей группе серверов.

proxy_next_upstream timeout;  #反向代理upstream中设置的服务器组，出现故障时，被代理服务器返回的状态值。

Значения статуса могут быть: error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off

  • error: Серверная ошибка возникает при установлении соединения, отправке запроса проксируемому серверу или чтении информации об ответе.
  • timeout: Тайм-аут возникает при установлении соединения, отправке запроса проксируемому серверу или чтении информации об ответе.
  • invalid_header: Заголовок ответа, возвращённый проксируемым сервером, является некорректным.
  • off: Невозможно распределить запросы на проксируемый сервер.
  • http_400, ...: Коды состояния, возвращаемые проксируемым сервером, — это 400, 500, 502 и т. д.

6. Если вы хотите получить реальный IP-адрес клиента по HTTP вместо IP-адреса прокси-сервера, нужно выполнить следующие настройки.

proxy_set_header Host $host; #只要用户在浏览器中访问的域名绑定了 VIP VIP 下面有RS；则就用$host ；host是访问URL中的域名和端口  www.taobao.com:80
proxy_set_header X-Real-IP $remote_addr;  #把源IP 【$remote_addr,建立HTTP连接header里面的信息】赋值给X-Real-IP;这样在代码中 $X-Real-IP来获取 源IP
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;#在nginx 作为代理服务器时，设置的IP列表，会把经过的机器ip，代理机器ip都记录下来，用 【，】隔开；代码中用 echo $x-forwarded-for |awk -F, '{print $1}' 来作为源IP

Со связанными статьями о X-Forwarded-For и X-Real-IP можно ознакомиться здесь:X-Forwarded-For в заголовках HTTP-запросов 。

7. Ниже приведена часть моего файла конфигурации для настройки прокси, только для справки.

include       mime.types;   #文件扩展名与文件类型映射表
default_type  application/octet-stream; #默认文件类型，默认为text/plain
#access_log off; #取消服务日志    
log_format myFormat ' $remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for'; #自定义格式
access_log log/access.log myFormat;  #combined为日志格式的默认值
sendfile on;   #允许sendfile方式传输文件，默认为off，可以在http块，server块，location块。
sendfile_max_chunk 100k;  #每个进程每次调用传输数量不能大于设定的值，默认为0，即不设上限。
keepalive_timeout 65;  #连接超时时间，默认为75s，可以在http，server，location块。
proxy_connect_timeout 1;   #nginx服务器与被代理的服务器建立连接的超时时间，默认60秒
proxy_read_timeout 1; #nginx服务器想被代理服务器组发出read请求后，等待响应的超时间，默认为60秒。
proxy_send_timeout 1; #nginx服务器想被代理服务器组发出write请求后，等待响应的超时间，默认为60秒。
proxy_http_version 1.0 ; #Nginx服务器提供代理服务的http协议版本1.0，1.1，默认设置为1.0版本。
#proxy_method get;    #支持客户端的请求方法。post/get；
proxy_ignore_client_abort on;  #客户端断网时，nginx服务器是否终端对被代理服务器的请求。默认为off.
proxy_ignore_headers "Expires" "Set-Cookie";  #Nginx服务器不处理设置的http相应投中的头域，这里空格隔开可以设置多个。
proxy_intercept_errors on;    #如果被代理服务器返回的状态码为400或者大于400，设置的error_page配置起作用。默认为off.
proxy_headers_hash_max_size 1024; #存放http报文头的哈希表容量上限，默认为512个字符。
proxy_headers_hash_bucket_size 128; #nginx服务器申请存放http报文头的哈希表容量大小。默认为64个字符。
proxy_next_upstream timeout;  #反向代理upstream中设置的服务器组，出现故障时，被代理服务器返回的状态值。error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off
#proxy_ssl_session_reuse on; 默认为on，如果我们在错误日志中发现“SSL3_GET_FINSHED:digest check failed”的情况时，可以将该指令设置为off.

Подробное объяснение балансировки нагрузки Nginx

В статьеПодробная конфигурация Nginxя упоминал алгоритмы балансировки нагрузки, доступные в nginx. В этом разделе я подробно объясню, как их настроить.

Сначала объясню директиву upstream. Эта директива используется для определения группы адресов проксируемых серверов и последующей настройки алгоритма балансировки нагрузки. Адреса проксируемых серверов можно записать двумя способами.

upstream mysvr { 
    server 192.168.10.121:3333;
    server 192.168.10.122:3333;
}
server {
    ....
    location  ~*^.+$ {         
        proxy_pass  http://mysvr;  #请求转向mysvr 定义的服务器列表         
    }
}

Итак, перейдём к практике.

1. Горячий резерв: если у вас есть 2 сервера, второй сервер активируется только тогда, когда первый сервер выходит из строя. Порядок обработки запросов серверами: AAAAAA, затем внезапно A выходит из строя, BBBBBBBBBBBBBB.....

upstream mysvr { 
    server 127.0.0.1:7878; 
    server 192.168.10.121:3333 backup;  #热备     
}

2. Round robin: в nginx по умолчанию используется round-robin, а вес всех серверов по умолчанию равен 1. Порядок обработки запросов серверами: ABABABABAB....

upstream mysvr { 
    server 127.0.0.1:7878;
    server 192.168.10.121:3333;       
}

3. Weighted round robin: запросы распределяются между разными серверами в разных количествах в соответствии с настроенным весом. Если вес не задан, по умолчанию он равен 1. Порядок запросов для серверов ниже: ABBABBABBABBABB....

upstream mysvr { 
    server 127.0.0.1:7878 weight=1;
    server 192.168.10.121:3333 weight=2;
}

4. ip_hash: nginx направляет запросы с одного и того же IP-адреса клиента на один и тот же сервер.

upstream mysvr { 
    server 127.0.0.1:7878; 
    server 192.168.10.121:3333;
    ip_hash;
}

5. Если вы не совсем понимаете 4 вышеперечисленных алгоритма балансировки, можете обратиться кПодробной конфигурации Nginx, так будет, возможно, проще понять.

На этом этапе вам может показаться, что настройка балансировки нагрузки в nginx особенно проста и мощна. Но мы ещё не закончили. Продолжим, и здесь я немного отвлекусь.

Пояснение нескольких параметров состояния в конфигурации балансировки нагрузки nginx.

  • down: означает, что текущий сервер временно не участвует в балансировке нагрузки.

  • backup: Резервная машина. Запросы к ней будут направляться только когда все остальные нерезервные машины выйдут из строя или будут заняты, поэтому нагрузка на эту машину самая низкая.

  • max_fails: Количество допустимых неудачных запросов, по умолчанию равно 1. При превышении максимального числа возвращается ошибка, определённая модулем proxy_next_upstream.

  • fail_timeout: Время приостановки обслуживания после max_fails сбоев. max_fails можно использовать вместе с fail_timeout.

upstream mysvr { 
    server 127.0.0.1:7878 weight=2 max_fails=2 fail_timeout=2;
    server 192.168.10.121:3333 weight=1 max_fails=2 fail_timeout=1;    
}

На этом можно с уверенностью сказать, что все встроенные алгоритмы балансировки нагрузки nginx рассмотрены. Если вы хотите глубже понять алгоритмы балансировки нагрузки nginx, nginx официально предоставляет некоторые плагины, которые вы можете изучить.

URL оригинальной статьи: https://www.cnblogs.com/knowledgesea/p/5199046.html