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

2008年12月28日

service集群的快速失败转移策略选择

Filed under: Cluster — 标签: — lizongbo @ 02:13

前提,Service是多个,数组方式存在,hashcode取模方式负载均衡,
当某个 service出现故障时的快速失败转移策略。
1.N+1模式,
N个正常运行的service,1个备份service。
类似心跳检测,当某个service的方法无法调用时,
从数组中将其替换为备份是service,是n对1模式,
优点是替换简便,缺点是始终留一个冷备。
如果同时坏两个的时候不好处理。
还有切换之后待故障service恢复之后的切换回。
可以采取类似浮动ip模式以抢ip的方式来进行切换。

2.rehash

N个正常运行的Service.无备份。
类似心跳检测,当某个service的方法无法调用时。
将按qq取模落在该service上的请求,重新hash,
将其分散到另外N-1个Service上。
如果再坏一个,就rehash到剩下的N-2个。

缺点是算法复杂,优点是无需冷备。不浪费资源

2008年04月8日

Openfire 3.5.0正式发布,Openfire Enterprise也将开源

Filed under: Cluster,IM,Openfire,Spark,XMPP,未分类 — 标签:, , , , , — lizongbo @ 12:48

Openfire 3.5.0正式发布,Openfire Enterprise也将开源

openfire 3.5 的 修订日志在: http://www.igniterealtime.org/builds/openfire/docs/latest/changelog.html
相关下载地址:

http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire_3_5_0.zip

http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire_src_3_5_0.zip

Openfire Enterprise下载
http://www.igniterealtime.org/projects/openfire/plugins/enterprise.jar
http://www.igniterealtime.org/projects/openfire/plugins/webchat.war

其它插件下载:

http://www.igniterealtime.org/projects/openfire/plugins/asterisk-im.jar
http://www.igniterealtime.org/projects/openfire/plugins/broadcast.jar
http://www.igniterealtime.org/projects/openfire/plugins/contentFilter.jar
http://www.igniterealtime.org/projects/openfire/plugins/emailListener.jar
http://www.igniterealtime.org/projects/openfire/plugins/gateway.jar
http://www.igniterealtime.org/projects/openfire/plugins/motd.jar
http://www.igniterealtime.org/projects/openfire/plugins/presence.jar
http://www.igniterealtime.org/projects/openfire/plugins/registration.jar
http://www.igniterealtime.org/projects/openfire/plugins/search.jar
http://www.igniterealtime.org/projects/openfire/plugins/sip.jar
http://www.igniterealtime.org/projects/openfire/plugins/subscription.jar
http://www.igniterealtime.org/projects/openfire/plugins/userImportExport.jar
http://www.igniterealtime.org/projects/openfire/plugins/userservice.jar
http://www.igniterealtime.org/projects/openfire/plugins/enterprise.jar

Openfire Enterprise以前是作为商业插件提供的,现在也将变成开源。相关文章:
http://www.igniterealtime.org/community/blogs/ignite/2008/04/07/openfire-is-lookin-hot

http://www.igniterealtime.org/community/blogs/ignite/2008/04/07/openfire-enterprise-is-becoming-open-source

http://www.igniterealtime.org/community/blogs/ignite/2008/04/07/turning-openfire-enterprise-into-an-open-source-product

目前在官方网站尚未看到 Openfire Enterprise的代码 http://svn.igniterealtime.org/svn/repos/

由于Openfire Enterprise是使用了Oracle Coherence来实现集群功能,
而Oracle Coherence是被Oracle收购的Tangosol Coherence,是商业产品。因此Openfire Enterprise的集群功能不会开源。

关于Oracle Coherence,可以参看: http://www.oracle.com/technology/global/cn/products/coherence/index.html

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
DNS 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/

Older Posts »

Powered by WordPress