lizongbo at 618119.com 工作,生活,Android,前端,Linode,Ubuntu,nginx,java,apache,tomcat,Resin,mina,Hessian,XMPP,RPC

2008年01月29日

关于分布式负载均衡的几个设置

Filed under: DNS,JavaScript — 标签:, , , — lizongbo @ 08:38

服务器对外的展现要统一,简洁。
即用户在URL里看到的地址是很方便记忆的。

而对于页面中嵌入的图片,脚本,样式表,视频,音频等文件,则可以放在其它服务器上。

第一层: DNS记录轮询负载均衡
www.google.com为例进行分析
1.首先是将 www.google.com,指定多个cname,根据不同的网络线路请求得到不同的别名

比如在中国得到的别名为:www.l.google.com,
www.l.google.com 的别名为: www-china.l.google.com

www-china.l.google.com再指定多个ip的a记录,
例如 ip 64.233.189.99, 64.233.189.104,64.233.167.147.

99,104,147这三个ip分别实现ip别名绑定,即如果99这个ip挂了,104会自动接管该ip到本机。

通过这样的方式,保证用户最终访问到的ip始终在线。

在cname解析的地方,可以使用多层cname解析,以实现更细粒度的负载均衡并灵活切换。

假设当www-china.l.google.com下整个节点都断网了,则只需要将www.l.google.com指向www-usa.l.google.com这样就可以切换了。

(纯属猜测:指定了cname的域名,则不要再配置a记录,因为a记录的优先级比cname高。)

dns解析过程记录如下:

[code]
E:\>nslookup
request timed out.
timeout was 2 seconds.
*** Can’t find server name for address 192.168.18.1: Timed out
*** Default servers are not available
Default Server:  UnKnown
Address:  192.168.18.1

> server 202.96.128.86
DNS request timed out.
timeout was 2 seconds.
Default Server:  [202.96.128.86]
Address:  202.96.128.86

> server 202.96.128.86
Default Server:  cache-a.guangzhou.gd.cn
Address:  202.96.128.86

> set q=cname
> www.google.com
Server:  cache-a.guangzhou.gd.cn
Address:  202.96.128.86

Non-authoritative answer:
www.google.com  canonical name = www.l.google.com
> www.l.google.com
Server:  cache-a.guangzhou.gd.cn
Address:  202.96.128.86

Non-authoritative answer:
www.l.google.com        canonical name = www-china.l.google.com
> www-china.l.google.com
Server:  cache-a.guangzhou.gd.cn
Address:  202.96.128.86

l.google.com
primary name server = f.l.google.com
responsible mail addr = dns-admin.google.com
serial  = 1331146
refresh = 900 (15 mins)
retry   = 900 (15 mins)
expire  = 1800 (30 mins)
default TTL = 60 (1 min)
> set q=a
> www-china.l.google.com
Server:  cache-a.guangzhou.gd.cn
Address:  202.96.128.86

Non-authoritative answer:
Name:    www-china.l.google.com
Addresses:  64.233.189.99, 64.233.189.104

[/code]

(也可用这个命令查询: dig @202.96.128.86 www.google.com +trace)

第二层,服务端请求分发。

前端的ip得到客户端的请求,并不是在本机进行业务逻辑处理,而是对请求进行初步解析过滤,再分发给其它服务器进行处理,
请求分发规则通常是基于url的,也可根据其它附加条件进行分发,例如GET/POST,user-Agent,remoteAddr,urlhash等。

第三层:客户端分发请求。

通常用于对图片资源的请求进行分发,按找浏览器的默认限制,对同一服务器的并发连接不超过2个,
因此,假设一个网页里要显示40张图片,而这40张图片,如果使用同一个域名的话,及时后台做了请求分发,
而受浏览器的限制,假设一秒中下载两张图,打开这40张图片,也需要20秒,

而在采取客户端分发请求的模式,将图片的链接自动分布的请求到远程多台服务器,那么以同时请求5台为例,则相当于将对网站的并发请求提高了 5倍,
获得了了10个并发请求。
不光是图片资源,其它资源也都可以采取这种模式,url的动态分布,可以在服务端生成html代码的时候完成,
也可以在html的Javascript中预先存放一个可用服务器列表

www.flickr.com为例:

http://farm1.static.flickr.com/
http://farm2.static.flickr.com/
http://farm3.static.flickr.com/
……
http://farmx.static.flickr.com/

没有评论 »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress