Mercurial > hg > nginx-site
view xml/ru/docs/http/ngx_http_upstream_module.xml @ 3084:0bbf14c9fd66
Documented $upstream_cache_key.
author | Maxim Dounin <mdounin@mdounin.ru> |
---|---|
date | Fri, 24 May 2024 03:49:10 +0300 |
parents | 9eadb98ec770 |
children | ca4c8ac67c0e |
line wrap: on
line source
<?xml version="1.0"?> <!-- Copyright (C) Igor Sysoev Copyright (C) Nginx, Inc. --> <!DOCTYPE module SYSTEM "../../../../dtd/module.dtd"> <module name="Модуль ngx_http_upstream_module" link="/ru/docs/http/ngx_http_upstream_module.html" lang="ru" rev="90"> <section id="summary"> <para> Модуль <literal>ngx_http_upstream_module</literal> позволяет описывать группы серверов, которые могут использоваться в директивах <link doc="ngx_http_proxy_module.xml" id="proxy_pass"/>, <link doc="ngx_http_fastcgi_module.xml" id="fastcgi_pass"/>, <link doc="ngx_http_uwsgi_module.xml" id="uwsgi_pass"/>, <link doc="ngx_http_scgi_module.xml" id="scgi_pass"/>, <link doc="ngx_http_memcached_module.xml" id="memcached_pass"/> и <link doc="ngx_http_grpc_module.xml" id="grpc_pass"/>. </para> </section> <section id="example" name="Пример конфигурации"> <para> <example> upstream <emphasis>backend</emphasis> { server backend1.example.com weight=5; server backend2.example.com:8080; server unix:/tmp/backend3; server backup1.example.com:8080 backup; server backup2.example.com:8080 backup; } server { location / { proxy_pass http://<emphasis>backend</emphasis>; } } </example> </para> </section> <section id="directives" name="Директивы"> <directive name="upstream"> <syntax block="yes"><value>название</value></syntax> <default/> <context>http</context> <para> Описывает группу серверов. Серверы могут слушать на разных портах. Кроме того, можно одновременно использовать серверы, слушающие на TCP- и UNIX-сокетах. </para> <para> Пример: <example> upstream backend { server backend1.example.com weight=5; server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; server unix:/tmp/backend3; server backup1.example.com backup; } </example> </para> <para> По умолчанию запросы распределяются по серверам циклически (в режиме round-robin) с учётом весов серверов. В вышеприведённом примере каждые 7 запросов будут распределены так: 5 запросов на <literal>backend1.example.com</literal> и по одному запросу на второй и третий серверы. Если при попытке работы с сервером происходит ошибка, то запрос передаётся следующему серверу, и так далее до тех пор, пока не будут опробованы все работающие серверы. Если не удастся получить успешный ответ ни от одного из серверов, то клиенту будет возвращён результат работы с последним сервером. </para> </directive> <directive name="server"> <syntax><value>адрес</value> [<value>параметры</value>]</syntax> <default/> <context>upstream</context> <para> Задаёт <value>адрес</value> и другие <value>параметры</value> сервера. Адрес может быть указан в виде доменного имени или IP-адреса, и необязательного порта, или в виде пути UNIX-сокета, который указывается после префикса “<literal>unix:</literal>”. Если порт не указан, используется порт 80. Доменное имя, которому соответствует несколько IP-адресов, задаёт сразу несколько серверов. </para> <para> Могут быть заданы следующие параметры: <list type="tag"> <tag-name id="weight"> <literal>weight</literal>=<value>число</value> </tag-name> <tag-desc> задаёт вес сервера, по умолчанию 1. </tag-desc> <tag-name id="max_conns"> <literal>max_conns</literal>=<value>число</value> </tag-name> <tag-desc> ограничивает максимальное <value>число</value> одновременных активных соединений к проксируемому серверу (1.11.5). Значение по умолчанию равно 0 и означает, что ограничения нет. Если группа не находится в <link id="zone">зоне разделяемой памяти</link>, то ограничение работает отдельно для каждого рабочего процесса. <note> При включённых <link id="keepalive">неактивных постоянных</link> соединениях, нескольких <link doc="../ngx_core_module.xml" id="worker_processes">рабочих процессах</link> и <link id="zone">зоне разделяемой памяти</link>, суммарное число активных и неактивных соединений с проксируемым сервером может превышать значение <literal>max_conns</literal>. </note> </tag-desc> <tag-name id="max_fails"> <literal>max_fails</literal>=<value>число</value> </tag-name> <tag-desc> задаёт число неудачных попыток работы с сервером, которые должны произойти в течение времени, заданного параметром <literal>fail_timeout</literal>, чтобы сервер считался недоступным на период времени, также заданный параметром <literal>fail_timeout</literal>. По умолчанию число попыток устанавливается равным 1. Нулевое значение отключает учёт попыток. Что считается неудачной попыткой, определяется директивами <link doc="ngx_http_proxy_module.xml" id="proxy_next_upstream"/>, <link doc="ngx_http_fastcgi_module.xml" id="fastcgi_next_upstream"/>, <link doc="ngx_http_uwsgi_module.xml" id="uwsgi_next_upstream"/>, <link doc="ngx_http_scgi_module.xml" id="scgi_next_upstream"/>, <link doc="ngx_http_memcached_module.xml" id="memcached_next_upstream"/> и <link doc="ngx_http_grpc_module.xml" id="grpc_next_upstream"/>. </tag-desc> <tag-name id="fail_timeout"> <literal>fail_timeout</literal>=<value>время</value> </tag-name> <tag-desc> задаёт <list type="bullet"> <listitem> время, в течение которого должно произойти заданное число неудачных попыток работы с сервером для того, чтобы сервер считался недоступным; </listitem> <listitem> и время, в течение которого сервер будет считаться недоступным. </listitem> </list> По умолчанию параметр равен 10 секундам. </tag-desc> <tag-name id="backup"> <literal>backup</literal> </tag-name> <tag-desc> помечает сервер как запасной сервер. На него будут передаваться запросы в случае, если не работают основные серверы. <note> Параметр нельзя использовать совместно с методами балансировки нагрузки <link id="hash"/>, <link id="ip_hash"/> и <link id="random"/>. </note> </tag-desc> <tag-name id="down"> <literal>down</literal> </tag-name> <tag-desc> помечает сервер как постоянно недоступный. </tag-desc> </list> </para> <para> <note> Если в группе только один сервер, параметры <literal>max_fails</literal> и <literal>fail_timeout</literal> игнорируются и такой сервер никогда не будет считаться недоступным. </note> </para> </directive> <directive name="zone"> <syntax><value>имя</value> [<value>размер</value>]</syntax> <default/> <context>upstream</context> <appeared-in>1.9.0</appeared-in> <para> Задаёт <value>имя</value> и <value>размер</value> зоны разделяемой памяти, в которой хранятся конфигурация группы и её рабочее состояние, разделяемые между рабочими процессами. В одной и той же зоне могут быть сразу несколько групп. В этом случае достаточно указать <value>размер</value> только один раз. </para> </directive> <directive name="hash"> <syntax><value>ключ</value> [<literal>consistent</literal>]</syntax> <default/> <context>upstream</context> <appeared-in>1.7.2</appeared-in> <para> Задаёт метод балансировки нагрузки для группы, при котором соответствие клиента серверу определяется при помощи хэшированного значения <value>ключа</value>. В качестве <value>ключа</value> может использоваться текст, переменные и их комбинации. Следует отметить, что любое добавление или удаление серверов в группе может привести к перераспределению большинства ключей на другие серверы. Метод совместим с библиотекой Perl <link url="https://metacpan.org/pod/Cache::Memcached">Cache::Memcached</link>. </para> <para> Если задан параметр <literal>consistent</literal>, то вместо вышеописанного метода будет использоваться метод консистентного хэширования <link url="https://www.metabrew.com/article/libketama-consistent-hashing-algo-memcached-clients">ketama</link>. Метод гарантирует, что при добавлении сервера в группу или его удалении на другие серверы будет перераспределено минимальное число ключей. Применение метода для кэширующих серверов обеспечивает больший процент попаданий в кэш. Метод совместим с библиотекой Perl <link url="https://metacpan.org/pod/Cache::Memcached::Fast">Cache::Memcached::Fast</link> при значении параметра <value>ketama_points</value> равным 160. </para> </directive> <directive name="ip_hash"> <syntax/> <default/> <context>upstream</context> <para> Задаёт для группы метод балансировки нагрузки, при котором запросы распределяются по серверам на основе IP-адресов клиентов. В качестве ключа для хэширования используются первые три октета IPv4-адреса клиента или IPv6-адрес клиента целиком. Метод гарантирует, что запросы одного и того же клиента будут всегда передаваться на один и тот же сервер. Если же этот сервер будет считаться недоступным, то запросы этого клиента будут передаваться на другой сервер. С большой долей вероятности это также будет один и тот же сервер. <note> IPv6-адреса поддерживаются начиная с версий 1.3.2 и 1.2.2. </note> </para> <para> Если один из серверов нужно убрать на некоторое время, то для сохранения текущего хэширования IP-адресов клиентов этот сервер нужно пометить параметром <literal>down</literal>. </para> <para> Пример: <example> upstream backend { ip_hash; server backend1.example.com; server backend2.example.com; server backend3.example.com <emphasis>down</emphasis>; server backend4.example.com; } </example> </para> <para> <note> До версий 1.3.1 и 1.2.2 для серверов, использующих метод балансировки нагрузки <literal>ip_hash</literal>, нельзя было задать вес. </note> </para> </directive> <directive name="keepalive"> <syntax><value>соединения</value></syntax> <default/> <context>upstream</context> <appeared-in>1.1.4</appeared-in> <para> Задействует кэш соединений для группы серверов. </para> <para> Параметр <value>соединения</value> устанавливает максимальное число неактивных постоянных соединений с серверами группы, которые будут сохраняться в кэше каждого рабочего процесса. При превышении этого числа наиболее давно не используемые соединения закрываются. <note> Следует особо отметить, что директива <literal>keepalive</literal> не ограничивает общее число соединений с серверами группы, которые рабочие процессы nginx могут открыть. Параметр <value>соединения</value> следует устанавливать достаточно консервативно, чтобы серверы группы по-прежнему могли обрабатывать новые входящие соединения. </note> <note> При использовании методов балансировки нагрузки, отличных от стандартного round-robin, следует активировать их до директивы <literal>keepalive</literal>. </note> </para> <para> Пример конфигурации группы серверов memcached с постоянными соединениями: <example> upstream memcached_backend { server 127.0.0.1:11211; server 10.0.0.2:11211; keepalive 32; } server { ... location /memcached/ { set $memcached_key $uri; memcached_pass memcached_backend; } } </example> </para> <para> Для HTTP директиву <link doc="ngx_http_proxy_module.xml" id="proxy_http_version"/> следует установить в “<literal>1.1</literal>”, а поле заголовка <header>Connection</header> — очистить: <example> upstream http_backend { server 127.0.0.1:8080; keepalive 16; } server { ... location /http/ { proxy_pass http://http_backend; proxy_http_version 1.1; proxy_set_header Connection ""; ... } } </example> </para> <para> <note> Хоть это и не рекомендуется, но также возможно использование постоянных соединений с HTTP/1.0, путём передачи поля заголовка <header>Connection: Keep-Alive</header> серверу группы. </note> </para> <para> Для работы постоянных соединений с FastCGI-серверами потребуется включить директиву <link doc="ngx_http_fastcgi_module.xml" id="fastcgi_keep_conn"/>: <example> upstream fastcgi_backend { server 127.0.0.1:9000; keepalive 8; } server { ... location /fastcgi/ { fastcgi_pass fastcgi_backend; fastcgi_keep_conn on; ... } } </example> </para> <para> <note> Протоколы SCGI и uwsgi не определяют семантику постоянных соединений. </note> </para> </directive> <directive name="keepalive_requests"> <syntax><value>число</value></syntax> <default>1000</default> <context>upstream</context> <appeared-in>1.15.3</appeared-in> <para> Задаёт максимальное число запросов, которые можно сделать по одному постоянному соединению. После того как сделано максимальное число запросов, соединение закрывается. </para> <para> Периодическое закрытие соединений необходимо для освобождения памяти, выделенной под конкретные соединения. Поэтому использование слишком большого максимального числа запросов может приводить к чрезмерному потреблению памяти и не рекомендуется. </para> <para> <note> До версии 1.19.10 по умолчанию использовалось значение 100. </note> </para> </directive> <directive name="keepalive_time"> <syntax><value>время</value></syntax> <default>1h</default> <context>upstream</context> <appeared-in>1.19.10</appeared-in> <para> Ограничивает максимальное время, в течение которого могут обрабатываться запросы в рамках постоянного соединения. По достижении заданного времени соединение закрывается после обработки очередного запроса. </para> </directive> <directive name="keepalive_timeout"> <syntax><value>таймаут</value></syntax> <default>60s</default> <context>upstream</context> <appeared-in>1.15.3</appeared-in> <para> Задаёт таймаут, в течение которого неактивное постоянное соединение с сервером группы не будет закрыто. </para> </directive> <directive name="least_conn"> <syntax/> <default/> <context>upstream</context> <appeared-in>1.3.1</appeared-in> <appeared-in>1.2.2</appeared-in> <para> Задаёт для группы метод балансировки нагрузки, при котором запрос передаётся серверу с наименьшим числом активных соединений, с учётом весов серверов. Если подходит сразу несколько серверов, они выбираются циклически (в режиме round-robin) с учётом их весов. </para> </directive> <directive name="random"> <syntax>[<literal>two</literal> [<value>метод</value>]]</syntax> <default/> <context>upstream</context> <appeared-in>1.15.1</appeared-in> <para> Задаёт для группы метод балансировки нагрузки, при котором запрос передаётся случайно выбранному серверу, с учётом весов серверов. </para> <para> Если указан необязательный параметр <literal>two</literal>, то nginx случайным образом выбирает <link url="https://homes.cs.washington.edu/~karlin/papers/balls.pdf">два</link> сервера, из которых выбирает сервер, используя указанный <literal>метод</literal>. Методом по умолчанию является <literal>least_conn</literal>, при котором запрос передаётся на сервер с наименьшим количеством активных соединений. </para> </directive> </section> <section id="variables" name="Встроенные переменные"> <para> Модуль <literal>ngx_http_upstream_module</literal> поддерживает следующие встроенные переменные: <list type="tag"> <tag-name id="var_upstream_addr"><var>$upstream_addr</var></tag-name> <tag-desc> хранит IP-адрес и порт или путь к UNIX-сокету сервера группы. Если при обработке запроса были сделаны обращения к нескольким серверам, то их адреса разделяются запятой, например, “<literal>192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock</literal>”. Если произошло внутреннее перенаправление от одной группы серверов на другую с помощью <header>X-Accel-Redirect</header> или <link doc="ngx_http_core_module.xml" id="error_page"/>, то адреса, соответствующие разным группам серверов, разделяются двоеточием, например, “<literal>192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80</literal>”. Если сервер не может быть выбран, то переменная хранит имя группы серверов. </tag-desc> <tag-name id="var_upstream_bytes_received"><var>$upstream_bytes_received</var></tag-name> <tag-desc> число байт, полученных от сервера группы (1.11.4). Значения нескольких соединений разделяются запятыми и двоеточиями подобно адресам в переменной <link id="var_upstream_addr">$upstream_addr</link>. </tag-desc> <tag-name id="var_upstream_bytes_sent"><var>$upstream_bytes_sent</var></tag-name> <tag-desc> число байт, переданных на сервер группы (1.15.8). Значения нескольких соединений разделяются запятыми и двоеточиями подобно адресам в переменной <link id="var_upstream_addr">$upstream_addr</link>. </tag-desc> <tag-name id="var_upstream_cache_key"><var>$upstream_cache_key</var> </tag-name> <tag-desc> используемый ключ кэширования (1.27.1). </tag-desc> <tag-name id="var_upstream_cache_status"><var>$upstream_cache_status</var> </tag-name> <tag-desc> хранит статус доступа к кэшу ответов (0.8.3). Статус может быть одним из “<literal>MISS</literal>”, “<literal>BYPASS</literal>”, “<literal>EXPIRED</literal>”, “<literal>STALE</literal>”, “<literal>UPDATING</literal>”, “<literal>REVALIDATED</literal>” или “<literal>HIT</literal>”. </tag-desc> <tag-name id="var_upstream_connect_time"><var>$upstream_connect_time</var> </tag-name> <tag-desc> хранит время, затраченное на установление соединения с сервером группы (1.9.1); время хранится в секундах с точностью до миллисекунд. В случае SSL, включает в себя время, потраченное на handshake. Времена нескольких соединений разделяются запятыми и двоеточиями подобно адресам в переменной <link id="var_upstream_addr">$upstream_addr</link>. </tag-desc> <tag-name id="var_upstream_cookie_"><var>$upstream_cookie_</var><value>имя</value> </tag-name> <tag-desc> кука с указанным <value>именем</value>, переданная сервером группы в поле <header>Set-Cookie</header> заголовка ответа (1.7.1). Необходимо иметь в виду, что куки запоминаются только из ответа последнего сервера. </tag-desc> <tag-name id="var_upstream_header_time"><var>$upstream_header_time</var> </tag-name> <tag-desc> хранит время, затраченное на получение заголовка ответа от сервера группы (1.7.10); время хранится в секундах с точностью до миллисекунд. Времена нескольких ответов разделяются запятыми и двоеточиями подобно адресам в переменной <link id="var_upstream_addr">$upstream_addr</link>. </tag-desc> <tag-name id="var_upstream_http_"><var>$upstream_http_</var><value>имя</value></tag-name> <tag-desc> хранят поля заголовка ответа сервера. Например, поле заголовка ответа <header>Server</header> доступно в переменной <var>$upstream_http_server</var>. Правила преобразования имён полей заголовка ответа в имена переменных такие же, как для переменных с префиксом “<link doc="ngx_http_core_module.xml" id="var_http_">$http_</link>”. Необходимо иметь в виду, что поля заголовка запоминаются только из ответа последнего сервера. </tag-desc> <tag-name id="var_upstream_queue_time"><var>$upstream_queue_time</var></tag-name> <tag-desc> хранит время, проведённое запросом в <link id="queue">очереди</link> (1.13.9); время хранится в секундах с точностью до миллисекунд. Времена нескольких ответов разделяются запятыми и двоеточиями подобно адресам в переменной <link id="var_upstream_addr">$upstream_addr</link>. </tag-desc> <tag-name id="var_upstream_response_length"><var>$upstream_response_length</var> </tag-name> <tag-desc> хранит длину ответа, полученного от сервера группы (0.7.27); длина хранится в байтах. Длины нескольких ответов разделяются запятыми и двоеточиями подобно адресам в переменной <link id="var_upstream_addr">$upstream_addr</link>. </tag-desc> <tag-name id="var_upstream_response_time"><var>$upstream_response_time</var> </tag-name> <tag-desc> хранит время, затраченное на получение ответа от сервера группы; время хранится в секундах с точностью до миллисекунд. Времена нескольких ответов разделяются запятыми и двоеточиями подобно адресам в переменной <link id="var_upstream_addr">$upstream_addr</link>. </tag-desc> <tag-name id="var_upstream_status"><var>$upstream_status</var></tag-name> <tag-desc> хранит статус ответа, полученного от сервера группы. Статусы нескольких ответов разделяются запятыми и двоеточиями подобно адресам в переменной <link id="var_upstream_addr">$upstream_addr</link>. Если сервер не может быть выбран, то переменная хранит статус <http-status code="502" text="Bad Gateway"/>. </tag-desc> <tag-name id="var_upstream_trailer_"><var>$upstream_trailer_</var><value>имя</value></tag-name> <tag-desc> хранит поля из конца ответа, полученного от сервера группы (1.13.10). </tag-desc> </list> </para> </section> </module>