使用Terracotta进行透明的JRuby集群

作者 Werner Schuster 译者 张龙 发布于 2008年12月17日

领域

架构 & 设计,

运维 & 基础架构,

语言 & 开发

主题

数据库设计 ,

性能和可伸缩性 ,

Java ,

Ruby ,

JRuby

标签

JRuby ,

对象数据库 ,

GemStone

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解释了他知道的一些针对JRuby和Terracotta的用例：

通过使用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

译者 张龙 热衷于编程，乐于分享，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。

• 更早的 >