J2EE集群原理

J2EE集群原理
什么是集群呢？总的来说，集群包括两个概念：“负载均衡”（load balancing）和“失效备援”（failover）

图一：负载均衡
多个客户端同时发出请求，位于前端的负载均衡器根据特定算法，将请求分担给比较空闲的机器，从而实现较高性能和较好的扩展性

图二：失效备援
当客户端连续向某个服务器发出请求时，该服务器可能处理到一半就宕机了，失效备援系统能够检测出有问题的服务器，将后续的请求转发至其他可用的机器，从而实现容错功能

那么，哪些对象可以被集群呢，答案是：“可以被部署在分布式拓扑的组件”
因此，负载均衡和失效备援会发生在哪些J2EE代码中呢？“仅当你调用分布式对象的方法时”


图四：分布式对象
客户端和目标服务器不在一个JVM上，他们之间通过标准的网络协议进行通讯，这也就给集群提供了用武之地，实现集群效果的设备可以放在边界上对通讯做一些处理
J2EE的分布式技术包括：JSP,JDBC,EJB,JNDI,WEB SERVICE等等

网络层的集群实现
这是最常见最基本的J2EE集群功能，网络层集群技术包括：网络负载均衡和HTTP SESSION的失效备援

图五：网络负载均衡

负载均衡器可以是一个硬件设备，比如F5 Load Balancer，也可以是另外一台服务器加一个负载均衡的插件，甚至一个Linux的嵌入式设备都能胜任。通常，负载均衡包括以下几个特点：
l 实现负载均衡算法
常用的算法有：Round-Robin, Random 和 Weight Based，算法的最终目标是尽量使每台服务器的负载达到平衡，但以上算法只是根据每台服务器接收的请求来进行均衡，因此都不能完全达到理想化的目标。有些复杂的算法可以在分发请求之前检测机器的性能，从而决定要由哪台机器来处理请求。
l 健康监测
一旦某台机器宕机了，负载均衡器要能够及时发现情况，并且将请求转交给其他可用的服务器，保证做到“failover”
l Session stickiness
即是让一次session会话的请求都尽量交给一台机器处理，这样省去了服务器之间交换session数据的开销

HTTPSession  Failover
当session进行到一半时，如果服务器挂了，我们就要想办法让session在另外一台机器上继续进行，而不是让用户重新来过。下面图六解释了实现HTTPSession Failover的原理：每次的session都会分配一个唯一的id，这个id以cookies的形式存放在客户端中，负载均衡器通过id分辨请求是属于哪个session的。在第四步中，服务器A以某种定义好的方式，定期将session数据保存起来，一旦出问题，负载均衡器会自动通知另一台服务器B，让它取出保存的数据，接A的班

图六

要实现以上基本功能，首先要支持以下特性：
l 全局session id
每个jvm内部都会为每次session维护一个唯一的id，但多个jvm之间的session id会不会重复就很难说了，所以负载均衡器要能够协调各个jvm，使每个session id都能全局唯一。
l 如何备份session
这个跟具体厂商有关，后面会讲到
l 备份的频度和粒度
这个事关负载均衡的性能，因为备份数据的过程直接占用cpu、网络和IO性能


数据库方式备份

这是最简单的实现方式，数据库还能在整个系统都当掉时依旧保存好session数据，可靠性高，几乎所有J2EE实现都提供了这种方式，当然，你的session数据必须是可序列化的。但是，这种方式一般推荐不要在session中存放过大过多的数据，因为数据库的事务过程相当费资源，但这样也大大限制了它的使用范围，毕竟我们有时必须要在session中存放一些大对象



内存拷贝方式


这种方式好处很多，首先它省去了数据库连接和事务的开销，其次由于备份的数据已经放在内存中了，也就省去了从数据库恢复的过程

“JavaGroup”是当前tomcat和jboss集群方案的通讯层协议，本质上是一个可靠的组间通讯和管理的toolkit，它的核心功能在于“ Group membership protocols” 和“message multicast”，用在集群上非常适合，关于JavaGroup的更多内容，请参考 http://www.jgroups.org/javagroupsnew/docs/index.html

Tomcat的实现：多服务器之间互相拷贝内存


虽然实现起来容易，但这种方法的弊端也显而易见，当节点增加时，拷贝量就要成倍增长，性能有时还不如不集群



Weblogic, Jboss 和 WebSphere的实现：双服务器拷贝



虽然这种方法的性能和扩展性都很好，但也有不少弊端

l  负载均衡器的复杂度加大，因为要记住每个服务器的备份者是谁

l  除了处理请求外，每个服务器还得自己维护备份开销

l  平时大量的内存都被用于备份数据，会增加jvm的垃圾收集频率，间接影响性能

l  一旦某个服务器长时间挂掉，那么另一台服务器的负荷就会翻倍，可能也被一起拖垮



为了克服以上缺点，各个厂商都有自己的不同解决方案



IBM的方案：中央服务器

很像是之前的数据库方式吧，只是把数据库换成了一台专门备份的服务器，综合了数据库和内存方式的优点。

l  将备份和请求处理分开，增强了系统的鲁棒性

l  所有的备份数据都在专门的服务器上，节省了其他服务器的内存

l  所有服务器都能存取备份机器上的数据，任何服务器宕机了，负载都能平滑的分配到剩余所有服务器上，而不至于加重某台机器的负担

l  比起数据库连接，备份服务器使用的socket连接更加轻量级



比起直接的双服务器互拷内存，这种方式效率还是比较低的，因为还要有个恢复的过程，而且在管理上也增加了系统的复杂度。此外，备份服务器本身也很有可能成为瓶颈。



Sun的实现：专用数据库

表面上就是数据库的方式，但实际上，Sun JES应用服务器使用的称为“HADB”的数据库是专门为session的备份做了优化的，其大部分数据都是直接存放在内存中

Session备份的性能考虑

集群中每台服务器都有多个web应用，每个应用又同时有数以千记的用户session，这些session的备份和恢复都会耗费大量资源。更恐怖的是，session一直在变，比如失效了，比如增加或修改某个属性了，等等。所以如何备份session是考验系统架构水平的



何时备份？

不管是用数据库还是内存方式，下面两点都是比较常见的考虑

l  按web 请求，即每次请求都进行备份更新，这样可以保证备份的数据是最新的

l  固定时间备份，虽然不能保证备份的session是最新的，但却可以提高性能



备份粒度

l  全部备份，最保险也是最慢的方法

l  备份修改过的session。通常的做法是检测”HTTPSession.setAttribute()” 或“HTTPSession.removeAttribute()” 的调用，当然你要保证session的状态只能由这两个方法更改，尽管这不是J2EE规范的要求。

l  备份修改过的session的属性，最节省性能的做法。但是有一点很重要：防止交叉引用。如下图，session中包含school对象，指向一个student对象。当school对象某个属性改变后，被备份到AS2中，它此时引用的是旧的student对象。接着student对象被单独改变了，也进行了备份，但是school中仍然引用旧的student。因此这种方法对web容器的设计要求很高，尽管它的性能是最好的。

图十三：session复制中的交叉引用



其他失效备援的实现

以上不论是数据库还是内存复制，归根结底都要使用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://blog.csdn.net/wangchengsi/archive/2008/03/08/2158187.aspx
原文出自 http://www.theserverside.com/tt/articles/article.tss?l=J2EEClustering