使用 Terracotta 进行透明的 JRuby 集群

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 {<br></br>
// ...<br></br>
private GlobalVariables globalVariables = new GlobalVariables();<br></br>
} <br></br>

及： ```

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