来源：蜘蛛抓取(WebSpider)
时间：2016-09-23 11:06
标签：
nginx 负载均衡
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员，您的IP地址所在网段被ITeye拒绝服务，这可能是以下两种情况导致：
一、您所在的网段内有网络爬虫大量抓取ITeye网页，为保证其他人流畅的访问ITeye，该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站，该代理服务器被网络爬虫利用，大量抓取ITeye网页
请您点击按钮解除封锁&摘要：对于一个大型网站来说，负载均衡是永恒的话题。随着硬件技术的迅猛发展，越来越多的负载均衡硬件设备涌现出来，如F5 BIG-IP、Citrix NetScaler、Radware等等，虽然可以解决问题，但其高昂的价格却往往令人望而却步，因此负载均衡软件仍然是大部分公司的不二之选。
nginx作为webserver的后起之秀，其优秀的反向代理功能和灵活的负载均衡策略受到了业界广泛的关注。
本文将以工业生产为背景，从设计实现和具体应用等方面详细介绍nginx负载均衡策略。
随着互联网信息的爆炸性增长，负载均衡（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是一款免费的性能测试工具，以对缓存服务、代理、交换机等方面的测试见长。它有规范的配置语言PGL（Polygraph Language），为软件提供了强大的灵活性。其工作原理如下图所示：
polygraph提供client端和server端，将测试目标nginx放在二者之间，三者之间的网络交互均走http协议，只需配置ip+port即可。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.&& 参考资料
阅读(...) 评论()使用Nginx轻松实现开源负载均衡 - 推酷
使用Nginx轻松实现开源负载均衡
使用Nginx轻松实现开源负载均衡
张宴，曾在新浪等公司任系统工程师、系统架构师。工作内容主要涉及：服务器系统架构设计与部署、系统运维与调优、网络故障解决、网站后端以及接口类PHP程序开发、Unix开源软件二次开发、服务器监控系统开发等。具有CDN部署，跨IDC的数据传输，电信网通南北互通，以及门户类FLV视频分享网站──新浪播客架构设计经验。
什么是Nginx？
Nginx&(“engine&x”)&是俄罗斯人Igor&Sysoev(塞索耶夫)编写的一款高性能的&HTTP&和反向代理服务器。
Nginx&已经在俄罗斯最大的门户网站──&Rambler&Media（www.rambler.ru）上运行了3年时间，同时俄罗斯超过20%的虚拟主机平台采用Nginx作为反向代理服务器。
在国内，已经有&新浪博客、新浪播客、网易新闻、六间房、56.com、Discuz!、水木社区、豆瓣、YUPOO、海内、迅雷在线&等多家网站使用&Nginx&作为Web服务器或反向代理服务器。
使用Nginx做七层负载均衡的理由
1、高并发连接：官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数。
2、内存消耗少：在3万并发连接下，开启的10个Nginx&进程才消耗150M内存（15M*10=150M）。
3、配置文件非常简单：风格跟程序一样通俗易懂。
4、成本低廉：Nginx为开源软件，可以免费使用。而购买F5&BIG-IP、NetScaler等硬件负载均衡交换机则需要十多万至几十万人民币。
使用Nginx做七层负载均衡的理由
5、支持Rewrite重写规则：能够根据域名、URL的不同，将&HTTP&请求分到不同的后端服务器群组。
6、内置的健康检查功能：如果&Nginx&Proxy&后端的某台&Web&服务器宕机了，不会影响前端访问。
7、节省带宽：支持&GZIP&压缩，可以添加浏览器本地缓存的&Header&头。
8、稳定性高：用于反向代理，宕机的概率微乎其微。
Nginx&负载均衡的典型应用&
硬件、软件七层负载均衡对比：
硬件、软件七层负载均衡对比：
五分钟搞定&Nginx&负载均衡
编译安装Nginx
1、创建供Nginx使用的组和帐号：
/usr/sbin/groupadd&www&-g&48
/usr/sbin/useradd&-u&48&-g&www&www
2、编译安装rewrite模块支持包
wget&ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-7.7.tar.gz
tar&zxvf&pcre-7.7.tar.gz
cd&pcre-7.7/
./configure
make&&&&make&install
编译安装Nginx
3、编译安装Nginx
wget&http://sysoev.ru/nginx/nginx-0.7.17.tar.gz
tar&zxvf&nginx-0.7.17.tar.gz
cd&nginx-0.7.17/
./configure&--user=www&--group=www&--prefix=/usr/local/nginx&--with-http_stub_status_module&--with-http_ssl_module
make&&&&make&install
4、备份默认nginx.conf配置文件
mv&/usr/local/nginx/conf/nginx.conf&&/usr/local/nginx/conf/nginx.old
创建nginx.conf配置文件(1)
1、创建Nginx配置文件
vi&/usr/local/nginx/conf/nginx.conf&
2、输入配置文件内容
user&&www&
worker_processes&8;
error_log&&/usr/local/nginx/logs/nginx_error.log&&
pid&&&&&&&&/usr/local/nginx/logs/nginx.
worker_rlimit_nofile&51200;
worker_connections&51200;
创建nginx.conf配置文件(2)
include&&&&&&&mime.
default_type&&application/octet-
#charset&&gb2312;
server_names_hash_bucket_size&128;
client_header_buffer_size&32k;
large_client_header_buffers&4&32k;
tcp_nopush&&&&&
keepalive_timeout&60;
tcp_nodelay&
创建nginx.conf配置文件(3)
#gzip_min_length&&1k;
#gzip_buffers&&&&&4&16k;
#gzip_http_version&1.0;
#gzip_comp_level&2;
#gzip_types&&&&&&&text/plain&application/x-javascript&text/css&application/
#gzip_vary&
创建nginx.conf配置文件(4)
upstream&&&&{
server&&&192.168.1.10:80;
server&&&192.168.1.11:80;
server&&&192.168.1.12:80;
server&&&192.168.1.13:81;
upstream&&&&{
server&&&192.168.1.20:80&weight=3;
server&&&192.168.1.21:80;
server&&&192.168.1.22:80;
创建nginx.conf配置文件(5)
listen&&80;
server_name&&*.;
proxy_redirect&
#后端的Web服务器可以通过X-Forwarded-For获取用户真实IP
proxy_set_header&&&X-Forwarded-For&&$remote_
if&($request_uri&&&~*&&&&.*\.(js|css|gif|jpg|jpeg|png|bmp|swf)$&)
proxy_pass&;
if&($request_uri&&&~*&&&&^/view/(.*)$&)
proxy_pass&;
proxy_pass&;
创建nginx.conf配置文件(6)
#定义日志格式
log_format&&access&&'$remote_addr&-&$remote_user&[$time_local]&$request&'
'&$status&&$body_bytes_sent&&$http_referer&&'
'&$http_user_agent&&&$http_x_forwarded_for&';
access_log&&/usr/local/nginx/logs/access.log&&
创建nginx.conf配置文件(7)
#允许客户端请求的最大的单个文件字节数
client_max_body_size&&&&&10m;
#缓冲区代理缓冲用户端请求的最大字节数&可以理解为先保存到本地再传给用户
client_body_buffer_size&&128k;
#跟后端服务器连接的超时时间_发起握手等候响应超时时间
proxy_connect_timeout&&&&600;
#连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理
proxy_read_timeout&&&&&&&600;
#后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据
proxy_send_timeout&&&&&&&600;
创建nginx.conf配置文件(8)
#代理请求缓存区_这个缓存区间会保存用户的头信息以供Nginx进行规则处理_一般只要能保存下头信息即可
proxy_buffer_size&&&&&&&&8k;
#同上&告诉Nginx保存单个用的几个Buffer&最大用多大空间
proxy_buffers&&&&&&&&&&&&4&32k;
#如果系统很忙的时候可以申请更大的proxy_buffers&官方推荐*2
proxy_busy_buffers_size&64k;
#proxy缓存临时文件的大小
proxy_temp_file_write_size&64k;
配置文件编写完毕
/usr/local/nginx/sbin/nginx&–t
如果屏幕显示以下两行信息，说明配置文件正确：
the&configuration&file&/usr/local/nginx/conf/nginx.conf&syntax&is&ok
the&configuration&file&/usr/local/nginx/conf/nginx.conf&was&tested&successfully
那么，则可以启动Nginx服务：
ulimit&-SHn&51200
/usr/local/nginx/sbin/nginx
不中断服务平滑修改Nginx配置
①、修改/usr/local/nginx/conf/nginx.conf配置文件后，请执行以下命令检查配置文件是否正确：
/usr/local/nginx/sbin/nginx&-t
如果屏幕显示以下两行信息，说明配置文件正确：
the&configuration&file&/usr/local/nginx/conf/nginx.conf&syntax&is&ok
the&configuration&file&/usr/local/nginx/conf/nginx.conf&was&tested&successfully
②、这时，输入以下命令查看Nginx主进程号：
ps&-ef&|&grep&&nginx:&master&process&&|&grep&-v&&grep&&|&awk&-F&'&'&'{print&$2}'
屏幕显示的即为Nginx主进程号，例如：
这时，执行以下命令即可使修改过的Nginx配置文件生效：
kill&-HUP&6302
或者用更简便的方法：
kill&-HUP&`cat&/usr/local/nginx/logs/nginx.pid`
编写每天定时切割Nginx日志的脚本
1、创建脚本/usr/local/nginx/sbin/cut_nginx_log.sh，输入以下内容：
#!/bin/bash
#&This&script&run&at&00:00
#&The&Nginx&logs&path
logs_path=&/usr/local/nginx/logs/&
mkdir&-p&${logs_path}$(date&-d&&yesterday&&+&%Y&)/$(date&-d&&yesterday&&+&%m&)/
mv&${logs_path}access.log&${logs_path}$(date&-d&&yesterday&&+&%Y&)/$(date&-d&&yesterday&&+&%m&)/access_$(date&-d&&yesterday&&+&%Y%m%d&).log
kill&-USR1&`cat&/usr/local/nginx/logs/nginx.pid`
2、设置crontab，每天凌晨00:00切割nginx访问日志
crontab&-e
输入以下内容：
00&00&*&*&*&/bin/bash&&/usr/local/nginx/sbin/cut_nginx_log.sh
1、对于中、小型企业，如果没有资金去购买昂贵的四/七层负载均衡交换机，那么Nginx是不错的七层负载均衡选择，并且可以通过&Nginx&+&Keepalived&实现&Nginx&负载均衡器双机互备，任意一台机器发生故障，对方都能够将虚拟IP接管过去。
2、对于有资金购买四/七层负载均衡交换机的大型网站，Nginx也有其用武之地。以门户类网站为例，&F5&BIG-IP等四/七层交换机由于负责了全站多个产品的服务，并发数非常高，而内容转发规则等七层交换业务，用不到F5&BIG-IP的四层硬件芯片，极大地消耗了F5的CPU和内存资源，成为高并发应用的制约条件。而Nginx的出现，成为了F5&BIG-IP七层交换的有力补充。
谢谢各位！
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致&&国之画&&&&&&
&& &&&&&&&&&&&&&&&&&&
鲁ICP备号-4
打开技术之扣，分享程序人生！抚琴煮酒 的BLOG
用户名：抚琴煮酒
文章数：98
评论数：2494
访问量：1074440
注册日期：
阅读量：5863
阅读量：12276
阅读量：334736
阅读量：1039494
51CTO推荐博文
现在网站发展的趋势对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术：
一种是通过硬件来进行进行，常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用；另外一种就是类似于LVS/HAProxy、Nginx的基于Linux的开源免费的负载均衡软件策略,这些都是通过软件级别来实现，所以费用非常低廉，所以我个也比较推荐大家采用第二种方案来实施自己网站的负载均衡需求。
近期朋友刘鑫(紫雨荷雪)的项目成功上线了，PV达到了亿级/日的访问量，最前端用的是HAProxy+Keepalived双机作的负载均衡器/反向代理，整个网站非常稳定；这让我更坚定了以前跟老男孩前辈聊的关于网站架构比较合理设计的架构方案：即Nginx/HAProxy+Keepalived作Web最前端的负载均衡器，后端的MySQL数据库架构采用一主多从，读写分离的方式，采用LVS+Keepalived的方式。
在这里我也有一点要跟大家申明下：很多朋友担心软件级别的负载均衡在高并发流量冲击下的稳定情况，事实是我们通过成功上线的许多网站发现，它们的稳定性也是非常好的，宕机的可能性微乎其微，所以我现在做的项目，基本上没考虑服务级别的高可用了。相信大家对这些软件级别的负载均衡软件都已经有了很深的的认识，下面我就它们的特点和适用场合分别说明下。
LVS：使用集群技术和Linux操作系统实现一个高性能、高可用的服务器，它具有很好的可伸缩性（Scalability)、可靠性（Reliability)和可管理性（Manageability)，感谢章文嵩博士为我们提供如此强大实用的开源软件。
LVS的特点是：
1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的；
2、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率；
3、工作稳定，自身有完整的双机热备方案，如LVS+Keepalived和LVS+Heartbeat，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived；
4、无流量，保证了均衡器IO的性能不会收到大流量的影响；
5、应用范围比较广，可以对所有应用做负载均衡；
6、软件本身不支持正则处理，不能做动静分离，这个就比较遗憾了；其实现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。
7、如果是网站应用比较庞大的话，实施LVS/DR+Keepalived起来就比较复杂了，特别后面有Windows Server应用的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。
Nginx的特点是：
1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是许多朋友喜欢它的原因之一；
2、Nginx对网络的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势所在；
3、Nginx安装和配置比较简单，测试起来比较方便；
4、也可以承担高的负载压力且稳定，一般能支撑超过几万次的并发量；
5、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测；
6、Nginx仅能支持http和Email，这样就在适用范围上面小很多，这个它的弱势；
7、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP现在也是非常流行的web架构，大有和以前最流行的LAMP架构分庭抗争之势，在高流量的环境中也有很好的效果。
8、Nginx现在作为Web反向加速缓存越来越成熟了，很多朋友都已在生产环境下投入生产了，而且反映效果不错，速度比传统的Squid服务器更快，有兴趣的朋友可以考虑用其作为反向代理加速器。
HAProxy的特点是：
1、HAProxy是支持虚拟主机的，以前有朋友说这个不支持虚拟主机，我这里特此更正一下。
2、能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作
3、支持url检测后端的服务器出问题的检测会有很好的帮助。
4、它跟LVS一样，本身仅仅就只是一款负载均衡软件；单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。
5、HAProxy可以对Mysql读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，不过在后端的MySQL slaves数量超过10台时性能不如LVS，所以我向大家推荐LVS+Keepalived。
6、HAProxy的算法现在也越来越多了，具体有如下8种：
①roundrobin，表示简单的轮询，这个不多说，这个是负载均衡基本都具备的；
②static-rr，表示根据权重，建议关注；
③leastconn，表示最少连接者先处理，建议关注；
④source，表示根据请求源IP，这个跟Nginx的IP_hash机制类似，我们用其作为解决session问题的一种方法，建议关注；
⑤ri，表示根据请求的URI；
⑥rl_param，表示根据请求的URl参数'balance url_param' requires an URL parameter name；
⑦hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；
⑧rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)
本文收录至博客专题：《》《》
16:17:16 17:13:06 17:17:10 17:20:39 21:50:52 22:19:55 06:35:20 08:56:09 09:41:15 22:40:11 10:04:10 10:42:22 10:54:59 03:15:13 09:51:41 11:56:03 15:54:48 11:45:32 11:53:49 19:22:19 09:59:03 16:53:50 16:56:31 23:10:40 11:26:29 &&1&
&&页数 ( 1/2 ) &
