网站开发的学习交流 -- 系统架构 -- 负载均衡

网站开发的学习交流

自己水平有限，希望大家能批判指导，谢谢。

文章中引用的互联网上的资料的链接放在文章最下面。

一、系统架构：

构建高并发高负载的大型网站一般需要注意一下几个方面：

1、负载均衡：负载均衡（又称为负载分担），英文名称为Load Balance

负载均衡分为两类：

1.1、软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡，如DNS Load Balance，lvs,nginx等，它的优点是基于特定环境，配置简单，使用灵活，成本低廉，可以满足一般的负载均衡需求。

　　软件解决方案缺点也较多，因为每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，所以当连接请求特别大的时候，软件本身会成为服务器工作成败的一个关键。

1.2、硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。

　　一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。如：F5。

=========================begin：DNS Load Balance==============================

详细解释：
最早使用的负载均衡技术是通过DNS服务中的随机名字解析来实现的。这就是通常所说的DNS负载均衡技术。
　　DNS负载均衡技术的实现原理是在DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。

优点：　
　　第一，技术实现比较灵活、方便，简单易行，成本低，适用于大多数TCP/IP应用。不需要网络专家来对之进行设定，或在出现问题时对之进行维护。
　　第二，对于Web应用来说，不需要对代码作任何的修改。事实上，Web应用本身并不会意识到负载均衡配置，即使在它面前。
　　第三，Web服务器可以位于互联网的任意位置上。
缺点：　　
　　第一，不能够按照Web服务器的处理能力分配负载。DNS负载均衡采用的是简单的轮循负载算法，不能区分服务器之间的差异，不能反映服务器的当前运行状态。所以DNS服务器将Http请求平均地分配到后台的Web服务器上，而不考虑每个Web服务器当前的负载情况。如果后台的Web服务器的配置和处理能力不同，最慢的 Web服务器将成为系统的瓶颈，处理能力强的服务器不能充分发挥作用。
　　第二，不支持高可靠性，DNS负载均衡技术没有考虑容错。如果后台的某台Web服务器出现故障，DNS服务器仍然会把DNS 请求分配到这台故障服务器上，导致不能响应客户端。
　　第三，可能会造成额外的网络问题。为了使本DNS服务器和其他DNS服务器及时交互，保证DNS数据及时更新，使地址能随机分配，一般都要将DNS的刷新时间设置的较小，但太小将会使DNS流量大增造成额外的网络问题。
　　第四，一旦某个服务器出现故障，即使及时修改了DNS设置，还是要等待足够的时间(刷新时间)才能发挥作用，在此期间，保存了故障服务器地址的客户计算机将不能正常访问服务器。
　

现在很多Web站点方案中，已经很少采用这种方案了。

=========================end：DNS Load Balance==============================

=========================begin：LVS + Nginx=================================

一、lvs的优势：

1、抗负载能力强，而且工作在网络4层仅做请求分发之用，没有流量，所以在效率上基本不需要太过考虑。
2、配置性低，这通常是一大劣势，但同时也是一大优势，因为没有太多可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率。
3、工作稳定，因为其本身抗负载能力很强，所以稳定性高也是顺理成章，另外各种lvs都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，lvs会自动判别，所以系统整体是非常稳定的。
4、lvs仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。
5、基本上能支持所有应用，因为lvs工作在4层，所以它可以对几乎所有应用做负载均衡，包括http、数据库、聊天室等等。
另：lvs也不是完全能判别节点故障的，譬如在wlc分配方式下，集群里有一个节点没有配置VIP，会使整个集群不能使用，这时使用wrr分配方式则会丢掉一台机。目前这个问题还在进一步测试中。所以，用lvs也得多多当心为妙。

二、nginx和lvs作对比的结果

1、nginx工作在网络的7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下lvs并不具备这样的功能，所以nginx单凭这点可利用的场合就远多于lvs了；但nginx有用的这些功能使其可调整度要高于lvs，所以经常要去触碰触碰，由lvs的第2条优点看，触碰多了，人为出问题的几率也就会大。
2、nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路
3、nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。lvs的安装和配置、测试就要花比较长的时间了，因为同上所述，lvs对网络依赖比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。
4、nginx也同样能承受很高负载且稳定，但负载度和稳定度差lvs还有几个等级：nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的；nginx没有现成的双机热备方案，所以跑在单机上还是风险较大。
5、nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前lvs也能支持针对服务器内部的情况来监控，但不能重发请求。重发请求这点，譬如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，nginx会把上传切到另一台服务器重新处理，而lvs就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而恼火。
6、nginx能支持http和email（email的功能估计比较少人用），lvs所支持的应用在这点上会比nginx更多。

在使用上，一般最前端所采取的策略应是lvs，也就是DNS的指向应为lvs均衡器，lvs的优点令它非常适合做这个任务。

重要的ip地址，最好交由lvs托管，比如数据库的ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给lvs托管是最为稳妥的。

nginx可作为lvs节点机器使用，一是可以利用nginx的功能，二是可以利用nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比nginx弱不少了，性能上也有所逊色于nginx。

具体的应用还得具体分析，如果是比较小的网站（日PV<1000万），用nginx就完全可以了，如果机器也不少，可以用DNS轮询，lvs所耗费的机器还是比较多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用lvs。

=========================end：LVS + Nginx=================================

=========================begin：Nginx+squid=================================

LVS-->squid前端缓存-->NGINX中层代理



在后端服务器中模拟url hash的算法来找到内容所在的squid，提高了命中率。

Nginx和squid的配置放到文章最后的附件里。

=========================end：Nginx+squid=================================

借鉴URL路径：

/article/1670379.html

http://hi.baidu.com/wrjgg/blog/item/80efc00348c5516403088139.html

http://sudone.com/nginx/nginx_vs_lvs.html

http://hi.baidu.com/tianhuimin/item/cfe68df75e77c40dd99e724f

http://www.fovweb.com/web/nginx-and-squid.html

http://wenku.baidu.com/view/67952e66f5335a8102d220bf.html

附件：

=========================begin：Nginx配置详解=================================

/article/5025885.html

http://www.cnblogs.com/cenly/archive/2008/12/12/1353799.html

=========================end：Nginx配置详解=================================

=========================begin：Nginx squid 配置=================================

http://anerg.com/read.php?43

squid的

cache_effective_user www-data cache_effective_group www-data http_port 127.0.0.1:88 accel vhost vport cache_peer 60.28.216.8 parent 80 0 no-query originserver forceddomain=www.iciba.com name=webServer1 cache_peer_domain webServer1 iciba.local acl localhost src 127.0.0.1/255.255.255.255 http_access allow localhost http_access deny all cache_mgr luochong@kingsoft.com cache_dir ufs /data/squid 1000 16 256 cache_mem 128 MB maximum_object_size_in_memory 512 KB max_open_disk_fds 0 KB minimum_object_size 0 KB maximum_object_size 4096 KB cache_swap_low 90 cache_swap_high 95 cache_access_log /data/logs/squid/access.log cache_log /data/logs/squid/cache.log cache_store_log /data/logs/squid/store.log visible_hostname No1.proxy refresh_pattern -i . 1440 50% 2880 ignore-reload
与之配合的nginx的

upstream iciba_local { ip_hash; server 127.0.0.1:88; }
server { listen 80; server_name iciba.local;
#access_log /var/log/nginx/localhost.access.log;
location / { proxy_pass http://iciba_local; proxy_redirect off; proxy_set_header Host $host:80; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }
=========================end：Nginx squid 配置=================================