使用 Terracotta 进行透明的 JRuby 集群

阅读数:206 2008 年 12 月 17 日

话题:JavaRubyDevOps语言 & 开发架构

Gemstone 在 RailsConf 上所展示的Maglev Demo展现了 Gemstone 的分布式 VM 技术,它可以透明地跨越多个 Gemstone VM 以共享相同的对象内存。

Terracotta是一项 Java 技术,它也可以完成类似的功能。Fabio Kung 已经开始了一些尝试以将 Terracotta 应用到 JRuby 上。过去他也尝试过一些类似的项目。Gemstone还尝试了在其基于 Java 的产品上支持 JRuby,之前他们也尝试过将 Terracotta 应用到 JRuby 上,尽管没有取得实质性的突破。

我们采访了Fabio Kung以了解该项目,他称这个项目为“JMaglev”,我们想知道要想让 JRuby 和 Terracotta 协同工作需要做哪些事情以及需要解决哪些问题。

首先,Fabio 谈到了他的实现以及他是如何对 JRuby 进行了修改以让其正常工作:

我使用了 Terracotta POJO 集群以便 JRuby 内核可被集群中的所有节点所共享。事实上,每次运行都会有一些全局变量,像下面这样:

public class Ruby {

// ...

private GlobalVariables globalVariables = new GlobalVariables();

}

及:
public class GlobalVariables {
 // ...
 private List values = new ArrayList();

}



Terracotta 仅仅对这个全局变量列表进行集群。对该列表的任何改变都会被复制到集群中的所有 JRuby 运行时。这样做的好处在于你可以将任何 ruby 对象增加到该列表中,甚至连复杂的对象如 regexps、hashes 和 procs 都可以。所有的全局变量都会自动被共享,同时由全局变量所引用的任何对象都会被 Terracotta 加到集群中。

为了做到这一点,我需要对 JRuby 进行一些修补,使其可以被“集群”。事实上,JRuby 中的每个 ruby 对象都会维护一个 ruby 运行时引用。由于共享的对象会用在很多不同的运行时中,所以 JRuby 必须得支持运行时的增加及删除。我可以解决这个问题,但是每个 JVM 上只能有一个 Ruby 运行时。在这个地方仍然有一些尚未解决和需要讨论的问题,如:

——全局对象标识符:在所有节点中 object_id 都应该相同么?——共享的元类(metaclass):当不同节点中的对象类、父类或者是包含的模块发生变化时怎么办?——在单个 JVM 上对多个运行时的支持。

对于这些问题我采取了简单的解决方法,但每种方法都需要一整篇博文才能说明白:-)

Fabio 解释了他知道的一些针对JRubyTerracotta的用例:

通过使用 Terracotta 的 High Availability 模式,我认为“JMaglev”(或许需要起个更好的名字)绝对能成为一个很棒的 memcached 而无需侵入 Ruby 代码。然而还有很多事情需要做。这就是我将其开放的原因所在,如果大家感兴趣,都可以尽一份力:http://github.com/fabiokung/clustered-jruby/

很多服务器都可以配置在 Terracotta 中,其中一个服务器叫“主”服务器(或者叫活动服务器),其他的处于备用模式。这很有意思,因为一旦活动服务器崩溃,其他的就会自动顶替上去。在 Terracotta 的企业版中甚至还有一种可用的模式,该模式可以开启多个活动服务器,这与 memcached 所做的事情差不多,但是 memcached 不会持久化对象。

Terracotta 可作为一个分布式缓存,同时无需 Java 序列化:它仅仅复制改变的东西。你只需要将想从数据库中取出的对象共享给集群中所有的节点即可。通过使用 JMaglev,你只需将他们放到全局变量中即可——$shared = Person.find(:all)。

其他可能的用例是在 Rails 应用中的多个进程和机器上共享 HttpSession。如果将 rails 应用部署到 JRuby 中,那么可以使用透明的集群对象来维护集群中所有节点所共享的 HttpSession。

事实上,任何 Terracotta 用例都是 JMaglev 用例。坦诚地说,就是因为这是可行的,我才这么做。这与 Avy Briant 的 Maglev 例子非常像:他说可以使用 SmallTalk VMs 运行 Ruby 代码,然后 Gemstone 的那些家伙让他证明这是可行的:-)

我希望那些比我更富创造力的人们能为“JMaglev”想出更多创造性的用例。

分布式的对象内存仅仅是Gemstone/S(以及 MagLev)诸多特性中的一个;另一个重要特性是持久化。正如 Gemstone 的Monty Williams 在最近的一个关于 Rails 的播客中所说,Gemstone/S 支持对象内存的持久化,这意味着我们无需 ORM甚至是RDBMS来存储数据。

当被问到“JMaglev”是否支持类似的功能时,Fabio 说到:

所有共享的 ruby 对象都位于 Terracotta 服务器中,而 Terracotta 服务器能自动地持久化这些对象,即使他们不是序列化的也可以。客户端持有这些真正的、共享的对象的桩(stubs)。你只需将服务器配置成持久化模式即可。我还没有测过,但这需要在 XML 配置文件中增加一行。

我认为 Terracotta 可作为一个面向对象的数据库以持久化 JRuby 对象,但我觉得这不是目前最主要的目标。Terracotta 现在可以通过其 High Availability 模式来持久化共享的对象,这存在于 fail-safe-high-available 部署中。http://www.terracotta.org/web/display/docs/Configuring+Terracotta+For+High+Availability

Terracotta 的站点上列出了很多 Terracotta 集成模块(Terracotta Integration Modules,即 TIM),其中一些面向的是流行的 ORM 解决方案。当被问到这是否有助于持久化时,Fabio 说到这些 TIM 的目的是不同的:

这些 TIM 并不涉及共享对象的自动持久化。他们仅有助于 Terracotta 与这些 ORM 框架的协作。例如,hibernate TIM 与持久化没有任何关系。它仅仅是简化了 Hibernate 对集群的(分布式的)EhCache(以及其他)的使用而无需真正的分布式缓存,如 JBoss TreeCache 和 memcached。

Fabio 展示了JRuby 与 Terracotta 是如何协作的。要想尝试一下,请参考Fabio 在 Github 上的 clustered-jruby 仓库,它提供了你所需要的所有内容。

查看英文原文:Clustered JRuby - Transparent Clustering of JRuby with Terracotta