nginx的 upstream模块调度算法调度算法

upstream模块调度算法调度算法通常分为两类，

• 第一类为静态调度算法，即负载均衡器根据自身设定的规则进行分配，不须要考虑后端节点服务器的状况，例如：rr、wrr、ip_hash等都属于静态调度算法。
• 第二类为动态调度算法，即负载均衡器会根据后端节点的当前状态来决定是否分发请求， 例如：链接数少的优先得到请求，响应时间短的优先得到请求。 例如：least_conn、fair等都属于动态调度算法。下面介绍一下常见的调度算法。

本文：永久连接： shudong.wang/10627.html

（1）rr轮询（默认调度算法，静态调度算法）

按客户端请求顺序把客户端的请求逐一分配到不一样的后端节点服务器， 这至关于LVS中的rr算法，若是后端节点服务器宕机（默认状况下Nginx只检测80端口）， 宕机的服务器会被自动从节点服务器池中剔除，以使客户端的用户访问不受影响。新的请求会分配给正常的服务器。

（2）wrr（权重轮询，静态调度算法）

在rr轮询算法的基础上加上权重，即为权重轮询算法，当使用该算法时，权重和用户访问成正比，权重值越大，被转发的请求也就越多。 能够根据服务器的配置和性能指定权重值大小，有效解决新旧服务器性能不均带来的请求分配问题。 举个例子帮助你们加深理解。 后端服务器192.168.1.2的配置为：E55202 CPU，8GB内存。 后端服务器192.168.1.3的配置为：Xeon（TM）2.80GHz2，4GB内存。 假设但愿在有30个请求到达前端时，其中20个请求交给192.168.1.3处理，剩余10个请求交给192.168.1.2处理，就可作以下配置；

upstream starkwang {
  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配置里的per-sistence_timeout 50参数都相似这个Nginx里的ip_hash参数，其功能均可以解决动态网页的session共享问题。一样也来看一个示例，以下：

upstream starkwang {
    ip_hash；server 192.168.1.2：80；
    server 192.168.1.3：8080；
  }
  upstream backend {    
    ip_hash；    
    server backend1.example.com；
    server backend2.example.com；   
    server backend3.example.com down；    
    server backend4.example.com；
  }
复制代码

注意：当负载调度算法为ip_hash时，后端服务器在负载均衡调度中的状态不能有weight和backup，即便有也不会生效。

（4）fair（动态调度算法）

此算法会根据后端节点服务器的响应时间来分配请求，响应时间短的优先分配。这是更加智能的调度算法。此种算法能够依据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。Ng-inx自己不支持fair调度算法，若是须要使用这种调度算法，必须下载Nginx的相关模块upstream_fair。示例以下：upstream starkwang {server 192.168.1.2；server 192.168.1.3；fair；}

（5）least_connleast_conn算法

会根据后端节点的链接数来决定分配状况，哪一个机器链接数少就分发。 除了上面介绍的这些算法外，还有一些第三方调度算法， 例如：url_hash、一致性hash算法等。

（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 starkwang {
  server squid1：3128；
  server squid2：3128；
  hash $request_uri；
  hash_method crc32；
}
复制代码

（7）一致性hash算法

一致性hash算法通常用于代理后端业务为缓存服务（如Squid、Memcached）的场景，经过将用户请求的URI或者指定字符串进行计算，而后调度到后端的服务器上，此后任何用户查找同一个URI或者指定字符串都会被调度到这一台服务器上，所以后端的每一个节点缓存的内容都是不一样的，一致性hash算法能够解决后端某个或几个节点宕机后，缓存的数据动荡最小，一致性hash算法知识比较复杂，详细内容能够参考后文或相关资料，这里仅仅给出配置示例：

http {    
  upstream test { 
    consistent_hash $request_uri；        
    server 127.0.0.1：9001 id=1001 weight=3；        
    server 127.0.0.1：9002 id=1002 weight=10；        
    server 127.0.0.1：9003 id=1003 weight=20；    
  }}
复制代码

虽然Nginx自己不支持一致性hash算法，但Nginx的分支Tengine支持。

详细可见 tengine.taobao.org/docu-ment_c…

做者博客