[转帖]NGINX官方文档[译]：HTTP负载均衡

nginx,官方,文档,http,负载,均衡 · 浏览次数 : 0

小编点评

**Nginx Plus负载均衡配置** **zone参数** * `zone size`：用于维护 zone 的内存大小。 * `resolver`：用于 DNS 解析记录变化的服务器地址。 **服务器组配置** * `upstream backend`：定义负载均衡组中的服务器组。 * `zone`：在服务器组中定义 zone。 * `least_conn`：用于负载均衡组中的最小连接数。 **负载均衡配置** * `location /`：用于负载均衡所有请求。 * `proxy_pass`：代理到 load balancing 组。 * `proxy_http_version`：设置 HTTP 版本。 * `proxy_set_header`：设置 HTTP 头部。 ** upstream块配置** * `ntml`：启用 NTML 验证。 * `server`：定义服务器组。 ** server组配置** * `upstream exchange`：定义负载均衡组中的服务器组。 * `zone`：在服务器组中定义 zone。 * `least_conn`：用于负载均衡组中的最小连接数。 * `server`：定义服务器。 **完整配置** ```nginx location / { proxy_pass https://exchange; proxy_http_version 1.1; proxy_set_header Connection \"\"; } server { listen 443 ssl; ssl_certificate /etc/nginx/ssl/company.com.crt; ssl_certificate_key /etc/nginx/ssl/company.com.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; location / { proxy_pass https://exchange; proxy_http_version 1.1; proxy_set_header Connection \"\"; } upstream exchange { zone exchange 64k; ntml; server exchange1.example.com; server exchange2.example.com; } server { listen 443 ssl; ssl_certificate /etc/nginx/ssl/company.com.crt; ssl_certificate_key /etc/nginx/ssl/company.com.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; location / { proxy_pass https://exchange; proxy_http_version 1.1; proxy_set_header Connection \"\"; } server { listen 443 ssl; ssl_certificate /etc/nginx/ssl/company.com.crt; ssl_certificate_key /etc/nginx/ssl/company.com.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; location / { proxy_pass https://exchange; proxy_http_version 1.1; proxy_set_header Connection \"\"; } } } } ``` **注意** * `zone size` 和 `resolver` 配置必须根据实际需求进行设置。 * `server` 和 `upstream` 块中可以配置各种其他参数，例如负载均衡算法、连接数等。

正文

负载均衡是一种优化资源利用率、提升最大吞吐量、减少延迟、提高系统容错率的常用技术。

要使用Nginx对一组服务器的HTTP流量进行负载均衡，首先需要使用upstream定义一组后端服务器（配置于http字段中），然后使用server对upstream组中的服务进行配置（同样配置于http字段中，注意与定义虚服务的server字段区分开）。

例如，如下配置定义了一组由3台服务器组成的名为backend的资源组：

  1. http {
  2.     upstream backend {
  3.         server backend1.example.com weight=5;
  4.         server backend2.example.com;
  5.         server 192.168.0.1 backup;
  6.     }
  7. }

接下来可以使用proxy_pass指令（或者fastcgi_pass、memcached_pass、scgi_pass、uwsgi_pass，取决于所使用的协议）将http请求传递给后端服务组backend，配置如下：

  1. http {
  2.     upstream backend {
  3.         server backend1.example.com weight=5;
  4.         server backend2.example.com;
  5.         server 192.168.0.1 backup;
  6.     }
  7.     server {
  8.         location / {
  9.             proxy_pass http://backend;
  10.         }
  11.     }
  12. }

此配置即为一标准的反向代理，用户向nginx发送的http请求将被代理到backend中的三台服务器上，其中192.168.0.1为备用服务器。因为upstream块中未指定负载均衡算法，所以将采用默认算法：轮询调度法。

负载均衡算法的选择

Nginx开源版本支持4种算法，PLUS版又额外新增了两种算法。

1、轮询法

请求按照权重平均分发给各个服务器，这种算法为默认算法，无需额外定义：

  1. upstream backend {
  2.     server backend1.example.com;
  3.     server backend2.example.com;
  4. }

2、最小连接法

请求将被分发到当前活跃连接数最小的服务器，同时将权重考虑在内：

  1. upstream backend {
  2.     least_conn;
  3.     server backend1.example.com;
  4.     server backend2.example.com;
  5. }

3、IP哈希法

根据IP地址来决定将请求分发到哪台服务器。此算法将根据IPv4的前三个8位或者整个IPv6地址计算哈希值，可确保来自同一IP的请求被分发到同一服务器上（除非该服务器不可用），可用于session保持。

  1. upstream backend {
  2.     ip_hash;
  3.     server backend1.example.com;
  4.     server backend2.example.com;
  5. }

如果其中一台服务器需要临时从负载均衡循环中删除，可以使用down参数对其进行标记以保留客户端IP地址的当前哈希值。该服务器的处理的请求将自动切换到组中下一台服务器：

  1. upstream backend {
  2.     server backend1.example.com;
  3.     server backend2.example.com;
  4.     server backend3.example.com down;
  5. }

4、一般哈希法

处理请求的服务器由自定义key决定，该key可以是文本字符串，也可以是变量或者两者的组合，例如成对的IP地址和端口，或者是如下示例中的URI：

  1. upstream backend {
  2.     hash $request_uri consistent;
  3.     server backend1.example.com;
  4.     server backend2.example.com;
  5. }

使用consistent参数将启用ketama一致性负载均衡。根据用户定义的哈希键值，将请求平均分配到所有服务器上。如果在upstream中新增或者删减服务器，则只会有少数键值会被重新映射，从而在负载均衡缓存服务器或其他状态累计应用程序中最大程度地减少缓存未命中。

5、最小延迟算法（仅PLUS版支持）

对于每个请求，Nginx将选择拥有最小平均延迟和最少活跃连接的服务器进行处理。最低平均延迟将根据如下参数进行计算：

  • header——从服务器接收到第一个字节的时间
  • last_byte——从服务器接收到完整响应的时间
  • last_byte inflight——从服务器接收到完整响应的时间，将不完整请求考虑在内
  1. upstream backend {
  2.     least_time header;
  3.     server backend1.example.com;
  4.     server backend2.example.com;
  5. }

6、随机算法（仅NGINX PLUS支持）

每个请求将被随机传递给各个服务器。two参数表示Nginx将在考虑权重的情况下随机先择两台服务器，然后根据two后面指定的算法从两台服务器中选定一台服务器，支持的算法如下：

  • least_conn
  • least_time=header
  • least_time=last_byte

上述三种算法的含义已在上文解释，不再赘述。

  1. upstream backend {
  2.     random two least_time=last_byte;
  3.     server backend1.example.com;
  4.     server backend2.example.com;
  5.     server backend3.example.com;
  6.     server backend4.example.com;
  7. }

该算法适用于多个负载均衡器共用一组后端服务器的分布式环境中。对于负载均衡器拥有全量请求视图的一般情景，请使用其他5种负载均衡算法。

注意：upstream块中指定负载时要放在server之前。

权重的含义

Nginx给每台服务器分配的默认权重为1，即在轮询算法调度下，请求将被平均分配给各个服务器。而在下面的配置中：

  1. upstream backend {
  2.     server backend1.example.com weight=5;
  3.     server backend2.example.com;
  4.     server 192.0.0.1 backup;
  5. }

backend1.example.com的权重被设置为5，这意味着，对于每6个请求，5个将被发送给backend1.example.com，1个将被发送给backend2.example.com。而192.168.0.1因为被指定为backup，将不参与调度，除非backend1.example.com和backend2.example.com均不可用。

慢启动

“慢启动（slow_start）”参数可以给从故障中恢复的节点加入调度队列一个缓冲时间，防止刚恢复的节点因访问超时而再次被标记为故障。此特性适用于Nginx PLUS版。

在Nginx PLUS版中，慢启动可以让upstream中的节点权重在其恢复后逐渐从0恢复到正常权重，此功能通过为server添加slow_start参数实现：

  1. upstream backend {
  2.     server backend1.example.com slow_start=30s;
  3.     server backend2.example.com;
  4.     server 192.168.0.1 backup;
  5. }

参数30s表示backend1.example.com在恢复可用的30秒后，接收的连接数达到正常值。

注意：如果upstream中只有一台服务器，那么max_fails、fail_timeout、slow_start这些参数都会被忽略，即Nginx将这台唯一的服务器视为可用的。

启用会话保持

此功能仅适用于Nginx PLUS。会话保持意味着Nginx可以识别用户会话，并将该会话的所有请求路由到一台指定服务器上。

Nginx PLUS支持3种会话保持方法，可通过sticky参数进行指定。（如果使用的是开源版Nginx，可以使用IP哈希或一般哈希法实现会话保持）

1、sticky cookie

Nginx PLUS为来自upstream组的第一个响应添加一个会话cookie，并标记发送该响应的服务器。携带此cookie值的下一客户端响应将被Nginx PLUS路由到这个被标记的服务器。

  1. upstream backend {
  2.     server backend1.example.com;
  3.     server backend2.example.com;
  4.     sticky cookie srv_id expires=1h domain=.example.com path=/;
  5. }

上例中，srv_id设置了cookie的名称，expires设置cookie了过期时间（即经过多久后浏览器就不再将此cookie发送给服务器），domain设置了cookie的作用域，path设置了cookie的作用路径。sticky cookie是最简单的会话保持方法。

2、sticky route

Nginx PLUS在收到第一个请求时为此客户端分配一个“路由”，所有后续的请求将与server指令的route参数进行比较，来决定将请求代理到哪台服务器。路由信息取自cookie或者请求URI。

  1. upstream backend {
  2.     server backend1.example.com route=a;
  3.     server backend2.example.com route=b;
  4.     sticky route $route_cookie $route_uri;
  5. }

3、sticky learn

Nginx PLUS首先通过分析server的响应来找到会话标识符，然后学习哪个server对应哪个会话标识符。通常，这些标识符通过HTTP cookie进行传递。如果请求包含的会话标识符已经被学习了，那么Nginx就会将请求转发给相应的服务器：

  1. upstream backend {
  2.     server backend1.example.com;
  3.     server backend2.example.com;
  4.     sticky learn
  5.         create=$upstream_cookie_examplecookie
  6.         lookup=$cookie_examplecookie
  7.         zone=client_sessions:1m
  8.         timeout=1h;
  9. }

上例中，upstream的一个节点通过在响应中设置“EXAMPLECOOKIE” cookie创建一个会话，带有此cookie的后续请求将被转发给该节点，如果该节点无法处理请求，则视为客户端尚未进行绑定，Nginx将重新选择一个节点来处理请求。

create参数（不可缺省）定义一个变量来指定如何创建新会话。在上例中，新会话是根据upstream中server发送的“EXAMPLECOOKIE” cookie创建。

lookup参数（不可缺省）定义如何搜索已经存在的会话。在上例中，已经存在的会话是根据客户端发送的“EXAMPLECOOKIE”cookie进行搜索的。

zone参数（不可缺省）定义一块保存所有会话信息的内存区域（在Nginx侧）。在上例中，此内存区域名为client_sessions，大小为1MB（在64位系统中，1MB大约可以存储4000个会话信息）。

timeout参数定义多长时间内未被访问的会话将从zone中删除，该值默认为10分钟。上例中，此时间为1小时。

这种会话保持方法相比前两种更为复杂，它不在客户端侧存储任何cookie，所有的信息都被保存在服务侧的共享内存区域中。

如果集群中有多个Nginx实例使用了sticky learn方法，可以将其共享内存区域的内容进行同步，条件是：

  • 1、zone名称相同
  • 2、每个实例都配置了zone_sync功能
  • 3、sticky learn中指定了sync参数
  1. upstream backend {
  2.     server backend1.example.com;
  3.     server backend2.example.com;
  4.     sticky learn
  5.         create=$upstream_cookie_examplecookie
  6.         lookup=$cookie_examplecookie
  7.         zone=client_sessions:1m
  8.         timeout=1h;
  9.         sync;
  10. }

限制连接数

Nginx PLUS中，可以使用max_conns参数来限制server的连接数量。如果server的连接数量达到了限制值，则请求将被置于队列中以等待进一步处理。

  1. upstream backend {
  2.     server backend1.example.com max_conn=3;
  3.     server backend2.example.com;
  4.     queue 100 timeout=70;
  5. }

如果队列也满了（上例中队列可存放100个请求），或者timeout指定的时间内Nginx仍未能选择到可用的server，那么客户端就会收到报错。

多个worker process共享数据

如果upstream块中未包含zone指令，则每个worker process都会保存自己的服务器组配置副本，并维护自己的一组计数器。计数器包括与upstream组中每个服务器的当前连接数以及请求传递给服务器的失败尝试次数。那么，服务器组的配置将无法动态更新。

如果upstream块中定义了zone，那么服务器组的配置将被保存在多个worker process共享的一个内存区域中。此方案是可动态配置的，因为每个worker process访问的是同一个组配置副本，并且使用的是相同的计数器。

zone参数对于主动健康检查和upstream组的动态配置更新是必须的，而且upstream组的其他功能也可从中受益。

例如，如果一个组的配置不是共享的，每个worker process都维护自己的尝试请求失败计数器（通过max_fails参数设置）。在这种情况下，每个请求仅达到一个worker process，当被选择用来处理此请求的worker process无法将请求给后端的某个服务器时，其他的worker process对此一无所知。这就造成尽管部分worker process认为一个server不可用，其他worker process仍然会向该server发送请求。server确定不可用的条件是在fail_timeout定义的时间内请求失败的次数必须达到max_fails*worker process的数量。如果我们配置了zone，server确定不可用的条件才会变成在fail_timeout定义的时间内请求失败次数达到max_fails，这才是我们想要的效果。

相似的，如果不设置zone，至少在低负载情况下，基于最小连接的负载均衡方法将不按预期工作。此种负载均衡将请求发送给当前活跃连接数最小的服务器，如果组配置不是共享的，每个worker process使用的都是自己的连接数计数器，那个很可能会把请求发送给另一个worker process刚刚发过请求的服务器上。在高负载情况下，请求在work process见均匀分配，最小连接负载均衡法就可以按预期工作。

设置zone的大小

由于使用模式差异巨大，因此不可能推荐一个通用的理想值。所需的内存大小取决于启用了那些功能（例如会话保持、健康检查、DNS重解析）以及upstream的定义方式。

例如，在一个使用了sticky_route会话保持且启用了健康检查的案例中，一个256KB的zone可以维护如下数量的server信息：

  • 128个节点（每个以IP:port形式定义）
  • 或者88个节点（每个以hostname:port形式定义，且每个域名解析到单个IP地址）
  • 或者12个节点（每个以hostname:port形式定义，且每个域名解析到多个IP地址）

使用DNS配置HTTP负载均衡

server组的配置可以使用DNS在运行时进行修改。

对于upstream中使用域名标识的server，Nginx PLUS可以监控DNS解析记录的变化，并自动将变化应用到负载均衡调度组中，而无需重启。实现方式是在http块中引入resolver指令，并在server后面添加resolve参数。

  1. http {
  2.     resolver 10.0.1 valid=300s ipv6=off;
  3.     resolver_timeout 10s;
  4.     server {
  5.         location / {
  6.             proxy_pass http://backend;
  7.         }
  8.     upstream backend {
  9.         zone backend 32k;
  10.         least_conn;
  11.         # ...
  12.         server backend1.example.com resolve;
  13.         server backend2.example.com resolve;
  14.     }
  15. }

上例中，server后的resolve参数指示Nginx PLUS周期性地重解析backend1.example.com和backend2.example.com为IP地址。

resolver指令定义了DNS服务器地址（10.0.0.1），Nginx PLUS默认以TTL（生存时间值）指定的频率重解析DNS记录，我们可以使用valid参数指定TTL值，上例中该值为300s。
ipv6=off表示负载均衡仅使用IPv4地址。Nginx默认是既支持IPv4也支持IPv6的。

如果一个域名被解析为多个IP地址，地址将会被保存到upstream配置中并进行负载均衡。如果IP列表发生了变更，则Nginx PLUS会立即基于新的地址列表进行负载均衡。

Microsoft Exchange Server的负载均衡

在Nginx PLUS R7或更高版本中，Nginx PLUS还可以代理Microsoft Exchange Server的流量，并进行负载均衡。

配置步骤如下：

1、location块中配置proxy_pass，代理到Microsoft Exchange Server服务组：

  1. location / {
  2.     proxy_pass https://exchange;
  3.     # ...
  4. }

2、location块中配置proxy_http_version为1.1，配置proxy_set_header为Connection “”：

  1. location / {
  2.     # ...
  3.     proxy_http_version 1.1;
  4.     proxy_set_header   Connection "";
  5.     # ...
  6. }

3、在upstream块中添加ntml指令，以使组中服务器接受带有NTML验证的请求：

  1. http {
  2.     # ...
  3.     upstream exchange {
  4.     zone exchange 64k;
  5.     ntml;
  6.     # ...
  7.     }
  8. }

4、添加server组：

  1. http {
  2.     #...
  3.     upstream exchange {
  4.     zone exchange 64k;
  5.     ntml;
  6.     server exchange1.example.com;
  7.     server exchange2.example.com;
  8.     # ...
  9.     }
  10. }

完整配置如下：

  1. http {
  2.     # ...
  3.     upstream exchange {
  4.     zone exchange 64k;
  5.     ntml;
  6.     server exchange1.example.com;
  7.     server exchange1.example.com;
  8.     }
  9.     server {
  10.         listen 443 ssl;
  11.         ssl_certificate /etc/nginx/ssl/company.com.crt;
  12.         ssl_certificate_key /etc/nginx/ssl/company.com.key;
  13.         ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  14.      
  15.         location / {
  16.             proxy_pass https://exchange;
  17.             proxy_http_version 1.1;
  18.             proxy_set_header Connection "";
  19.         }
  20.     }
  21. }
文章知识点与官方知识档案匹配，可进一步学习相关知识
网络技能树首页概览23211 人正在系统学习中
nginx 官方 文档 http 负载 均衡

与[转帖]NGINX官方文档[译]：HTTP负载均衡相似的内容：

[转帖]NGINX官方文档[译]：HTTP负载均衡

负载均衡是一种优化资源利用率、提升最大吞吐量、减少延迟、提高系统容错率的常用技术。 要使用Nginx对一组服务器的HTTP流量进行负载均衡，首先需要使用upstream定义一组后端服务器（配置于http字段中），然后使用server对upstream组中的服务进行配置（同样配置于http字段中，注意

nginx 官方 文档 http
0
[转帖]NGINX的一些SEO优化常用配置

https://www.jianshu.com/p/e55073e5ebc7 官方文档：http://nginx.org/en/docs/ 常用模块： ngx_http_core_module ngx_http_rewrite_module ngx_http_proxy_module ngx_htt

nginx 一些 seo 优化
0
[转帖]nginx上传模块—nginx upload module-

https://www.cnblogs.com/lidabo/p/4171515.html 一. nginx upload module原理 官方文档： http://www.grid.net.ru/nginx/upload.en.html Nginx upload module通过nginx服务来

nginx 上传 模块 upload
0
[转帖]【官方文档】Nginx负载均衡学习笔记（三） TCP和UDP负载平衡官方参考文档

本章介绍如何使用NGINX Plus和NGINX开放源代理和负载平衡TCP和UDP流量。 目录 介绍先决条件配置反向代理配置TCP或UDP负载平衡被动健康监控 选择负载平衡方法配置会话持久性 主动健康监控 怎么运行的先决条件基本配置微调健康检查使用匹配配置块进行微调健康检查 TCP的微调健康检查UD

官方 文档 nginx 负载
0
[转帖]nginx(三十二)rewrite模块

一 官方rewrite模块 ① 模块涉及的指令 ② 基本简介 rewrite模块会根据'PCRE正则'匹配'重写URI' pcre下载地址 pcretest测试正则表达式 ③ break 疑惑点： 结束'该作用域'下剩余的指令,还是'只是该rewrite模块的'指令? 1）配置demo 2）不带参数

nginx 三十二 rewrite 模块
0
[转帖]Nginx 40 问~~~

https://zhuanlan.zhihu.com/p/485159477 Nginx是一个 轻量级/高性能的反向代理Web服务器，用于 HTTP、HTTPS、SMTP、POP3 和 IMAP 协议。他实现非常高效的反向代理、负载平衡，他可以处理2-3万并发连接数，官方监测能支持5万并发，现在中国

nginx
0
[转帖]如何在 NGINX 中安全地分发 SSL 私钥

https://my.oschina.net/u/5246775/blog/7812621 原文作者：Owen Garrett of F5 原文链接：如何在 NGINX 中安全地分发 SSL 私钥 转载来源：NGINX 官方网站 NGINX 唯一中文官方社区 ，尽在 nginx.org.cn 本文介

如何 nginx 安全 分发
0
[转帖]nginx的Mainline version、Stable version、Legacy version的版本区别

https://blog.csdn.net/zwjzwj520520/article/details/62883317 Nginx官网提供了三个类型的版本Mainline version：Mainline 是 Nginx 目前主力在做的版本，可以说是开发版Stable version：最新稳定版，生

nginx mainline version stable
0
[转帖]nginx版本区别

https://www.easck.com/cos/2020/0801/567085.shtml 生产环境使用Stable version：最新稳定版。 注意各版本的区别：Nginx官网提供了三个类型的版本 1、Mainline version：Mainline 是 Nginx 目前主力在做的版本，

nginx 版本 区别
0
[转帖]Nginx(四)负载均衡

一 nginx目录的说明 1 nginx/ 3 |-- client_body_temp 4 |-- conf #这是Nginx所有配置文件的目录，极其重要 5 | |-- fastcgi.conf 'fastcgi相关参数的配置文件' 6 | |-- fastcgi.conf.default #f

nginx 负载 均衡
0
# 热门排行
微软 New Bing AI 申请与使用保姆级教程（免魔法） ChatGPT API使用介绍 ChatGPT开发实战 一篇带你了解如何使用纯前端类Excel表格构建现金流量表 手把手教你玩转 Excel 数据透视表 为什么 C# 可能是最好的第一编程语言 .NET 入门到高级路线 提高工作效率的神器：基于前端表格实现Chrome Excel扩展插件 React + Springboot + Quartz，从0实现Excel报表自动化 用Echarts实现前端表格引用从属关系可视化
© PmDaddy. 2023 PmDaddy教程网 All rights reserved.