什么是集群呢?总的来说,集群包括两个概念:“负载均衡”(load balancing)和“ 失败接管 ”(failover)
多个客户端同时发出请求,位于前端的负载均衡器根据特定算法,将请求分担给比较空闲的机器,从而实现较高性能和较好的扩展性
当客户端连续向某个服务器发出请求时,该服务器可能处理到一半就宕机了,失败接管系统能够检测出有问题的服务器,将后续的请求转发至其他可用的机器,从而实现容错功能
那么,哪些对象可以被集群呢,答案是:“可以被部署在分布式拓扑的组件 ”
因此,负载均衡和失败接管会发生在哪些 J2EE代码中呢?“仅当你调用分布式对象的方法时 ”
客户端和目标服务器不在一个 JVM上,他们之间通过标准的网络协议进行通讯,这也就给集群提供了用武之地,实现集群效果的设备可以放在边界上对通讯做一些处理。
J2EE的分布式技术包括: JSP,JDBC,EJB,JNDI,WEB SERVICE等等
一. Web层的集群实现
这是最重要最基本的 J2EE集群功能,网络层集群技术包括:Web负载均衡和HTTPSession失败接管
Web负载均衡
负载均衡器可以是一个硬件设备,比如 F5 Load Balancer,也可以是另外一台服务器加一个负载均衡的插件,甚至一个 Linux的嵌入式设备都能胜任。通常,负载均衡包括以下几个特点:
1.实现负载均衡算法
常用的算法有: Round-Robin, Random 和 Weight Based,算法的最终目标是尽量使每台服务器的负载达到平衡,但以上算法只是根据每台服务器接收的请求来进行均衡,因此都不能完全达到理想化的目标。有 些复杂的算法可以在分发请求之前检测机器的性能,从而决定要由哪台机器来处理请求。
2.健康监测
一旦某台机器宕机了,负载均衡器要能够及时发现情况,并且将请求转交给其他可用的服务器,保证做到“ failover”
3.Session stickiness
即是让一次 session会话的请求都尽量交给一台机器处理,这样省去了服务器之间交换 session数据的开销
HTTPSession失败接管
当session进行到一半时,如果服务器挂了,我们就要想办法让session在另外一台机器上继续进行,而不是让用户重新来过。下面图六解释 了实现HTTPSession Failover的原理:每次的session都会分配一个唯一的id,这个id以cookies的形式存放在客户端中,负载均衡器通过id分辨请求是属 于哪个session的。在第四步中,服务器 A以某种定义好的方式,定期将 session数据保存起来,一旦出问题,负载均衡器会自动通知另一台服务器 B,让它取出保存的数据,接 A的班
要实现以上基本功能,首先要支持以下特性:
1.全局session id
每个jvm内部都会为每次session维护一个唯一的id,但多个jvm之间的session id会不会重复就很难说了,所以负载均衡器要能够协调各个jvm,使每个session id都能全局唯一。
2.如何备份session
这个跟具体厂商有关,后面会讲到
3.备份的频度和粒度
这个事关负载均衡的性能,因为备份数据的过程直接占用cpu、网络和IO性能
I.数据库方式备份
这是最简单的实现方式,数据库还能在整个系统都当掉时依旧保存好 session 数据,可靠性高,几乎所有 J2EE 实现都提供了这种方式,当然,你的 session 数据必须是可序列化的。但是,这种方式一般推荐不要在 session 中存放过大过多的数据,因为数据库的事务过程相当费资源,但这样也大大限制了它的使用范围,毕竟我们有时必须要在 session 中存放一些大对象
II.内存拷贝方式
这种方式好处很多,首先它省去了数据库连接和事务的开销,其次由于备份的数据已经放在内存中了,也就省去了从数据库恢复的过程
“JavaGroup”是当前tomcat和jboss集群方案的通讯层协议,本质上是一个可靠的组间通讯和管理的toolkit,它的核心功能 在于“ Group membership protocols” 和“message multicast”,用在集群上非常适合,关于JavaGroup的更多内容,请参考 http://www.jgroups.org/javagroupsnew/docs/index.html
III. Tomcat的实现:多服务器之间互相拷贝内存
虽然实现起来容易,但这种方法的弊端也显而易见,当节点增加时,拷贝量就要成倍增长,性能有时还不如不集群
IV.Weblogic, Jboss 和 WebSphere 的实现:双服务器拷贝
虽然这种方法的性能和扩展性都很好,但也有不少弊端
1 负载均衡器的复杂度加大,因为要记住每个服务器的备份者是谁
2 除了处理请求外,每个服务器还得自己维护备份开销
3 平时大量的内存都被用于备份数据,会增加 jvm 的垃圾收集频率,间接影响性能
4 一旦某个服务器长时间挂掉,那么另一台服务器的负荷就会翻倍,可能也被一起拖垮
为了克服以上缺点,各个厂商都有自己的不同解决方案
V. IBM 的方案:中央服务器
很像是之前的数据库方式吧,只是把数据库换成了一台专门备份的服务器,综合了数据库和内存方式的优点。
1 将备份和请求处理分开,增强了系统的鲁棒性
2 所有的备份数据都在专门的服务器上,节省了其他服务器的内存
3 所有服务器都能存取备份机器上的数据,任何服务器宕机了,负载都能平滑的分配到剩余所有服务器上,而不至于加重某台机器的负担
4 比起数据库连接,备份服务器使用的 socket 连接更加轻量级
比起直接的双服务器互拷内存,这种方式效率还是比较低的,因为还要有个恢复的过程,而且在管理上也增加了系统的复杂度。此外,备份服务器本身也很有可能成为瓶颈。
VI. Sun 的实现:专用数据库
表面上就是数据库的方式,但实际上, Sun JES 应用服务器使用的称为“ HADB ”的数据库是专门为 session 的备份做了优化的,其大部分数据都是直接存放在内存中
* Session 备份的性能考虑
集群中每台服务器都有多个 web 应用,每个应用又同时有数以千记的用户 session ,这些 session 的备份和恢复都会耗费大量资源。更恐怖的是, session 一直在变,比如失效了,比如增加或修改某个属性了,等等。所以如何备份 session 是考验系统架构水平的
何时备份?
不管是用数据库还是内存方式,下面两点都是比较常见的考虑
1. 按 web 请求,即每次请求都进行备份更新,这样可以保证备份的数据是最新的
2. 固定时间备份,虽然不能保证备份的 session 是最新的,但却可以提高性能
备份粒度
1.全部备份,最保险也是最慢的方法
2.备份修改过的 session 。通常的做法是检测 ”HTTPSession.setAttribute()” 或 “HTTPSession.removeAttribute()” 的调用,当然你要保证 session 的状态只能由这两个方法更改,尽管这不是 J2EE 规范的要求。
3.备份修改过的 session 的属性,最节省性能的做法。但是有一点很重要:防止交叉引用。如下图, session 中包含 school 对象,指向一个 student 对象。当 school 对象某个属性改变后,被备份到 AS2 中,它此时引用的是旧的 student 对象。接着 student 对象被单独改变了,也进行了备份,但是 school 中仍然引用旧的 student 。因此这种方法对 web 容器的设计要求很高,尽管它的性能是最好的。
图十三: session 复制中的交叉引用
VII.其他 失效接管的实现
以上不论是数据库还是内存复制,归根结底都要使用 Java 的序列化机制,这给 web 容器的性能造成了不小的影响,因此有些应用服务器使用别的方式进行 session 备份
JRun with Jini
JRun 4 使用 jini 实现集群, jini 的详细介绍请参考 http://java.sun.com/products/jini/2_0index.html
Tangosol with Distributed Cache
Tangosol Coherence™ 提供了一个分布式数据管理平台,可以嵌入到大部分 J2EE 系统中,此外还提供一个分布式缓存系统,能够在多台 jvm 上有效的共享缓存,详情请参考 http://www.tangosol.com/
原文出自 http://www.theserverside.com/tt/articles/article.tss?l=J2EEClustering