Nginx的负载均衡的那点事

最新推荐文章于 2024-07-13 17:35:55 发布

shero_zsmj

最新推荐文章于 2024-07-13 17:35:55 发布

阅读量739

点赞数

分类专栏：我的技术收集之路——杂七杂八系列

本文链接：https://blog.csdn.net/shero_zsmj/article/details/52234821

版权

我的技术收集之路——杂七杂八系列专栏收录该内容

6 篇文章 0 订阅

订阅专栏

HTTP负载均衡，也就是我们通常所有“七层负载均衡”，工作在第七层“应用层”。而TCP负载均衡，就是我们通常所说的“四层负载均衡”，工作在“网络层”和“传输层”。例如，LVS（Linux Virtual Server，Linux虚拟服务）和F5（一种硬件负载均衡设备），也是属于“四层负载均衡”。

轮询策略和IP哈希策略对比

加权轮询策略

优点：适用性更强，不依赖于客户端的任何信息，完全依靠后端服务器的情况来进行选择。能把客户端请求更合理更均匀地分配到各个后端服务器处理。

缺点：同一个客户端的多次请求可能会被分配到不同的后端服务器进行处理，无法满足做会话保持的应用的需求。

IP哈希策略

优点：能较好地把同一个客户端的多次请求分配到同一台服务器处理，避免了加权轮询无法适用会话保持的需求。

缺点：当某个时刻来自某个IP地址的请求特别多，那么将导致某台后端服务器的压力可能非常大，而其他后端服务器却空闲的不均衡情况、

此下面将以nginx1.0.15稳定版为例，从源码角度分析各个策略。

1. 加权轮询（weighted round robin）

轮询的原理很简单，首先我们介绍一下轮询的基本流程。如下是处理一次请求的流程图：

图中有两点需要注意，第一，如果可以把加权轮询算法分为先深搜索和先广搜索，那么nginx采用的是先深搜索算法，即将首先将请求都分给高权重的机器，直到该机器的权值降到了比其他机器低，才开始将请求分给下一个高权重的机器；第二，当所有后端机器都down掉时，nginx会立即将所有机器的标志位清成初始状态，以避免造成所有的机器都处在timeout的状态，从而导致整个前端被夯住。

接下来看下源码。nginx源码的目录结构很清晰，加权轮询所在路径为nginx-1.0.15/src/http/ngx_http_upstream_round_robin.[c|h]，在源码的基础上，针对重要的、不易理解的地方我加了注释。首先看下ngx_http_upstream_round_robin.h中的重要声明：

从变量命名中，我们就可以大致猜出其作用。其中，current_weight和weight的区别主要是前者为权重排序的值，随着处理请求会动态的变化，后者是配置值，用于恢复初始状态。

接下来看下轮询的创建过程，代码如下图所示。

这里有个tried变量需要做些说明。tried中记录了服务器当前是否被尝试连接过。他是一个位图。如果服务器数量小于32，则只需在一个int中即可记录下所有服务器状态。如果服务器数量大于32，则需在内存池中申请内存来存储。对该位图数组的使用可参考如下代码：

最后是实际的策略代码，逻辑很简单，代码实现也只有30行，直接上代码。

2. ip hash

ip hash是nginx内置的另一个负载均衡的策略，流程和轮询很类似，只是其中的算法和具体的策略有些变化，如下图所示：

ip hash算法的核心实现如下图：

从代码中可以看出，hash值既与ip有关又与后端机器的数量有关。经过测试，上述算法可以连续产生1045个互异的value，这是该算法的硬限制。对此nginx使用了保护机制，当经过20次hash仍然找不到可用的机器时，算法退化成轮询。因此，从本质上说，ip hash算法是一种变相的轮询算法，如果两个ip的初始hash值恰好相同，那么来自这两个ip的请求将永远落在同一台服务器上，这为均衡性埋下了很深的隐患。

3. fair

fair策略是扩展策略，默认不被编译进nginx内核。其原理是根据后端服务器的响应时间判断负载情况，从中选出负载最轻的机器进行分流。这种策略具有很强的自适应性，但是实际的网络环境往往不是那么简单，因此要慎用。

4. 通用hash、一致性hash

这两种也是扩展策略，在具体的实现上有些差别，通用hash比较简单，可以以nginx内置的变量为key进行hash，一致性hash采用了nginx内置的一致性hash环，可以支持memcache。

对上面的集中负载均衡算法进行测试（测试工具polygraph），考察下面三个关键的测试指标：

均衡性：是否能够将请求均匀的发送给后端

一致性：同一个key的请求，是否能落到同一台机器

容灾性：当部分后端机器挂掉时，是否能够正常工作

通过实际的对比测试，我们对nginx各个负载均衡策略进行了验证。下面从均衡性、一致性、容灾性以及适用场景等角度对比各种策略。

无论哪种策略都不是万金油，在具体的场景下应该选择哪种策略一定程度上依赖于使用者对这些策略的熟悉程度。希望本文的分析和测试数据能够对读者有所帮助，更希望有越来越多、越来越好的负载均衡策略产出。

本节就聊聊采用Nginx负载均衡之后碰到的问题：

Session问题
文件上传下载

通常解决服务器负载问题，都会通过多服务器分载来解决。常见的解决方案有：

网站入口通过分站链接负载（天空软件站，华军软件园等）
DNS轮询
F5物理设备
Nginx等轻量级架构

那我们看看Nginx是如何实现负载均衡的，Nginx的upstream目前支持以下几种方式的分配
1、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
2、weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
2、ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
3、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
4、url_hash（第三方）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

Upstream配置如何实现负载

 
    http {    
    
    upstream  www.test1.com {
          ip_hash;
          server   
    
    172.16
    
    .
    
    125.76
    
    :
    
    8066
    
     weight
    
    =
    
    10
    
    ;
          server   
    
    172.16
    
    .
    
    125.76
    
    :
    
    8077
    
     down;
          server   
    
    172.16
    
    .
    
    0.18
    
    :
    
    8066
    
     max_fails
    
    =
    
    3
    
     fail_timeout
    
    =
    
    30s;
          server   
    
    172.16
    
    .
    
    0.18
    
    :
    
    8077
    
     backup;
     }
      
     upstream  www.test2.com {
          server   
    
    172.16
    
    .
    
    0.21
    
    :
    
    8066
    
    ;
          server   
    
    192.168
    
    .
    
    76.98
    
    :
    
    8066
    
    ;         
     }

     server {
        listen       
    
    80
    
    ;
        server_name  www.test1.com;        
       
        location 
    
    /
    
    {
           proxy_pass        http:
    
    //
    
    www.test1.com;
    
               proxy_set_header   Host             $host;
           proxy_set_header   X
    
    -
    
    Real
    
    -
    
    IP        $remote_addr;
           proxy_set_header   X
    
    -
    
    Forwarded
    
    -
    
    For  $proxy_add_x_forwarded_for;
        }      
     }  
     
     server {
        listen       
    
    80
    
    ;
        server_name  www.test2.com;        
       
        location 
    
    /
    
    {
           proxy_pass        http:
    
    //
    
    www.test2.com;
    
               proxy_set_header   Host             $host;
           proxy_set_header   X
    
    -
    
    Real
    
    -
    
    IP        $remote_addr;
           proxy_set_header   X
    
    -
    
    Forwarded
    
    -
    
    For  $proxy_add_x_forwarded_for;
     }
}

当有请求到www.test1.com/www.test2.com 时请求会被分发到对应的upstream设置的服务器列表上。test2的每一次请求分发的服务器都是随机的，就是第一种情况列举的。而test1刚是根据来访问ip的hashid来分发到指定的服务器，也就是说该IP的请求都是转到这个指定的服务器上。

根据服务器的本身的性能差别及职能，可以设置不同的参数控制。

down 表示负载过重或者不参与负载

weight 权重过大代表承担的负载就越大

backup 其它服务器时或down时才会请求backup服务器

max_fails 失败超过指定次数会暂停或请求转往其它服务器

fail_timeout 失败超过指定次数后暂停时间

以上就Nginx的负载均衡的简单配置。那继续我们的本节讨论内容：

一、Session问题

当我们确定一系列负载的服务器后，那我们的WEB站点会分布到这些服务器上。这个时候如果采用Test2 每一次请求随机访问任何一台服务器上，这样导致你访问A服务器后，下一次请求又突然转到B服务器上。这个时候与A服务器建立的Session，传到B站点服务器肯定是无法正常响应的。我们看一下常用的解决方案：

Session或凭据缓存到独立的服务器
Session或凭据保存数据库中
nginx ip_hash 保持同一IP的请求都是指定到固定的一台服务器

第一种缓存的方式比较理想，缓存的效率也比较高。但是每一台请求服务器都去访问Session会话服务器，那不是加载重了这台Session服务器的负担吗？

第二种保存到数据库中，除了要控制Session的有效期，同时加重了数据库的负担，所以最终的转变为SQL Server 负载均衡，涉及读，写，过期，同步。

第三种通过nginx ip_hash负载保持对同一服务器的会话，这种看起来最方便，最轻量。

正常情况下架构简单的话， ip_hash可以解决Session问题，但是我们来看看下面这种情况

这个时候ip_hash 收到的请求都是来自固定IP代理的请求，如果代理IP的负载过高就会导致ip_hash对应的服务器负载压力过大，这样ip_hash就失去了负载均衡的作用了。

如果缓存可以实现同步共享的话，我们可以通过多session服务器来解决单一负载过重的问题。那Memcached是否可以做Session缓存服务器呢？MemcachedProvider提供了Session的功能，即将Session保存到数据库中。那为什么不直接保存到数据库中，而要通过Memcached保存到数据库中呢？很简单，如果直接保存到数据库中，每一次请求Session有效性都要回数据库验证一下。其次，即使我们为数据库建立一层缓存，那这个缓存也无法实现分布式共享，还是针对同一台缓存服务器负载过重。网上也看到有用Memcached实现Session缓存的成功案例，当然数据库方式实现的还是比较常用的，比如开源Disuz.net论坛。缓存实现的小范围分布式也是比较常用的，比如单点登录也是一种特殊情况。

二、文件上传下载

如果实现了负载均衡，除了Session问题，我们还会碰到文件的上传下载问题。文件不可能上传不同的服务器上，这样会导致下载不到对应文件的问题。我们看一下下面的方案