1、Nginx 负载均衡策略

1.1、轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器 down 掉，能自动剔除。

upstream backend {
   # no load balancing method is specified for Round Robin
   server backend1.example.com;
   server backend2.example.com;
}

1.2、指定权重

指定轮询几率，weight 和访问比率成正比，用于后端服务器性能不均的情况。

upstream backserver {
	server 192.168.0.14 weight=10;
	server 192.168.0.15 weight=10;
}

1.3、IP 绑定 ip_hash

每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决 session 的问题。

upstream backserver {
	ip_hash;
	server 192.168.0.14:88;
	server 192.168.0.15:80;
}

1.4、最少连接

将活动连接最少的请求发送到服务器，再次考虑服务器权重：

upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

1.5、一致性hash

指令的可选consistent参数hash启用ketama一致性哈希负载平衡。根据用户定义的哈希键值，请求在所有上游服务器上平均分配。如果将上游服务器添加到上游组或从上游组中删除，则只有少数几个键会被重新映射，从而在负载平衡缓存服务器或其他累积状态的应用程序的情况下最大程度地减少缓存未命中的情况。

upstream backend {
    hash $request_uri consistent;
    server backend1.example.com;
    server backend2.example.com;
}

1.6、最短时间（仅NGINX Plus）

对于每个请求，NGINX Plus选择具有最低平均延迟和最低活动连接数的服务器，其中最低平均延迟是根据包含在指令中以下参数中的哪一个来计算的least_time：

• header –从服务器接收第一个字节的时间
• last_byte –是时候收到来自服务器的完整响应了
• last_byte inflight –考虑到请求不完整的时间，可以从服务器接收完整的响应

upstream backend {
    least_time header;
    server backend1.example.com;
    server backend2.example.com;
}

1.7、随机

每个请求将传递到随机选择的服务器。如果two指定了参数，首先，NGINX考虑服务器权重随机选择两个服务器，然后使用指定的方法选择这些服务器之一：

• least_conn –活动连接数最少
• least_time=header（NGINX Plus）–从服务器接收响应标头的最短平均时间（$upstream_header_time）
• least_time=last_byte（NGINX Plus）–从服务器接收完整响应的最短平均时间（$upstream_response_time）

upstream backend {
    random two least_time=last_byte;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
    server backend4.example.com;
}

1.8、服务器慢启动

服务器缓慢启动功能可防止连接恢复，使最近恢复的服务器不堪重负，因为连接可能会超时并导致服务器再次标记为故障。

在NGINX Plus中，慢速启动允许上游服务器0在恢复或可用后逐渐将其重量从其名义值恢复到正常值。这可以通过伪指令的slow_start参数来完成server：

upstream backend {
    server backend1.example.com slow_start=30s;
    server backend2.example.com;
    server 192.0.0.1 backup;
}

时间值（此处为30 秒）设置了NGINX Plus将与服务器的连接数增加到最大值的时间。

请注意，如果只有一个单一的服务器组，中max_fails，fail_timeout和slow_start参数的server指令被忽略，服务器永远不会认为不可用。

1.9、启用会话持久性

会话持久性意味着NGINX Plus可以识别用户会话并将给定会话中的所有请求路由到同一上游服务器。

NGINX Plus支持三种会话持久性方法。方法是通过sticky伪指令设置的。（对于NGINX开源的会话持久性，请使用hash或ip_hash指令，如上所述）。

粘性cookie – NGINX Plus将会话cookie添加到上游组的第一个响应中，并标识发送响应的服务器。客户端的下一个请求包含cookie值，NGINX Plus将请求路由到响应第一个请求的上游服务器：

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

在示例中，srv_id参数设置cookie的名称。可选expires参数设置浏览器保留cookie的时间（此处为1 小时）。可选domain参数定义设置cookie的域，可选path参数定义设置cookie的路径。这是最简单的会话持久性方法。

粘性路由– NGINX Plus在收到第一个请求时为客户端分配一个“路由”。将所有后续请求与伪指令的route参数进行比较，server以标识将请求代理到的服务器。路由信息来自Cookie或请求URI。

upstream backend {
    server backend1.example.com route=a;
    server backend2.example.com route=b;
    sticky route $route_cookie $route_uri;
}

粘性学习方法– NGINX Plus首先通过检查请求和响应来找到会话标识符。然后，NGINX Plus“学习”哪个上游服务器对应于哪个会话标识符。通常，这些标识符在HTTP cookie中传递。如果一个请求包含一个已经“学习”的会话标识符，则NGINX Plus将请求转发到相应的服务器：

upstream backend {
   server backend1.example.com;
   server backend2.example.com;
   sticky learn
       create=$upstream_cookie_examplecookie
       lookup=$cookie_examplecookie
       zone=client_sessions:1m
       timeout=1h;
}

在该示例中，上游服务器之一通过EXAMPLECOOKIE在响应中设置cookie来创建会话。

必需create参数指定一个变量，该变量指示如何创建新会话。在该示例中，新会话是EXAMPLECOOKIE根据上游服务器发送的cookie创建的。

必填lookup参数指定如何搜索现有会话。在我们的示例中，现有会话EXAMPLECOOKIE在客户端发送的cookie中进行搜索。

必选zone参数指定一个共享内存区域，其中保留了有关粘性会话的所有信息。在我们的示例中，该区域名为client_sessions1 ，大小为MB。

与前两种方法相比，这是一种更复杂的会话持久性方法，因为它不需要在客户端保留任何cookie：所有信息都在共享存储区的服务器端保留。

如果集群中有多个使用“粘性学习”方法的NGINX实例，则可以在以下条件下同步其共享内存区域的内容：

区域具有相同的名称
该zone_sync功能在每个实例上配置
在sync被指定的参数

   sticky learn
       create=$upstream_cookie_examplecookie
       lookup=$cookie_examplecookie
       zone=client_sessions:1m
       timeout=1h
       sync;
}

1.10、限制连接数

使用NGINX Plus，可以通过使用max_conns参数指定最大数量来限制到上游服务器的连接数量。

如果max_conns已达到限制，则将请求放置在队列中以进行进一步处理，前提queue是还包含该指令以设置可以同时在队列中请求的最大数量：

upstream backend {
    server backend1.example.com max_conns=3;
    server backend2.example.com;
    queue 100 timeout=70;
}

如果队列中充满了请求，或者在可选timeout参数指定的超时期间无法选择上游服务器，则客户端会收到错误消息。

请注意，max_conns如果在其他工作进程中打开了空闲的keepalive连接，则忽略该限制。结果，与服务器的连接总数可能会超过与多个工作进程共享内存的配置中的值。max_conns

我是小白弟弟，一个在互联网行业的小白，立志成为一名架构师
https://blog.csdn.net/zhouhengzhe?t=1