upstream模块调度算法

内容概述:
       静态调度算法：
       1.rr轮询(默认调度算法)       顺序分配逐一请求
       2.wrr权重轮询算法           权重大转发次数多
       3.ip_hash                 相同ip固定转发
       动态调度算法:
       1.fair调度算法              响应时间短的优先分配
       2.least_conn               连接请求少的优先分配
       3.一致HASH 和url_hash       后台为缓存服务器时效果好

调度算法一般分为两类,第一类为静态调度算法,即负载均衡器根据自身设定的规则进行分配,不需要考虑后端节点服务器的情况,例如: rr wrr ip_hash等都属于静态调度算法。

第二类为动态调度算法,即负载均衡器会根据后端节点的当前状态来决定是否分发请求,例如:连接数少的优先获得请求,响应时间短的优先获得请求。例如:least_conn,fair等都属于动态调度算法。
下面介绍一下常见的调度算法

1. rr轮询(默认调度算法,静态调度算法)

按客户端请求顺序把客户端的请求逐一分配到不同的后端节点服务器.这相当于LVS中的rr算法,如果后端节点服务器宕机(默认情况下nginx只检查80端口),宕机的服务器会别自动从节点服务器池中剔除,以使客户端的用户访问不受影响。新的请求会分配给正常的服务器。

2. wrr(权重轮询,静态调度算法)

在rr轮询算法的基础上加上权重，即为权重轮询算法,当使用该算法时,权重和用户访问成正比,权重值越大,被转发的请求也越多。可以根据服务器的配置和性能指定权重值大小,有效解决新旧服务器性能不均带来的请求分配问题。
举个例子帮助大家加深理解。
后端服务器 192.168.1.2 的配置为: E5520*2 CPU， 8GB内存
后端服务器 192.168.1.3 的配置为: Xeon™2.80GHz * 2, 4GB内存
假设希望在有30个请求到达前端时,其中20个请求交给 192.168.1.3处理,剩余10个请求交给 192.168.1.2处理, 就可做如下配置:
upstream ouyang_lb {
server 192.168.1.2 weight=1;
server 192.168.1.3 weight=2;
}

3.ip_hash(静态调度算法)

每个请求按客户端IP的hash结果分配,当新的请求到达时,先将其客户端IP通过哈希算法哈希出一个值,在随后的客户端请求中,客户IP的哈希值只要相同,就会被分配到同一台服务器,该调度算法可以解决动态网页的session共享问题,但有时会导致请求分配不均,即无法保证1:1的负载均衡,因为在国内大多数公司都是NAT上网模式,多个客户端会对应一个外部IP，所以,这些客户端都会被分配到同一个节点服务器,从而导致请求分配不均。LVS负载均衡的-p参数,
Keepalived配置的persistence_timeout
50参数都类似这个Nginx里的ip_hash参数解决动态网页的session共享问题。

 同样也来看个示例

  upstream  backend {
            ip_hash;
            server   backend1.example.com;
            server   backend2.example.com;
            server   backend3.example.com;
            server   backend4.example.com; 
     }
     注意:当负载调度算法为ip_hash时,后端服务器在负载均衡调度中的状态不能有weight和backup,即使有也不会生效

4.fair(动态调度算法)

此算法会根据端节点服务器的响应时间来分配请求,响应时间短的优先分配。这是更加智能的调度算法。此种算法可以依据页面大小和加载时间长短智能地进行负载均衡,也就是根据后端服务器地响应时间来分配请求,响应时间短地优先分配。Nginx本身时不支持fair调度算法地,如果需要使用这种调度算法,必须下载Nginx的相关模块
upstream_fair

     示例如下:
     upstream   ouyang_lb {
            server   192.168.1.2;
            server   192.168.1.3;
            fair;
     }
     fair 根据响应,谁快就给谁   理论上这个更好   更能满足用户需求

5.least_conn

least_conn算法会根据后端节点的连接数来决定分配情况,哪个机器连接数少就分发。
除了上面介绍的这些算法外,还有一些第三方的调度算法,例如:url_hash,一致性HASH算法等
因此least_conn指令的含义就是,选取活跃连接数与权重weight的比值最小者为下一个处理的server。当然,上一次已选的server和已达到最大连接数的server按照不在选择的范围

    例如一个upstream有三台server:
    upstream  backend  {
            zone   backends    64k;
            least_conn;
            server   10.10.10.2   weight=2；
            server   10.10.10.4   weight=1;
            server   10.10.10.6   weight=1;
    }

假如上一个请求选择了第二台10.10.10.4,下一个请求到来,通过比较剩下可用的server的conns/weight值来决定选哪一台
如果10.10.10.2连接数为100，10.10.10.6连接数为80，因为权重分别是2和1，因此计算结果
100/2=50， 80/1=80 因此50<80 所以选择第一台而不选第三台。尽管连接数第一台要大于第三台

6. url_hash算法

和ip_hash类似,这里是根据访问URL的hash结果来分配请求的，让每个URL定向到同一个后端服务器,后端服务器为缓存服务器时效果显著。在upstream中加入hash语句,server语句中不能写入weight等其他的参数,hash_method使用的时hash算法

url_hash按访问URL的hash结果来分配请求,使每个URL定向到同一个后端服务器,可以进一步提高后端缓存服务器的效率命中率。Nginx本身是不支持url_hash的,如果需要使用这种调度算法,必须安装Nginx的hash模块软件包。

  url_hash（WEB缓存节点）和ip_hash(会话保持)类似。示例配置如下:
  upstream  ouyang_lb {
         server   squid1:3128;
         server   squid2:3128;
         hash  $request_uri;
         hash_method  crc32;
  }

7.一致HASH算法 主要用于缓存

一致性HASH算法一般用于代理后端业务为缓存服务(squid,memcached)的场景,通过将用户请求的URI或者指定字符串进行计算,然后调度到后端的服务器上,此后任何用户查找同一个URI或者指定字符串都会被调度到这一台服务器上,因此后端的每个节点缓存的内容都是不同的,一致性HASH算法可以解决后端某个或几个节点宕机后,缓存的数据动荡的最小,一致性HASH算法知识比较复杂