Java集群框架Shoal支持容错及分布式状态缓存

Shoal是一个基于java的动态集群框架，为构建容错、可靠和可用的Java EE应用服务器提供了基础架构支持。它还可以插入到需要集群和分布式系统支持的任何java应用中。Shoal是GlassFish（v2及后续版本）和JonAS 应用服务器的集群引擎。

Shoal框架提供了客户端APIs以发出如运行时集群成员的增加或减少这样的事件。一个成员可以以核心成员（其失败会被通知给集群中所有其他的成员）或旁观者成员（其失败不会被通知给集群中其他成员，但它会收到其他核心成员的所有通知）的方式加入到组中。Shoal的核心服务是组管理服务（Group Management Service——GMS），它给客户端（JVMs）提供了一个组消息句柄，使其可以向组或集群中特定的成员发送消息。Shoal还提供了其他一些非常棒的特性，例如面向恢复的信号及支持，自动恢复成员选择（Shoal自动委托恢复初始化）和失败保护操作。

java.net网站上最近有一篇文章讨论了Shoal框架的架构以及如何将它集成到java应用中。InfoQ与Shoal框架的合作者Shreedhar Ganapathy和Mohamed Abdelaziz讨论了该产品当前的特性以及未来的发展路线图。InfoQ问到Shoal与其他的开源JVM集群框架像Terracotta相比如何。他们说Terracotta采取了非基于API的字节码增强方式，这对于数据复制难题给出了非常好的解决方案。Shoal的集群方式来自于一个容错的基础架构。它提供了一个组事件通知模型使得消费应用程序（consuming applications）可以解决分布式系统领域中的很多难题包括数据复制。他们解释了其开发团队如何使用Shoal来解决GlassFish服务器的特定集群需求。

以我们为例，GlassFish需要能满足若干个GF组件的集群解决方案，例如IIOP负载平衡，Session复制模块，事务服务模块等等。

在IIOP负载平衡的情况下，需求如下：当一个失败产生时，orb应该让其远程客户端对集群中的其他成员也产生失败的结果。连接到特定实例的orb的远程客户端会通过Shoal的事件通知机制得到动态的集群变化信息以及IIOP端点地址。

在事务服务模块的情况下，需求如下：根据一个失败成员的事务日志，从一个远程集群成员中执行自动的事务恢复操作以使得在失败时刻未完成的事务得以完成。为了支持上述特性，我们提供了一个 恢复服务器选择通知 （recovery server selection notification）以及失败防护支持。

对于Shoal中的“组通信（Group Communication）”模块与其他的组通信框架如JGroups相比的问题，他们回答如下：

组通信服务提供者提供了一套API，对各种组通信提供者实现提供了支持。默认情况下Shoal使用 JXTA框架。如果遵循服务提供者API，我们可以换成其他的实现，因此可以采用JGroups、基于 Appia或者基于 JINI的组通信提供者。 

JXTA不需要指定单独的TCP和UDP传输就可以进行通信，并且它还不限于IP（支持RF，BT等）。当在集群中的进行广播时，JXTA可以动态决定向集群成员发送消息的最佳方式，这是通过IP广播和虚拟广播来实现的。

Shoal中基于JXTA的提供者利用了JXTA所提供的同层寻址的位置透明性，这是因为组成员是由其名字来标识的，该名字被散列后映射为一个128位的标识符。该标识符被链接到网络上，向成员显示所有物理和虚拟地址，这样就可以支持容错性、灵活性和非ip传输。这简化了集群内的连通，我们可以通过组或者实例名来定位集群、套接字和消息通道。此外，名称模式被扩展到通信通道，这样就可以虚拟化实例（例如，可以对一个具体的应用服务使用名称而不是端口号）之间的寻址。JXTA上的TCP传输通信完全是基于NIO的，因而能够提供可伸缩的消息处理和吞吐量。JXTA还支持认证和授权，提供了端到端的安全性。两位作者还对JGroups框架中可靠的广播特性进行了评论：

JGroups是一个著名的组通信提供者。我们喜欢JGroups的众多原因之一是它提供了一个非常好的可靠的广播栈。然而当前的JXTA提供者尚未提供可靠的广播，我们正在评估开源的实现机制以提供高效和轻量级的可靠广播。JGroups中其他的不同点包括 RPCDispatcher，这对于在UDP上模拟受阻塞的消息是非常有用的。

InfoQ问到了“虚拟广播通道（virtual multicast channels）”以及在一个典型的JEE集群应用中它们是如何工作的。

虚拟广播通道是一种抽象，对跨越正常广播边界的通信提供了支持。典型地，当用户需要跨越几个子网的集群或者是广播被禁用时，他必须请求网络管理员允许在指定sockets上的指定路由器上进行广播通信。JXTA的虚拟广播支持组之间的无缝通信而不必改变网络或者应用。用户仅仅需要指定一些成员作为冗余的路由主机，他们可以作为软件路由器将信息路由到其他组成员。它的工作方式非常类似于 IGMP，仅仅需要将一个虚拟广播组加入到指定的路由节点中，接下来就可以利用这些路由节点来传播集群中的消息——这是模仿了交换机的工作方式。此外在可能的情况下可以采用IP广播。考虑下面的情况：你只在一个子网中进行广播，这时将一个或者几个组成员配置为路由主机使得子网外的成员可以通过TCP进行组通信，而子网内的成员仍旧使用广播方式通信。这对地理上分布的集群的基于WAN的部署提供了基础（下个版本将提供对基于WAN的部署包括跨防火墙的支持）。

关于集群应用中session的复制问题，InfoQ问到是否可以使用Shoal API来对web应用，集群EJB和JMS组件中的HTTP session进行复制。他们说：

GlassFish应用服务器中的EJB容器、事务服务、定时服务、Orb、Session复制模块以及其他组件都使用了Shoal来与集群中的成员进行交互。用户可以将Shoal用于集群几乎任何产品：JMS（MQ clusters）、数据库（指 Postgres或者 MySQL集群），甚至进行 CVS和 Subversion的集群。 

Shoal框架还有一个叫做分布式状态缓存（Distributed State Cache，DSC）的共享分布式存储特性，它可以用来在内存中对应用的状态进行分布式缓存。GMS为轻量级复制缓存提供了一个默认实现。Sreedhar将DSC与其他的java对象缓存框架如JBossCache、OSCache和EHCache进行了对比.  

Shoal中的分布式状态缓存是一个接口，针对该接口可以有多种实现。默认实现是一个简单的共享缓存，可以处理轻量级消息传递如配置数据、组状态机等等。它不适合进行高吞吐量的缓存，也不支持基于LRU（Latest Recently Used）的缓存校验与分布式的锁语义。

最近在设计和实现可伸缩应用架构时，网格和云计算得到了越来越多的重视。InfoQ问到在网格计算架构中Shoal框架扮演了什么样的角色。他们解释了为何Shoal很适合构建这样的解决方案：

 Shoal提出了一个组长（组长依赖于其下的组通信提供者）的概念。在失败时（这同样依赖于组通信服务提供者）组长有相应的继任者。系统通过实例名称映射来动态和独立地推选出组长和继任者，这会降低网络传输并加快系统的构成，此外还能减轻网络分区症状（split brain syndrome）。一旦这两个基本需求得到了满足，我们会很清楚地看到组长是称职的计算网格的任务管理者。加上JXTA对于虚拟广播和跨子网的支持，我们可以扩展集中资源孤岛的概念，它可以执行任务并向主线组长报告结果。服务位置透明性也对资源的移动提供了支持，这意味着网格可以基于可用性扩展或收缩，必要时还可以移动。想想几个 Blackbox项目数据中心托管在一个网格的情况。 

Shoal的另一个使用地方是作为一个计算网格应用的底层引擎。 FishFarm项目当前正使用Shoal做这个事情。

最后根据新版本以及即将增加的一些特性，InfoQ问到了Shoal项目未来发展的路线图，他们回答如下：

当前我们正从事于 Sailfin的电信应用服务器项目的支持工作，这包括了一个负载均衡组件。我们未来的计划是提供一个基于分布式缓存的数据网格解决方案。  

利用GMS服务，Shoal可用于动态服务器供应，因此可以根据负载情况在失败时采取适当的动作以提供更多的资源。Shoal是双重许可的：基于CDDL1.0和GPL v2协议（除了类路径）。

查看英文原文：Java Clustering Framework Shoal Provides Fault Tolerance and Distributed State Cache