J2EE集群原理 I

什么是集群呢？总的来说，集群包括两个概念：“负载均衡”（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