点点滴滴

如果你有一个很受欢迎的Web站点，你会发现当请求的连接数增加时，服务器的响应延时也会随之增加。虽然你可以增加RAM、升级处理器、使用更快的驱动器及总线,这在短期内会有一定的帮助，但最终会发现一台服务器无法完成需要的任务。
 
使用多台服务器平衡负载是一个不错的想法，你可以在你的服务器池中随意增加多台服务器来提高服务器的性能和增强网络的稳定性。如果你的服务器池中有多台服务器，当一台down机后，其他服务器可以接替它的工作，继续提供服务而不至于造成服务中断。
 
通过使用RR-DNS（Round-Robin Domain Name System）可以实现平衡负载的功能，向一个主机名发出的入站请求可以被转发到多个IP地址上。
 

 
在BIND9中实现此功能就向添加一条A记录那么简单。举例说，如果我们向somode.com区域文件中加入下面行便可实现：
www       60     IN     A       220.181.11.124
          60     IN     A       220.181.11.125
 
当然你还可以根据需要加入更多服务器。这样如果有人请求解析[url]www.somode.com[/url]时将有一半的机率解析到220.181.11.124上，而另一半会解析到220.181.11.125上。
 
然而，使用RR-DNS方法实现负载平衡也会带来一些问题：
第一，域名服务器是一个分布式系统，是按照一定的层次结构组织的。当用户将域名解析请求提交给本地的域名服务器，它会因不能直接解析而向上一级域名服务器提交，上一级域名服务器再依次向上提交，直到RR-DNS 域名服务器把这个域名解析到其中一台服务器的IP 地址。可见，从用户到RR-DNS 间存在多台域名服务器，而它们都会缓冲已解析的名字到IP 地址的映射,这会导致该域名服务器组下所有用户都会访问同一Web 服务器，出现不同Web 服务器间的负载不平衡。为了保证在域名服务器中域名到IP 地址的映射不被长久缓冲，RR-DNS 在域名到IP 地址的映射上设置一个TTL(Time To Live)值，过了这一段时间，域名服务器将这个映射从缓冲中淘汰。当用户请求，它会再向上一级域名服务器提交请求并进行重新映射。这就涉及到如何设置这个TTL值，若这个值太大，在这个TTL 期间，很多请求会被映射到同一台Web 服务器上，同样会导致负载不平衡。若这个值太小，例如是０，会导致本地域名服务器频繁地向RR-DNS提交请求，增加了域名解析的网络流量，同样会使RR-DNS 成为系统中一个新的瓶颈。
 
第二，用户机器会缓冲从名字到IP 地址的映射，而不受TTL 值的影响，用户的访问请求会被送到同一台Web 服务器上。由于用户访问请求的突发性和访问方式不同，例如有的人访问一下就离开了，而有的人访问可长达几个小时，所以各台服务器间的负载仍存在倾斜（Skew）而不能控制。假设用户在每个会话中平均请求数为20，负载最大的服务器获得的请求数额高于各服务器平均请求数的平均比率超过百分之三十。也就是说，当TTL 值为0 时，因为用户访问的突发性也会存在着较严重的负载不平衡。
 
第三，系统的可靠性和可维护性不好。若一台服务器失效，会导致将域名解析到该服务器的用户看到服务中断，即使用户按“Reload”按钮，也无济于事。系统管理员也不能随时地将一台服务器切出服务进行维护，如进行操作系统和应用软件升级，这需要修改RR-DNS 服务器中的IP 地址列表，把该服务器的IP 地址从中划掉，然后等上一段时间，等所有域名服务器将该域名到这台服务器的映射淘汰，和所有映射到这台服务器的客户机不再使用该站点为止。
 
RR-DNS方法只是一个简单的负载平衡方案，如果你有更高要求，可以研究LVS集群（IPVS和KTCPVS、TCPHA），实现基于IP的负载均衡和基于内容的负载均衡。