> 博客详情
&浅谈千万级PV/IP规模高性能高并发网站架构
原创作品，允许转载，转载时请务必以超链接形式标明文章&
&、作者信息和本声明。否则将追究法律责任。
原创作者：老男孩linux实战运维培训机构&老男孩 QQ： && 说明：几个月前老男孩发过一次类似的文章，本次为了参加一个朋友邀请的活动，稍微完善了一下，欢迎各位同仁一起交流网站架构技术。
文章架构简图：
高并发访问的核心原则其实就一句话“把所有的用户访问请求都尽量往前推”。
&&&&如果把来访用户比作来犯的"敌人"，我们一定要把他们挡在800里地以外，即不能让他们的请求一下打到我们的指挥部（指挥部就是数据库及分布式存储）。
&&&&如：能缓存在用户电脑本地的，就不要让他去访问CDN。 能缓存CDN服务器上的，就不要让CDN去访问源（静态服务器）了。能访问静态服务器的，就不要去访问动态服务器。以此类推：能不访问数据库和存储就一定不要去访问数据库和存储。
&&&&说起来很轻松，实际做起来却不容易，但只要稍加努力是可以做到的，Google的日独立IP过亿不也做到了么？我们这几千万的PV站比起Google不是小屋见大屋了。我们还是先从我们的小屋搭起吧！哈哈！下面内容的介绍起点是千万级别的PV站，也可以支持亿级PV的网站架构。
高性能高并发高可扩展网站架构访问的几个层次：
&&&&有人会问，我们老是说把用户对业务的访问往前推，到底怎么推啊？推到哪呢？下面，老男孩就为大家一一道来。
第一层：首先在用户浏览器端，使用Apache的mod_deflate压缩传输，再比如：expires功能、deflate和expires功能利用的好，就会大大提升用户体验效果及减少网站带宽，减少后端服务器的压力。当然，方法还有很多，这里不一一细谈了。
提示：有关压缩传输及expires功能nginx/lighttpd等软件同样也有。
第二层：页面元素，如图片/js/css等或静态数据html，这个层面是网页缓存层,比如CDN（效果比公司自己部署squid/nginx要好，他们更专业，价格低廉，比如快网/CC等（价格80元/M/月甚至更低）而且覆盖的城市节点更多），自己架设squid/nginx cache来做小型CDN是次选(超大规模的公司可能会考虑风险问题实行自建加购买服务结合)，除非是为前端的CDN提供数据源服务，以减轻后端我们的服务器数据及存储压力，而不是直接提供cache服务给最终用户。taobao的CDN曾经因为一部分图片的次寸大而导致CDN压力大的情况，甚至对图片尺寸大的来改小，以达到降低流量及带宽的作用。
&&&&提示：我们也可以自己架设一层cache层，对我们购买的CDN提供数据源服务，可用的软件有varnish/nginx/squid&等cache，以减轻第三层静态数据层的压力。在这层的前端我们也可以架设DNS服务器，来达到跨机房业务拓展及智能解析的目的。
第三层：静态服务器层一般为图片服务器，视频服务器，静态HTML服务器。这一层是前面缓存层和后面动态服务器层的连接纽带，大公司发布新闻等内容直接由发布人员分发到各cache节点（sina,163等都是如此），这和一般公司的业务可能不一样。所以，没法直接的参考模仿，比如人人的SNS。
&&&&我们可以使用Q队列方式实现异步的分发访问，同时把动态发布数据（数据库中的数据）静态化存储。即放到本层访问，或通过其他办法发布到各cache节点，而不是直接让所有用户去访问数据库，不知道大家发现了没有，<门户的新闻评论多的有几十万条，如果所有用户一看新闻就加载所有评论，那数据库不挂才怪。他们的评论需要审核（美其名约，实际是异步的方式，而且，评论可能都是静态化的或类似的静态化或内存cache的方式），这点可能就是需要<这样站点学习的，你们打开51CTO的一篇博文，就会发现下面的评论一直都显示出来了，也可能是分页的。不过，应该都是直接读库的，一旦访问量大，数据库压力大是必然。这里不是说51cto网站不好，所有的网站都是从类似的程序架构开始发展的。CU也可能是如此。
&&&&提示：我们可以在静态数据层的前端自己架设一层cache层，对我们购买的CDN提供数据源服务，可用的软件有varnish/nginx/squid&等cache。在这层的前端我们也可以架设DNS服务器，来达到跨机房业务拓展及智能解析的目的。
第四层：动态服务器层：php,java等，只有透过了前面3层后的访问请求才会到这个层，才可能会访问数据库及存储设备。经过前三层的访问过滤能到这层访问请求一般来说已非常少了，一般都是新发布的内容和新发布内容第一次浏览如；博文（包括微博等），BBS帖子。
&&&&特别提示：此层可以在程序上多做文章，比如向下访问cache层，memcache，memcachedb，tc，mysql，oracle，在程序级别实现分布式访问，分布式读写分离，而程序级别分布式访问的每个db cache节点，又可以是一组业务或者一组业务拆分开来的多台服务器的负载均衡。这样的架构会为后面的数据库和存储层大大的减少压力，那么这里呢，相当于指挥部的外层了。
第五层：数据库cache层，比如：memcache,memcachedb,tc等等。 &&&& &&&&根据不同的业务需求，选择适合具体业务的数据库。对于memcache、memcachedb ttserver及相关nosql数据库，可以在第四层通过程序来实现对本层实现分布式访问，每个分布式访问的节点都可能是一组负载均衡（数十台机器）。
第六层：数据库层，一般的不是超大站点都会用mysql主从结构，如：163，sina，kaixin都是如此，程序层做分布式数据库读写分离，一主（或双主）多从的方式，访问大了，可以做级连的主从及环状的多主多从，然后，实现多组负载均衡，供前端的分布式程序调用，如果访问量在大，就需要拆业务了，比如：我再给某企业做兼职时，发现类似的51cto的一个站点，把www服务，blog服务，bbs服务都放一个服务器上，然后做主从。这种情况，当业务访问量大了，可以简单的把www，blog，bbs服务分别各用一组服务器拆分开，这种方式运维都会的没啥难度。当然访问量在大了，可以继续针对某一个服务拆分如：www库拆分，每个库做一组负载均衡，还可以对库里的表拆分。需要高可用可以通过drbd等工具做成高可用方式。对于写大的，可以做主主或多主的MYSQL REP方式，对于ORACLE来说，来几组oracle DG（1master多salve方式）就够了，11G的DG可以象mysql rep一样，支持读写分离了。当然可选的方案还有，mysql cluster&和oracle&的RAC，玩mysql cluster和oracle RAC要需要更好更多的硬件及部署后的大量维护成本，因此，要综合考虑，到这里访问量还很大，那就恭喜了，起码是几千万以上甚至上亿的PV了。
&&&&象百度等巨型公司除了会采用常规的mysql及oracle数据库库外，会在性能要求更高的领域，大量的使用nosql数据库，然后前端在加DNS，负载均衡，分布式的读写分离，最后依然是拆业务，拆库，。。。逐步细化，然后每个点又可以是一组或多组机器。
&&&&特别提示：数据库层的硬件好坏也会决定访问量的多少，尤其是要考虑磁盘IO的问题，大公司往往在性价比上做文章，比如核心业务采用硬件netapp/emc及san光纤架构，对于资源数据存储，如图片视频，会采用sas或固态ssd盘，如果数据超大，可以采取热点分取分存的方法：如：最常访问的10-20%使用ssd存储，中间的20-30%采用sas盘，最后的40-50%可以采用廉价的sata。
第七层：千万级PV的站如果设计的合理一些，1，2个NFS SERVER就足够了。我所维护（兼职）或经历过的上千万PV的用NFS及普通服务器做存储的还有大把，多一些磁盘，如SAS 15K*6的，或者用dell6850，搞几组&NFS存储，中小网站足够了。当然可以做成drbd+heartbeat+nfs+a/a的方式。
&&&&如果能达到本文设计要求的，中等规模网站，后端的数据库及存储压力会非常小了。&象门户网站级别，如XX等， 会采用硬件netapp/emc等等硬件存储设备或是san光纤同道，甚至在性价比上做文章，比如核心业务采用硬件netapp/emc及san光纤架构，对于资源数据存储，如图片视频，会采用sas或固态ssd盘，如果数据超到，可以采取热点分取分存的方法：如：最常访问的10-20%使用ssd存储，中间的20-30%采用sas盘，最后的40-50%可以采用廉价的sata。
&&&&象XX等巨型公司会采用hadoop等分布式的存储架构，前端在加上多层CACHE及多及的负载均衡，同样会根据业务进行拆分，比如爬虫层存储，索引层存储，服务层存储。。。可以更细更细。。。为了应付压力，什么手段都用上了。
&&&&特殊业务，如某些SNS门户站，包括门户网站的评论，微博，大多都是异步的写入方式，即无论读写，并发访问数据库都是非常少量的。
&&&&以上1-7层，如果都搭好了，这样漏网到第四层动态服务器层的访问，就不多了。一般的中等站点，绝对不会对数据库造成太大的压力。程序层的分布式访问是从千万及PV向亿级PV的发展，当然特殊的业务 还需要特殊架构，来合理利用数据库和存储。
&&&&老男孩，资深unix/Linux系统运维网站架构专家、高级运维总监。从事一线网站运维及系统架构管理10年以上，13年的教育教学培训经历(擅长教育心理，职业规划，性格分析、谈判，职场，就业)。并将自身的网站运维架构及教育领域的经验成功结合应用到IT教育领域教学工作中。曾前后就职于若干个大规模高并发访问量的行业门户网站，并为多家互联网公司做过技术顾问，企业技术培训。提供各类网站系统架构解决方案。
&&&&老男孩linux实战培训中心是老男孩于2007年开办的国内首个linux运维实战培训私塾式精英教育培训机构。截止到2012年，累计受益学生达到千余人（其中培训VIP面授学生数百人，网络班学生数百人）。全科毕业学生平均就业工资7000以上，其中部分学生就职于淘宝、阿里巴巴、百度、腾讯、和讯、开心网、人人、激动网、小米科技、土豆、酷六、sohu、sina、金山、尚德，欢聚网、蓝港，chinacache,快网、帝联，遨游、赶集、拉手网，窝窝团、就业工场、联通、电信、乐视、乐淘、启明星辰，寻医问药，高德，360等公司。
其他活动： 1）曾为《构建高可用Linux服务器》一书做首序！ 2）曾多次受邀参加51cto,CU,it168技术活动（因兼职及培训、写书，部分未参加）。
老男孩目前从事工作： 1)&老男孩linux运维实战培训机构精英办学（面试通过方可入学）。 2）提供企业技术培训及技术顾问服务。 3）提供各种网站系统架构（数据库）解决方案。 4）提供linux技术方向企业雇员双向猎头、HR。 5）提供优质linux运维原创系列视频（初级，中级，高级）。 6）Linux网站运维从初级到高级架构的书籍写作工作。
联系方式： 网名：老男孩 QQ号:（顾问咨询）& 信箱:
培训咨询: 咨询：QQ: 33741 电话：
个人博客： （2011年度十大杰出IT博客）
个人微博： （运维思想分享地）
QQ群： 老男孩培训交流群&&246017 网站运维交流群：&518 19852 网站运维经理交流群&（非经理级别莫入）
代表作品： 老男孩浅谈如何看待运维？ 老男孩在创业及培训中28条感悟语录分享！ 批量分发管理3种简单、易用的解决方案案例视频分享& 浅谈千万级PV/IP规模高性能高并发网站架构& 老男孩linux培训某节课前考试试题及答案分享& 老男孩之学好运维四要素“坚持”的启示分享& 学会感恩会使你回报的更多--老男孩& 一道实用linux运维问题的9种shell解答方法！ Linux系统基础网络配置老鸟精华篇&
本文出自 “” 博客，请务必保留此出处
人打赏支持
码字总数 78332
支付宝支付
微信扫码支付
打赏金额: ￥
已支付成功
打赏金额: ￥浅谈web应用的负载均衡、集群、高可用(HA)解决方案 - aokunsang - ITeye技术网站
博客分类：
声明：以下仅为个人的一些总结和随写，如有不对之处，还请看到的网友指出，以免误导。 （详细的配置方案请google，这里只说解决方案。）
1、熟悉几个组件1.1、apache
—— 它是Apache软件基金会的一个开放源代码的跨平台的网页服务器，属于老牌的web服务器了，支持基于Ip或者域名的虚拟主机，支持代理服务器，支持安全Socket层(SSL)等等，目前互联网主要使用它做静态资源服务器，也可以做代理服务器转发请求(如：图片链等)，结合tomcat等servlet容器处理jsp。1.2、ngnix
—— 俄罗斯人开发的一个高性能的 HTTP和反向代理服务器。由于Nginx 超越 Apache 的高性能和稳定性，使得国内使用 Nginx 作为 Web 服务器的网站也越来越多，其中包括新浪博客、新浪播客、网易新闻、腾讯网、搜狐博客等门户网站频道等，在3w以上的高并发环境下，ngnix处理能力相当于apache的10倍。
参考：apache和tomcat的性能分析和对比(/nginx_php_v6/)1.3、lvs
—— Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。由毕业于国防科技大学的章文嵩博士于1998年5月创立，可以实现LINUX平台下的简单负载均衡。了解更多，访问官网：http://zh.linuxvirtualserver.org/。
1.4、HAProxy
—— HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点， 这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上.1.5、keepalived
—— 这里说的keepalived不是apache或者tomcat等某个组件上的属性字段，它也是一个组件，可以实现web服务器的高可用(HA high availably)。它可以检测web服务器的工作状态，如果该服务器出现故障被检测到，将其剔除服务器群中，直至正常工作后，keepalive会自动检测到并加入到服务器群里面。实现主备服务器发生故障时ip瞬时无缝交接。它是LVS集群节点健康检测的一个用户空间守护进程，也是LVS的引导故障转移模块（director failover）。Keepalived守护进程可以检查LVS池的状态。如果LVS服务器池当中的某一个服务器宕机了。keepalived会通过一 个setsockopt呼叫通知内核将这个节点从LVS拓扑图中移除。
Keepalived详解：https://my.oschina.net/piorcn/blog/4046441.6、memcached
—— 它是一个高性能分布式内存对象缓存系统。当初是Danga Interactive为了LiveJournal快速发展开发的系统，用于对业务查询数据缓存，减轻数据库的负载。其守护进程(daemon)是用C写的，但是客户端支持几乎所有语言(客户端基本上有3种版本[memcxMecache])，服务端和客户端通过简单的协议通信；在memcached里面缓存的数据必须序列化。1.7、terracotta
—— 是一款由美国Terracotta公司开发的著名开源Java集群平台。它在JVM与Java应用之间实现了一个专门处理集群功能的抽象层，允许用户在不改变系统代码的情况下实现java应用的集群。支持数据的持久化、session的复制以及高可用(HA)。详细参考：/blog/19116792、关键术语2.1、负载均衡（load balance） 在互联网高速发展的时代，大数据量、高并发等是互联网网站提及最多的。如何处理高并发带来的系统性能问题，最终大家都会使用负载均衡机制。它是根据某种负载策略把请求分发到集群中的每一台服务器上，让整个服务器群来处理网站的请求。公司比较有钱的，可以购买专门负责负载均衡的硬件（如：F5）,效果肯定会很好。对于大部分公司，会选择廉价有效的方法扩展整个系统的架构，来增加服务器的吞吐量和处理能力，以及承载能力。2.2、集群（Cluster） 用N台服务器构成一个松耦合的多处理器系统(对外来说，他们就是一个服务器)，它们之间通过网络实现通信。让N台服务器之间相互协作，共同承载一个网站的请求压力。2.3、高可用（HA） 在集群服务器架构中，当主服务器故障时，备份服务器能够自动接管主服务器的工作，并及时切换过去，以实现对用户的不间断服务。ps：这里我感觉它跟故障转移(failover)是一个意思，看到的网友给个解释，谢谢？2.4、session复制/共享 在访问系统的会话过程中，用户登录系统后，不管访问系统的任何资源地址都不需要重复登录，这里面servlet容易保存了该用户的会话(session)。如果两个tomcat(A、B)提供集群服务时候，用户在A-tomcat上登录，接下来的请求web服务器根据策略分发到B-tomcat，因为B-tomcat没有保存用户的会话(session)信息，不知道其登录，会跳转到登录界面。这时候我们需要让B-tomcat也保存有A-tomcat的会话，我们可以使用tomcat的session复制实现或者通过其他手段让session共享。
3、常用web集群3.1、tomcat集群方案 apache+tomcat；ngnix+tomcat；lvs+ngnix+tomcat；大家比较熟悉的是前两种。(lvs负责集群调度，nginx负责静态文件处理，tomcat负责动态文件处理[最优选择])。 以apache+tomcat集群为例，简单说一下：
1、他们之间的通信有三种方式：ajp_proxy、mod_jk链接器、http_proxy。具体参考：/developerworks/cn/opensource/os-lo-apache-tomcat/
2、apache的分发策略有4种。权重(默认)、流量(bytraffic)、请求次数(byRequests)、繁忙程度(byBusyness根据活跃请求数的多少)
3、apache支持stickysession(粘性session)，即为：访问用户访问了A-tomcat，那么他的所有请求都会转发到A-tomcat，而不会到B-tomcat。[这样的负载均衡效果不好，适用于小型网站，下面说非粘性session]
4、它们之间的架构如图1：
问题1：只有一个web服务器，明显的单点故障。如果该apache出现问题，整个网站就会瘫痪。
3.2、session复制
如果不采用stickysession(粘性session)，那么我们可以采用tomcat的session复制使所有节点tomcat的会话相同，tomcat使用组播技术，只要集群中一个tomcat节点的session发生改变，会广播通知所有tomcat节点发生改变。问题2：据网友测试，当tomcat节点数达到4个以上时候，集群性能呈线性下滑；另外当用户访问量大到一定程度，会话内容随之增多，tomcat节点相互之间通信产生大量的网络消耗，产生网络阻塞，整个集群的吞吐量不能再上升。
4、高可用(HA)和session共享(解决上面提到的两个问题)
4.1、使用lvs+keepalive实现集群高可用，达到更健壮的LB 我们可以做前端使用lvs来做负载均衡，根据lvs的8种调度算法(可设置)，分发请求到对应的web服务器集群上。lvs做双机热备，通过keepalived模块能够达到故障自动转移到备份服务器，不间断提供服务，结构如图2：
说明：据查询了解，一般在WEB端使用的负载均衡比较多的是HAProxy+keepalived+nginx；数据库mysql集群使用Lvs+keepalived+mysql实现。因为HAProxy和nginx一样是工作在网络7层之上，并且前者弥补了nginx的一些缺点如session的保持，cookie的引导等，且它本身是个负责均衡软件，处理负载均衡上面必然优于nginx；lvs比较笨重，对于比较庞大的网络应用实施比较复杂，虽然它运行在网络4层之上，仅做分发没有流量产生，但是它不能做正则处理也不能也不能做动静分离，所以一般用lvs+keepalived或heatbeat做数据库层的负载均衡。
4.2、使用terracotta或者memcached使session共享
4.2.1、terracotta是jvm级别的session共享
它基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta只把变化的部分发送给Terracotta服务器，然后由服务器把它转发给真正需要这个数据的节点，并且共享的数据对象不需要序列化。
4.2.2、通过memcached实现内存级session共享
通过memcached-session-manager（msm）插件，通过tomcat上一定的配置，即可实现把session存储到memcached服务器上。注意：tomcat支持tomcat6+，并且memcached可以支持分布式内存，msm同时支持黏性session（sticky sessions）或者非黏性session（non-sticky sessions）两种模式，在memcached内存中共享的对象需要序列化。结构如图3：
通过一定的配置，可以实现故障转移(只支持对非粘性session)。如：
&Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1::1211"
failoverNodes="n1"
requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
&/Context&
说明：failoverNodes：故障转移节点，对非粘性session不可用。属性failoverNodes="n1"的作用是告诉msm最好是把session保存在memcached "n2"节点上，只有在n2节点不可用的情况下才把session保存在n1节点。这样即使host2上的tomcat宕机，仍然可以通过host1上的tomcat访问存放在memcached "n1" 节点中的session。 4.2.3、其他方案通过cookie保存用户信息(一般是登录信息)，每一个请求到达web应用的时候，web应用从cookie中取出数据进行处理（这里尽量对cookie做加密处理）；另外一种是把用户信息的关键属性保存到数据库，这样就不需要session了。请求过来从数据库查询关键属性数据，做相应处理。缺点：加大了数据库的负载，使数据库成为集群的瓶颈。
下篇再讨论，。
浏览 72998
浏览: 540085 次
来自: 北京
不错，谢谢分享！推荐个参考视频内容：http://www.ro ...
完全正确，补充一下&beans:bean id=&quo ...
longToip直接用ipToLong反过来就好了 publi ...
[size=x-small]jatoolsPrinter还有破 ...16406人阅读
Web&分布式架构（22）
负载均衡(Load Balance)是集群技术（Cluster）的一种应用。负载均衡可以将工作任务分摊到多个处理单元，从而提高并发处理能力。目前最常见的负载均衡应用是Web负载均衡。根据实现的原理不同，常见的web负载均衡技术包括：DNS轮询、IP负载均衡和CDN。其中IP负载均衡可以使用硬件设备或软件方式来实现。
什么是web负载均衡
服务器集群(Cluster)使得多个服务器节点能够协同工作，根据目的的不同，服务器集群可以分为：
高性能集群：将单个重负载的请求分散到多个节点进行处理，最后再将处理结果进行汇总高可用集群：提高冗余单元，避免单点故障负载均衡集群：将大量的并发请求分担到多个处理节点。由于单个处理节点的故障不影响整个服务，负载均衡集群同时也实现了高可用性。
一般提到的负载均衡(Load Balance)，是指实现负载均衡集群。负载均衡实现了横向扩展（Scale Out），避免纵向的升级（Scale Up）换代。
本文中的web负载均衡，特指能够分担web请求（http，https等）的负载均衡技术。
任何的负载均衡技术都要想办法建立某种一对多的映射机制：一个请求的入口映射到多个处理请求的节点，从而实现分而治之（Divide and Conquer）。
这种映射机制使得多个物理存在对外体现为一个虚拟的整体，对服务的请求者屏蔽了内部的结构。
采用不同的机制建立映射关系，可以形成不同的负载均衡技术，常见的包括：
DNS轮询CDNIP负载均衡
DNS轮询是最简单的负载均衡方式。以域名作为访问入口，通过配置多条DNS A记录使得请求可以分配到不同的服务器。
DNS轮询没有快速的健康检查机制，而且只支持WRR的调度策略导致负载很难“均衡”，通常用于要求不高的场景。并且DNS轮询方式直接将服务器的真实地址暴露给用户，不利于服务器安全。
CDN（Content Delivery Network，内容分发网络）。通过发布机制将内容同步到大量的缓存节点，并在DNS服务器上进行扩展，找到里用户最近的缓存节点作为服务提供节点。
因为很难自建大量的缓存节点，所以通常使用CDN运营商的服务。目前国内的服务商很少，而且按流量计费，价&#26684;也比较昂贵。
IP负载均衡
IP负载均衡是基于特定的TCP/IP技术实现的负载均衡。比如NAT、DR、Turning等。是最经常使用的方式。关于其原理，可以参考下面另一篇文章：。
IP负载均衡可以使用硬件设备，也可以使用软件实现。硬件设备的主要产品是F5-BIG-IP-GTM（简称F5)，软件产品主要有LVS、HAProxy、NginX。其中LVS、HAProxy可以工作在4-7层，NginX工作在7层。关于三者的简单对比，可以参考。
硬件负载均衡设备可以将核心部分做成芯片，性能和稳定性更好，而且商用产品的可管理性、文档和服务都比较好。唯一的问题就是价&#26684;。
软件负载均衡通常是开源软件。自由度较高，但学习成本和管理成本会比较大。
F5的全称是F5-BIG-IP-GTM，是最流行的硬件负载均衡设备，其并发能力达到百万级。F5的主要特性包括：
多链路的负载均衡和冗余
可以接入多条ISP链路，在链路之间实现负载均衡和高可用。
防火墙负载均衡
F5具有异构防火墙的负载均衡与故障自动排除能力。
服务器负载均衡
这是F5最主要的功能，F5可以配置针对所有的对外提供服务的服务器配置Virtual Server实现负载均衡、健康检查、回话保持等。
F5设备自身的冗余设计能够保证99.999%的正常运行时间，双机F5的故障切换时间为毫秒级。
使用F5可以配置整个集群的链路冗余和服务器冗余，提高可靠的健康检查机制，以保证高可用。
与防火墙类&#20284;，F5采用缺省拒绝策略，可以为任何站点增加额外的安全保护，防御普通网络攻击，包括DDoS、IP欺骗、SYN攻击、teartop和land攻击、ICMP攻击等。
F5提供HTTPS、SSH、Telnet、SNMP等多种管理方式，包含详尽的实时报告和历史纪录报告。同时还提供二次开发包(i-Control)。
F5还提供了SSL加速、软件升级、IP地址过滤、带宽控制等辅助功能。
LVS(Linux Virtual Server, Linux虚拟服务器），是开发的开放软件，目前已经集成到Linux内核中。
基于不同的网络技术，LVS支持多种负载均衡机制。包括：VS/NAT（基于网络地址转换技术）、VS/TUN（基于IP隧道技术）和VS/DR（基于直接路由技术）。
此外，为了适应不同的需要，淘宝开发了，从本质上来说也是基于网络地址转换技术。最近还有一个基于VS/FULLNAT的模块。
不管使用哪种机制，LVS都不直接处理请求，而是将请求转发到后面真正的服务器(Real Server)。不同的机制，决定了响应包如何返回到客户端。
也叫做网络掩蔽或者IP掩蔽，是将IP 数据包头中的IP 地址转换为另一个IP 地址的过程。
NAT能够将私有（保留）地址转化为合法IP地址，通常用于一个公共IP地址和多个内部私有IP地址直接的映射，广泛应用于各种类型Internet接入方式和各种类型的网络中。
通过使用NAT将目的地址转换到多个服务器的方式，可以实现负载均衡，同时能够隐藏并保护内部服务器，避免来自网络外部的攻击。商用负载均衡设备如Cisco的LocalDirector、F5的Big/IP和Alteon的ACEDirector都是基于NAT方法。
VS/NAT(Virtual Server via Network Address Translation)是基于NAT技术实现负载均衡的方法。其架构如下图所示：
客户通过Virtual IP Address（虚拟服务的IP地址）访问网络服务时，请求报文到达调度器
调度器根据连接调度算法从一组真实服务器中选出一台服务器，将报文的目标地址Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将修改后的报文发送给选出的服务器。
真实的服务器处理请求，并将响应报文发到调度器。
调度器将报文的源地址和源端口改为Virtual IP Address和相应的端口调度器将修改过的报文发给用户
在VS/NAT的集群系统中，请求和响应的数据报文都需要通过负载调度器，当真实服务器的数目在10台和20台之间时，负载调度器将成为整个集群系统的新瓶颈。大多数Internet服务都有这样的特点：请求报文较短而响应报文往往包含大量的数据。如果能将请求和响应分开处理，即在负载调度器中只负责调度请求而响应直接返回给客户，将极大地提高整个集群系统的吞吐量。比如IP隧道技术。
，又称为IP封装技术(IP encapsulation)，是一种在网络之间传递数据的方式。可以将一个IP报文封装到另一个IP报文（可能是不同的协议）中，并转发到另一个IP地址。IP隧道主要用于移动主机和虚拟私有网络（Virtual Private Network），在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的IP地址。
VS/TUN（Virtual Server via IP Tunneling）是基于隧道技术实现负载均衡的方法。其架构如下图所示：
VS/TUN与VS/NAT的工作机制大体上相同，区别在于：
调度器转发报文的时候进行了协议的二次封装，真实的服务器接收到请求后先进行解包。过程如下图所示：
响应报文从后端服务器直接返回给客户，不需要经过调度器。
, 路由器学习路由的方法之一。路由器对于自己的网络接口所直连的网络之间的通信，可以自动维护路由表，而且不需要进行路由计算。
直接路由通常用在一个三层交换机连接几个VLAN的情况，只要设置直接路由VLAN之间就可以通信，不需要设置其他的路由方式。
VS/DR(Virtual Server via Direct Routing)是基于直接路由实现负载均衡的方法。其架构如下图所示：
跟VS/TUN方法相同，VS/DR利用大多数Internet服务的非对称特点，负载调度器中只负责调度请求，而服务器直接将响应返回给客户，可以极大地提高整个集群系统的吞吐量。
VS/DR要求调度器和服务器组都必须在物理上有一个网卡通过不分段的局域网相连，即通过交换机或者高速的HUB相连，中间没有隔有路由器。VIP地址为调度器和服务器组共享，调度器配置的VIP地址是对外可见的，用于接收虚拟服务的请求报文；所有的服务器把VIP地址配置在各自的Non-ARP网络设备上，它对外面是不可见的，只是用于处理目标地址为VIP的网络请求。
VS/DR的整个过程与VS/TUN非常类&#20284;，不同之处在于调度器不对请求包进行二次封装，只是将目标MAC地址更改为经过调度算法选出的目标服务器的MAC地址。如下图：
三种方法的优缺点比较
对后端服务器的操作系统无要求只需要一个IP地址配置在调度器上，服务器组可以用私有的IP地址。支持端口映射
请求和响应报文都需要通过调度器，伸缩能力有限（10&#43;)要求服务器和调度器在同一个VLAN需要将服务器的默认网关指向调度器对于那些将IP地址或者端口号在报文数据中传送的网络服务，需要编写相应的应用模块来转换报文数据中的IP地址或者端口号
不需要调度应答报文，性能高服务器和调度器可以不在同一个VLAN支持广域负载均衡
所有的服务器必须支持“IP Tunneling”协议，要安装内核模块（比如IPIP等），配置复杂有建立IP隧道的开销服务器上直接绑定虚拟IP(Virtaul IP)，风险很大服务器需要联通外网不支持端口映射
与VS/TUN相比，没有IP隧道的开销，性能最好
要求调度器与服务器都有一块网卡连在同一物理网段（同一个VLAN）上要求服务器网络设备（或者设备别名）不作ARP响应，或者能将报文重定向（Redirect）到本地的Socket端口上服务器上直接绑定虚拟IP(Virtaul IP)，风险很大不支持端口映射
VS/FULLNAT
如上节所述，前面三种传统的负载均衡机制各自存在一些不足。
是为了解决这些不足而新开发的一种转发模式。VS/FULLNAT的特点是：
调度器和服务器可以跨VLAN通信，不需要配置在同一个网段请求和应答报文都经过调度器，服务器不需要绑定虚拟IP
VS/FULLNAT这两个特点可以简化网络拓扑，降低运维成本和风险。
如果人少钱多，不在乎性能的损耗愿意多买服务器，同时希望最大程度较少运维的工作量，可以选择FULLNAT很大众的方式是用DR，没有太多的优点但也没有太多的缺点如果要搞广域网负载均衡，那就用TUN吧个人感觉NAT不是为了互联网用的。小并发的实验性应用或者用在非web场合，比如mysql集群等。当然，如果需要端口映射，必须使用NAT方式
本文转自：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1221406次
积分：13703
积分：13703
排名：第739名
原创：162篇
转载：82篇
译文：70篇
评论：172条
(1)(1)(6)(1)(20)(20)(18)(24)(2)(8)(13)(3)(5)(11)(13)(1)(2)(3)(1)(8)(4)(2)(5)(7)(3)(6)(3)(2)(3)(2)(5)(1)(8)(1)(4)(3)(1)(6)(4)(18)(18)(9)(26)(13)}