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