最近网站不收录,开外贸公司的流程及费用,太原做网站哪里好,网站建设沈阳凯鸿摘要#xff1a;对于一个大型网站来说#xff0c;负载均衡是永恒的话题。随着硬件技术的迅猛发展#xff0c;越来越多的负载均衡硬件设备涌现出来#xff0c;如F5 BIG-IP、Citrix NetScaler、Radware等等#xff0c;虽然可以解决问题#xff0c;但其高昂的价格却往往令人…摘要对于一个大型网站来说负载均衡是永恒的话题。随着硬件技术的迅猛发展越来越多的负载均衡硬件设备涌现出来如F5 BIG-IP、Citrix NetScaler、Radware等等虽然可以解决问题但其高昂的价格却往往令人望而却步因此负载均衡软件仍然是大部分公司的不二之选。nginx作为webserver的后起之秀其优秀的反向代理功能和灵活的负载均衡策略受到了业界广泛的关注。本文将以工业生产为背景从设计实现和具体应用等方面详细介绍nginx负载均衡策略。 关键字nginx 负载均衡 反向代理 1.前言 随着互联网信息的爆炸性增长负载均衡load balance已经不再是一个很陌生的话题顾名思义负载均衡即是将负载分摊到不同的服务单元既保证服务的可用性又保证响应足够快给用户很好的体验。快速增长的访问量和数据流量催生了各式各样的负载均衡产品很多专业的负载均衡硬件提供了很好的功能但却价格不菲这使得负载均衡软件大受欢迎nginx就是其中的一个。 nginx第一个公开版本发布于2004年2011年发布了1.0版本。它的特点是稳定性高、功能强大、资源消耗低从其目前的市场占有而言nginx大有与apache抢市场的势头。其中不得不提到的一个特性就是其负载均衡功能这也成了很多公司选择它的主要原因。本文将从源码的角度介绍nginx的内置负载均衡策略和扩展负载均衡策略以实际的工业生产为案例对比各负载均衡策略为nginx使用者提供参考。 2. 源码剖析 nginx的负载均衡策略可以划分为两大类内置策略和扩展策略。内置策略包含加权轮询和ip hash在默认情况下这两种策略会编译进nginx内核只需在nginx配置中指明参数即可。扩展策略有很多如fair、通用hash、consistent hash等默认不编译进nginx内核。由于在nginx版本升级中负载均衡的代码没有本质性的变化因此下面将以nginx1.0.15稳定版为例从源码角度分析各个策略。 2.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.2. ip hash ip hash是nginx内置的另一个负载均衡的策略流程和轮询很类似只是其中的算法和具体的策略有些变化如下图所示 ip hash算法的核心实现如下图 从代码中可以看出hash值既与ip有关又与后端机器的数量有关。经过测试上述算法可以连续产生1045个互异的value这是该算法的硬限制。对此nginx使用了保护机制当经过20次hash仍然找不到可用的机器时算法退化成轮询。因此从本质上说ip hash算法是一种变相的轮询算法如果两个ip的初始hash值恰好相同那么来自这两个ip的请求将永远落在同一台服务器上这为均衡性埋下了很深的隐患。 2.3. fair fair策略是扩展策略默认不被编译进nginx内核。其原理是根据后端服务器的响应时间判断负载情况从中选出负载最轻的机器进行分流。这种策略具有很强的自适应性但是实际的网络环境往往不是那么简单因此要慎用。 2.4. 通用hash、一致性hash 这两种也是扩展策略在具体的实现上有些差别通用hash比较简单可以以nginx内置的变量为key进行hash一致性hash采用了nginx内置的一致性hash环可以支持memcache。 3. 对比测试 本测试主要为了对比各个策略的均衡性、一致性、容灾性等从而分析出其中的差异性并据此给出各自的适用场景。为了能够全面、客观的测试nginx的负载均衡策略我们采用了两个测试工具、在不同场景下做测试以此来降低环境对测试结果造成的影响。首先简单介绍测试工具、测试网络拓扑和基本的测试流程。 3.1. 测试工具 3.1.1 easyABC easyABC是公司内部开发的性能测试工具采用epool模型实现简单易上手可以模拟GET/POST请求极限情况下可以提供上万的压力在公司内部得到了广泛的使用。由于被测试对象为反向代理服务器因此需要在其后端搭建桩服务器这里用nginx作为桩webserver提供最基本的静态文件服务。 3.1.2 polygraph polygraph是一款免费的性能测试工具以对缓存服务、代理、交换机等方面的测试见长。它有规范的配置语言PGLPolygraph Language为软件提供了强大的灵活性。其工作原理如下图所示 polygraph提供client端和server端将测试目标nginx放在二者之间三者之间的网络交互均走http协议只需配置ipport即可。client端可以配置虚拟robot的个数以及每个robot发请求的速率并向代理服务器发起随机的静态文件请求server端将按照请求的url生成随机大小的静态文件做响应。这也是选用这个测试软件的一个主要原因可以产生随机的url作为nginx各种hash策略的key。 另外polygraph还提供了日志分析工具功能比较丰富感兴趣的同学可以参考附录中的相关材料。 3.2. 测试环境 本测试运行在5台物理机上其中被测对象单独搭在一台8核机器上另外四台4核机器分别搭建了easyABC、webserver桩和polygraph如下图所示 3.3. 测试方案 首先介绍下关键的测试指标 均衡性是否能够将请求均匀的发送给后端 一致性同一个key的请求是否能落到同一台机器 容灾性当部分后端机器挂掉时是否能够正常工作 以上述指标为指导我们针对如下四个测试场景分别用easyABC和polygraph进行测试 场景1 server_*均正常提供服务 场景2 server_4挂掉其他正常 场景3 server_3、server_4挂掉其他正常 场景4 server_*均恢复正常服务。 上述四个场景将按照时间顺序进行每个场景将建立在上一个场景基础上被测试对象无需做任何操作以最大程度模拟实际情况。另外考虑到测试工具自身的特点在easyabc上的测试压力在17000左右polygraph上的测试压力在4000左右。以上测试均保证被测试对象可以正常工作且无任何notice级别以上alert/error/warn的日志出现在每个场景中记录下server_*的qps用于最后的策略分析。 3.4. 测试结果 表1和图1是轮询策略在两种测试工具下的负载情况。对比在两种测试工具下的测试结果会发现结果完全一致因此可以排除测试工具的影响。从图表中可以看出轮询策略对于均衡性和容灾性都可以做到很好的满足。(点击图片查看大图) 表2和图2是fair策略在两种测试工具下的负载情况。fair策略受环境影响非常大在排除了测试工具的干扰之后结果仍然有非常大的抖动。从直观上讲这完全不满足均衡性。但是从另一个角度出发恰恰是由于这种自适应性确保了在复杂的网络环境中能够物尽所用。因此在应用到工业生产中之前需要在具体的环境中做好测试工作。(点击图片查看大图) 以下图表是各种hash策略所不同的仅仅是hash key或者是具体的算法实现因此一起做对比。实际测试中发现通用hash和一致性hash均存在一个问题当某台后端的机器挂掉时原有落到这台机器上的流量会丢失但是在ip hash中就不存在这样的问题。正如上文中对ip hash源码的分析当ip hash失效时会退化为轮询策略因此不会有丢失流量的情况。从这个层面上说ip hash也可以看成是轮询的升级版。(点击图片查看大图) 图5为ip hash策略ip hash是nginx内置策略可以看做是前两种策略的特例以来源ip为key。由于测试工具不便于模拟海量ip下的请求因此这里截取线上实际的情况加以分析如下图所示 图5 ip hash策略 图中前1/3使用轮询策略中间段使用ip hash策略后1/3仍然是轮询策略。可以明显的看出ip hash的均衡性存在着很大的问题。原因并不难分析在实际的网络环境中有大量的高校出口路由器ip、企业出口路由器ip等网络节点这些节点带来的流量往往是普通用户的成百上千倍而ip hash策略恰恰是按照ip来划分流量因此造成上述后果也就自然而然了。 4. 总结与展望 通过实际的对比测试我们对nginx各个负载均衡策略进行了验证。下面从均衡性、一致性、容灾性以及适用场景等角度对比各种策略。(点击图片查看大图) 以上从源码和实际的测试数据角度分析说明了nginx负载均衡的策略并给出了各种策略适合的应用场景。通过本文的分析不难发现无论哪种策略都不是万金油在具体的场景下应该选择哪种策略一定程度上依赖于使用者对这些策略的熟悉程度。希望本文的分析和测试数据能够对读者有所帮助更希望有越来越多、越来越好的负载均衡策略产出。 5. 参考资料 http://wiki.nginx.org/HttpUpstreamConsistentHash http://wiki.nginx.org/HttpUpstreamFairModule http://wiki.nginx.org/HttpUpstreamRequestHashModule http://www.web-polygraph.org/ http://nginx.org/ 转自http://www.kuqin.com/web/20120728/323399.html