Nginx反向代理upstream模块介绍
Nginx反向代理upstream模块内容详解
upstream模块语法
Nginx反向代理upstream模块介绍
Nginx反向代理upstream模块调度算法介绍
轮询（RR）
权重（weight）
ip_hash
最小连接（least_conn）
通用hash
一致性hash
fair（第三方）
url_hash （第三方）
sticky
Nginx的负载均衡功能依赖于 ngx_http_upstream_module，可用于定义由 proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass, 和 grpc_pass 指令引用的服务器组；
| 指令 | 用途说明 |
|---|---|
| proxy_pass | 设置一个代理服务器的协议和地址和一个可选的URI，该URI应该映射到一个位置 |
| fastcgi_pass | 设置FastCGI服务器的地址 |
| uwsgi_pass | 设置uwsgi服务器的协议和地址 |
| scgi_pass | 设置SCGI服务器的地址 |
| memcached_pass | 设置memcached服务器地址 |
| grpc_pass | 设置gRPC服务器地址 |
upstream模块语法
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com:8080 fail_timeout=5s;
server 192.0.2.1 max_fails=3;
server unix:/tmp/backend3;
server backup1.example.com:8080 backup;
server backup2.example.com:8080 backup;
}
server {
location / {
proxy_pass http://backend;
}
}| 参数 | 使用格式 | 参数说明 |
|---|---|---|
| weight | weight=number | 权重，默认值是1 |
| max_conns | max_conns=number | 最大并发活动连接数；默认值为0时，意味着没有限制；如果服务器不驻留在共享内存中，则每个worker进程的限制都是有效的； |
| max_fails | max_fails=number | 最大尝试失败次数，默认值为1； 0 表示禁止失败尝试；被认为失败的尝试是由proxy_next上游、fastcgi_next上游、uwsgi_next上游、scgi_next上游、memcached_next上游和grpc_next上游指令定义的 |
| fail_timeout | fail_timeout=time | 失败超时时间，默认值为10秒 |
| backup | 将服务器标记为备份服务器。当主服务器不可用时，将会传递请求。 | |
| down | 将服务器标记为永久不可用 |
关于商业版参数，这里不阐述说明；其中包括：resolve、route、service、slow_start、drain、least_time，zone等等
Nginx反向代理upstream模块调度算法介绍
轮询（RR）
服务器将每个前端请求按顺序（时间顺序和排列次序）逐一分配到不同的后端服务器节点。如果后端服务器出现问题，即down掉，那么就会被自动剔除。
例如：当前端有多个请求到后端服务器节点，服务会被轮流分配到下面三个服务器。
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}权重（weight）
在基本的轮询策略基础上考虑各后端服务器节点接受请求的权重，指定各后端服务器节点被轮询到的机率，主要应用于后端服务器节点性能不均的情况。
例如：通过直接配置weight来设置访问机率，weight的大小和访问比率成正比。
upstream backend {
server backend1.example.com;
server backend2.example.com weight=2;
server backend3.example.com weight=3; # 权重值越大被分配的几率越大
}
注意：因为weight是内置，所以可以直接和其他策略配合使用。ip_hash
将前端的访问IP进行hash操作，然后根据hash结果将请求分配到不同的后端服务器节点。
客户端IPv4地址的前三个八位字节(或整个IPv6地址)被用作哈希键。
该方法确保来自同一客户端的请求将始终传递到相同的服务器，除非此服务器不可用。
在后一种情况下，客户端请求将被传递到另一个服务器。
最可能的情况是，它始终是同一台服务器【从版本1.3.2和1.2.2开始支持IPv6地址】
例如：因为weight是内置，所以可直接和其他策略配合使用。本策略使用的是ip_hash策略，需要在配置upstream中添加ip_hash一行；
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
server backend4.example.com;
}
注意：
1. 如果暂时删除其中一台服务器，则使用`down`参数进行标记，以保存当前客户端IP地址的哈希。
2. ip_hash模块和后面的Sticky模块不能够同时使用。
3. 在版本1.3.1和1.2.2之前，无法为使用`ip_hash`负载平衡方法的服务器指定权重。最小连接（least_conn）
一个请求被传递给服务器，并使用最少的活动连接，同时考虑到服务器的权重； 如果有几个这样的服务器，则使用加权循环平衡方法进行尝试；
注意：该指令出现在版本1.3.1和1.2.2中
通用hash
指定客户端 - 服务器映射基于哈希key值的服务器组的负载平衡方法。该key可以包含文本，变量，以及它们的组合。
请注意：从组中添加或删除服务器可能导致将大多数密钥重新映射到不同的服务器。
如果consistent指定了参数，则使用一致哈希方法。该方法可确保在向组中添加或删除服务器时，只有少数密钥将重新映射到不同的服务器。这有助于为高速缓存服务器实现更高的高速缓存命中率。该方法 与参数设置为160 的Memcached Perl库兼容 ketama_points。
Specifies a load balancing method for a server group where the client-server mapping is based on the hashed key value. The key can contain text, variables, and their combinations. Note that adding or removing a server from the group may result in remapping most of the keys to different servers. The method is compatible with the Cache::Memcached Perl library.
If the consistent parameter is specified the ketama consistent hashing method will be used instead. The method ensures that only a few keys will be remapped to different servers when a server is added to or removed from the group. This helps to achieve a higher cache hit ratio for caching servers. The method is compatible with the Cache::Memcached::Fast Perl library with the ketama_points parameter set to 160.一致性hash
通用hash和一致性hash也是种扩展策略。通用hash可以以nginx内置的变量为key进行hash，一致性hash采用了nginx内置的一致性hash环，可支持memcache。
upstream backend {
consistent_hash $request_uri;
server backend1.example.com;
server backend2.example.com;
}fair（第三方）
该策略请求转发到负载最小的后端服务器节点上。Nginx通过后端服务器节点对响应时间来判断负载情况，响应时间最短的节点负载就相对较轻，Nginx就会将前端请求转发到此后端服务器节点上。
例如：同样只需要在upstream的所有的server后面添加fair一行即可。
upstream backend {
server backend1.example.com;
server backend2.example.com;
fair;
}
注意：这种策略具有很强的自适应性，但是实际的网络环境往往不是那么简单，因此需要慎用。url_hash （第三方）
该策略将前端请求的url地址进行hash操作，根据hash结果将请求定向到同一后端服务器节点上，后台服务器为缓存是比较有效。一般url_hash需要配合缓冲命中来使用。
upstream backend {
hash $request_uri;
server backend1.example.com;
server backend2.example.com;
}
sticky
该策略在多台服务器的环境下，为了确保一个客户端只和一台服务器通讯，它会保持长连接，并在结束会话后再次选择一个服务器，保证了压力均衡。
例如：同样只需要在upstream的server前添加sticky一行即可，但是代码中还需要进行cookie的
upstream backend {
sticky;
server backend1.example.com;
server backend2.example.com;
}
注意：如果浏览器不支持cookie，那么sticky不生效，毕竟整个模块是给予cookie实现。Sticky模块和ip_hash模块不能够同时使用。