1 nginx负载均衡

负载均衡在服务端开发中算是一个比较重要的特性， nginx 提供的负载均衡可以实现上游服务器的负载均衡、故障转移、失败重试、容错、健康检查，当某些 上游服务器出现问题时，可以将请求转到其它的上游服务器从而保障高可用。

负载均衡

2 nginx负载均衡方法

1.轮询
2.加权轮询
3.hash
4.最少连接数

2.1 轮询

默认轮询方式
每一个来自网络的请求，轮流分配给内部服务器，从1到N然后重新开始。
此种负载均衡算法是和服务器组内部的服务器都具有相同的配置并且平均服务请求相对均衡的情况。

upstream blog{
      server    192.168.35.1:81
      server    192.168.35.2:81
      server    192.168.35.3:81
}
server
{
      listen 80;
      ……
      location ~  / {
            proxy_pass http://blog;
      }
}

2.2 加权轮询

通过weigth参数控制权重
根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。
例如：服务器A的权值被设置为1，B的权值为3，C的权值为6，则服务器A、B、C将分别接收到10%、30%、60%的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。

upstream blog{
      server    192.168.35.1:81 weight=1;
      server    192.168.35.2:81 weight=3;
      server    192.168.35.3:81 weight=6;
}
server
{
      listen 80;
      ……
      location ~  / {
            proxy_pass http://blog;
      }
}

2.3 hash

2.3.1 ip_hash（通过客户端请求ip进行hash，再通过hash值选择后端server）

在upstream中配置ip_hash;
这种方式通过生成请求源IP的哈希值，并通过这个哈希值来找到正确的服务器。这意味着对同一主机来说它对应的服务器总是相同。使用这种方式，你不需要保存任何源IP。将客户端会话“持久化”，以便总是能选择特定服务器，那么可以使用ip_hash负载均衡机制。使用ip_hash时，客户端IP地址作为hash_key使用，用来决策选择服务器集群中哪个服务器来处理这个客户端请求。
例如：当你服务端的一个特定url路径会被同一个用户连续访问时，如果负载均衡策略还是轮询的话，那该用户的多次访问会被打到各台服务器上，这显然并不高效（会建立多次http链接等问题）。所以，此类场景可以考虑采用nginx提供的ip_hash策略。既能满足从同一个客户端发起的请求总是定向到同一台服务器，又能满足不同用户之间负载均衡。

upstream blog{
      ip_hash;
      server    192.168.35.1:81
      server    192.168.35.2:81
      server    192.168.35.3:81
}
server
{
      listen 80;
      ……
      location ~  / {
            proxy_pass http://blog;
      }
}

2.3.2 url_hash（通过请求url进行hash，再通过hash值选择后端server）

在upstream中配置hash;
一般来讲，要用到url_hash，是要配合缓存命中来使用。例如：有一个服务器集群A，需要对外提供文件下载，由于文件上传量巨大，没法存储到服务器磁盘中，所以用到了第三方云存储来做文件存储。服务器集群A收到客户端请求之后，需要从云存储中下载文件然后返回，为了省去不必要的网络带宽和下载耗时，在服务器集群A上做了一层临时缓存（缓存一个月）。由于是服务器集群，所以同一个资源多次请求，可能会到达不同的服务器上，导致不必要的多次下载，缓存命中率不高，以及一些资源时间的浪费。在此类场景下，为了使得缓存命中率提高，很适合使用url_hash策略，同一个url（也就是同一个资源请求）会到达同一台机器，一旦缓存住了资源，再此收到请求，就可以从缓存中读取，既减少了带宽，也减少的下载时间。

upstream blog{
      #也可直接使用$request_uri
      hash $uid;
      server    192.168.35.1:81
      server    192.168.35.2:81
      server    192.168.35.3:81
server
{
      listen 80;
      ……
      #此验证可以在后面传递uid参数来指定服务器，如不使用可以直接在上方指定$request_uri
      if ( $request_uri ~* ^\/.*uid=(\d+).* ) {
          set $uid $1;
      }
      location ~  / {
            proxy_pass http://blog;
      }
}

2.4 最少连接数

在upstream当中配置least_conn实现最少连接数
客户端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间加长，如果采用简单的轮循或随机均衡算法，每一台服务器上的连接进程可能 会产生极大的不同，并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数 量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。

upstream blog{
      least_conn;
      server    192.168.35.1:81
      server    192.168.35.2:81
      server    192.168.35.3:81
}
server
{
      listen 80;
      ……
      location ~  / {
            proxy_pass http://blog;
      }
}

本文参考链接:
https://blog.csdn.net/dengjiexian123/article/details/53105918