在架构系统的时候，通常会涉及到分布式，而处分布式里面最前端的是负载均衡器(当然还有cdn)。在网上搜寻一份，对目前常见的负载均衡器做一些介绍和常见组合，不涉及具体配置。
第一种是常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用；
第二种是类似于LVS/HAProxy、Nginx的基于Linux的开源免费的负载均衡软件策略,这些都是通过软件级别来实现，所以费用非常低廉，所以我个也比较推荐大家采用第二种方案来实施自己网站的负载均衡需求。除了这些还有：Lighttpd、Apache-mod_proxy、Squid、Socks、TIS FWTK、Delegate。
LVS的特点是：
1.抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的；
2.配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率；
3.工作稳定，自身有完整的双机热备方案，如LVS+Keepalived和LVS+Heartbeat，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived；
4.无流量，保证了均衡器IO的性能不会收到大流量的影响；
5.应用范围比较广，可以对所有应用做负载均衡；
6.软件本身不支持正则处理，不能做动静分离，这个就比较遗憾了；其实现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。如果是网站应用比较庞大的话，实施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请求。
Nginx和LVS作对比的结果
1、Nginx工作在网络的7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下LVS并不具备这样的功能，所 以 Nginx单凭这点可利用的场合就远多于LVS了；但Nginx有用的这些功能使其可调整度要高于LVS，所以经常要去触碰触碰，由LVS的第2条优点 看，触碰多了，人为出问题的几率也就会大。
2、Nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，Nginx就能连得通，Nginx同时还能区分内外网，如果是同时拥有内外网的 节点，就相当于单机拥有了备份线路；LVS就比较依赖于网络环境，目前来看服务器在同一网段内并且LVS使用direct方式分流，效果较能得到保证。另 外注意，LVS需要向托管商至少申请多一个ip来做Visual IP，貌似是不能用本身的IP来做VIP的。要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了。站长教学网 eduyo.com
3、Nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。LVS的安装和配置、测试就要花比较长的时间了，因为同上所述，LVS对网络依赖比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。
4、Nginx也同样能承受很高负载且稳定，但负载度和稳定度差LVS还有几个等级：Nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的；Nginx没有现成的双机热备方案，所以跑在单机上还是风险较大，单机上的事情全都很难说。
5、Nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前LVS中 ldirectd也能支持针对服务器内部的情况来监控，但LVS的原理使其不能重发请求。重发请求这点，譬如用户正在上传一个文件，而处理该上传的节点刚 好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能 会因此而恼火。
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载，假如使用apache直接对外服务，那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放，使用多一个Nginx做apache代理的话，这些窄带链接会被Nginx挡住，apache上就不会堆积过多的请求，这样就减少了相 当多的内存占用。这点使用squid也有相同的作用，即使squid本身配置为不缓存，对apache还是有很大帮助的。LVS没有这些功能，也就无法能 比较。
7、Nginx能支持http和email（email的功能估计比较少人用），LVS所支持的应用在这点上会比Nginx更多。在使用上，一般最前端所 采取的策略应是LVS，也就是DNS的指向应为LVS均衡器，LVS的优点令它非常适合做这个任务。重要的ip地址，最好交由LVS托管，比如数据库的 ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给 LVS托管是最为稳妥的，这样做的唯一缺点是需要的VIP数量会比较多。Nginx可作为LVS节点机器使用，一是可以利用Nginx的功能，二是可以利 用Nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比Nginx弱不少了，性能上也有所逊色于Nginx。Nginx也 可作为中层代理使用，这一层面Nginx基本上无对手，唯一可以撼动Nginx的就只有lighttpd了，不过lighttpd目前还没有能做到 Nginx完全的功能，配置也不那么清晰易读。另外，中层代理的IP也是重要的，所以中层代理也拥有一个VIP和LVS是最完美的方案了。具体的应用还得 具体分析，如果是比较小的网站（日PV<1000万），用Nginx就完全可以了，如果机器也不少，可以用DNS轮询，LVS所耗费的机器还是比较 多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用LVS
反向代理从传输上分可以分为2种：
1：同步模式(apache-mod_proxy和squid)
2：异步模式(lighttpd 和 nginx)
在nginx的文档说明中，提到了异步传输模式并提到它可以减少后端连接数和压力，这是为何？
下面就来讲解下传统的代理（apache/squid）的同步传输和lighttpd,nginx的异步传输的差异。
同步传输：浏览器发起请求，而后请求会立刻被转到后台，于是在浏览器和后台之间就建立了一个通道。在请求发起直到请求完成，这条通道都是一直存在的。
异步传输：浏览器发起请求，请求不会立刻转到后台，而是将请求数据（header）先收到nginx上，然后nginx再把这个请求发到后端，后端处理完之后把数据返回到nginx上，nginx将数据流发到浏览器，这点和lighttpd有点不同，lighttpd是将后端数据完全接收后才发送到浏览器。
Squid作为网页服务器的前置cache服务器，可以代理用户向web服务器请求数据并进行缓存，也可以用在局域网中，使局域网用户通过代理上网。Squid与Linux下其它的代理软件如Apache、Socks、TIS FWTK和delegate相比，下载安装简单，配置简单灵活，支持缓存和多种协议。用ipchains+Squid的解决方案，就可以获得通过缓存高性能的同时能够无缝的访问Internet。
小结：apache和squid的反向会增加后端web的负担，因为每个用户请求都会在proxy上与后端server建立的长久链接，知道数据取完前，连接都不会消失。因为wan速度与lan速度的不同，虽然lan之间的速度是极度快的，但是用户的wan连接决定了这个时间长。而lighttpd和nginx的异步模式，是不管你用户要求的数据有多大，都是先收下来，再与后端联系，这是非常迅速的速度，所以proxy与后端连接时间也会很短，几十M的东西也是几秒内。后端不需要维护这么多连接。而lighttpd也和nginx不同的异步，lighttpd是先收完再转向客户浏览器，而nginx是边收数据边转向用户浏览器。
那么这到底有什么好处呢？
1. 假设用户执行一个上传文件操作，因为用户网速又比较慢，因此需要花半个小时才能把文件传到服务器。squid的同步代理在用户开始上传后就和后台建立了连接，半小时后文件上传结束，由此可见，后台服务器连接保持了半个小时；而nginx异步代理就是先将此文件收到nginx上，因此仅仅是nginx和用户保持了半小时连接，后台服务器在这半小时内没有为这个请求开启连接，半小时后用户上传结束，nginx才将上传内容发到后台，nginx和后台之间的带宽是很充裕的，所以只花了一秒钟就将请求发送到了后台，由此可见，后台服务器连接保持了一秒。同步传输花了后台服务器半个小时，异步传输只花一秒，可见优化程度很大。
2. 在上面这个例子中，假如后台服务器因为种种原因重启了，上传文件就自然中断了，这对用户来说是非常恼火的一件事情，想必各位也有上传文件传到一半被中断的经历。用nginx代理之后，后台服务器的重启对用户上传的影响减少到了极点，而nginx是非常稳定的并不需要常去重启它，即使需要重启，利用kill -HUP就可以做到不间断重启nginx。
3. 异步传输可以令负载均衡器更有保障，为什么这么说呢？在其它的均衡器（lvs/haproxy/apache等）里，每个请求都是只有一次机会的，假如用户发起一个请求，结果该请求分到的后台服务器刚好挂掉了，那么这个请求就失败了；而nginx因为是异步的，所以这个请求可以重新发往下一个后台，下一个后台返回了正常的数据，于是这个请求就能成功了。还是用用户上传文件这个例子，假如不但用了nginx代理，而且用了负载均衡，nginx把上传文件发往其中一台后台，但这台服务器突然重启了，nginx收到错误后，会将这个上传文件发到另一台后台，于是用户就不用再花半小时上传一遍。
4. 假如用户上传一个10GB大小的文件，而后台服务器没有考虑到这个情况，那么后台服务器岂不要崩溃了。用nginx就可以把这些东西都拦在nginx上，通过nginx的上传文件大小限制功能来限制，另外nginx性能非常有保障，就放心的让互联网上那些另类的用户和nginx对抗去吧。
用异步传输会造成问题：
后台服务器有提供上传进度的功能的话，用了nginx代理就无法取得进度，这个需要使用nginx的一个第三方模块来实现。
针对高可用（HA）通常做是主备或者集群，也是分布式集群的中的很重要一环，直接避免单点故障。目前使用较多的HA软件有：Keepalived、Heartbeat、 Piranha、Pacemaker；
Keepalived和Heartbeat对比：
Keepalived使用的vrrp协议方式，虚拟路由冗余协议 (Virtual Router Redundancy Protocol，简称VRRP)。Heartbeat是基于主机或网络的服务的高可用方式；
keepalived的目的是模拟路由器的双机。heartbeat的目的是用户service的双机；
lvs的高可用建议用keepavlived。业务的高可用用heartbeat
Piranha 提供了一套解决方案，包括对服务状态的监控、业务服务器的监控和负载服务器本身热备。
Pacemaker 是一个集群资源管理器。它利用你喜欢的集群基础构件（OpenAIS 或heartbeat）提供的消息和成员管理能力来探测并从节点或资源级别的故障中恢复，以实现群集服务（亦称资源）的最大可用性。
它可以做几乎任何规模的集群，并带有一个强大的依赖模式，让管理员能够准确地表达的群集资源之间的关系（包括顺序和位置）。几乎任何可以编写的脚本，都可以作为管理起搏器集群的一部分。尤为重要的是Pacemaker不是一个heartbeat的工具，可能有人存在这样的误解。Pacemaker是一个延续CRM（亦称V2资源管理器）的项目。最初开发的项目是heartbeat，已经成为该项目的子项目。