Java数据网格规范:JSR-347详解

 

JSR-347是数据网格规范。和JSR-107（JCache）相比，这个JSR的应用场景生来就有争议，容易被混淆。InfoQ有幸采访了Manik Surtani，了解了他对JSR-347和JSR-107的看法，以及他对缓存、NoSQL、数据网格、Infinispan及相关主题所持的观点。

Manik是JSR-347规范的领导者，并长期参与JBoss Cache和JBoss Infinispan的开发和维护，这两个项目分别是领先、开源的Java缓存实现和数据网格实现。Infinispan数据网格项目开始于2009年4月，宣布开始之前，Manik至少花费了四个月时间去实现数据网格的原型。Infinispan受到了JSR-347的启发，Infinispan里的很多功能特性都是JSR-347目前所建议的。

InfoQ：JSR-347要达到什么目标？这些目标和JSR-107相比有何不同？

JSR-347也称为针对Java平台的数据网格，大家建议JSR-347能统一API、编程模型，分布式的预期行为，还有容错的内存键值存储。它在很多方面都和JSR-107（针对Java平台的临时缓存）有所不同：

1. 数据持久性。JSR-347想借助它固有的分布式特性记录存储，从而提供耐久性。JSR-107则假设存储起来的数据是临时而短暂的。
2. 分布式。JSR-107允许实现可以是分布的，JSR-347则要求实现必须分布。因此，标准可以为用户提供更丰富的API，以便用户很好地利用数据存储。比如说，只有知道实现是分布式的时候，暴露那些能控制数据在网格里存储位置的API，异步和非阻塞的API，还有那些终终支持相容实现的API才有意义。
3. Map/Reduce和分布式的代码执行。当数据跨网格分布的时候，把代码移到数据中执行有时候要比其他方式更有意义。JSR-347也会为这些功能提供标准的API。

InfoQ：已经签署协议去实现JSR-347的供应商有哪些？Gemfire和Coherence为什么还没参与到JSR-347里呢？

到目前为止，专家组包括Red Hat、Gigaspaces和GridGain。Oracle和IBM通过法律审批后才会正式签署协议，不过他们都表示有兴趣。

Manik接着说，他希望Oracle的Coherence团队能参与到JSR-347里来，Coherence团队已经表示有兴趣了，现在正在走内部流程，然后才会正式签署协议。他还说，JSR-347团队已经联系了Gemfire，但Gemfire还没有反馈。

InfoQ：JBoss Cache是怎样演进的？JBoss Cache如何演变成了Infinispan？

JBoss Cache是我们搭建JBoss应用服务器集群的工具包。我们用它来实现HTTP和EJB会话的集群，还有一个具备事务特性的Hibernate/JPA二级缓存。

Manik解释说，开发人员接着把JBoss Cache当作具备永久存储功能的数据网格来用。由于JBoss Cache并不是设计成数据网格的，所以才创建了Infinispan。Infinispan既能替代JBoss Cache作为集群工具包，也能提供非常强大的数据网格功能。

InfoQ：假定JBoss应用服务器的用户默认用Infinispan做会话复制，那有多少JBoss用户会真正使用Infinispan所有的数据网格功能呢？假如JSR还没有针对缓存或分布式缓存的标准接口，又有多少JBoss用户会真正用Infinispan去做分布式缓存或数据网格呢？

这很难说。JBoss应用服务器和Infinispan都是开源项目，我们已经明确区分了社区所作的事情，还有他们怎样和Infinispan交互。如果用户论坛和IRC上的问题能作为依据，我看大部分人的问题是如何在JBoss应用服务上部署的Web应用或EJB里直接使用Infinispan的API。不过提问的也只有这些人。

InfoQ：什么能定义数据网格解决方案？是查询、事务、从缓存读、写入缓存、数据分片、数据复制还是Map/Reduce等其他内容呢？数据网格必须支持哪些功能？

我的回答自然有些主观，但我认为数据网格需要提供事务、读取、写入、某些形式的分片或分区，还有监听器。查询和Map/Reduce是更高级的功能，不过大家很快就会期望数据网格能具备这两个功能，所以我们觉得它们也该添加到功能列表里。

InfoQ：你怎么定义Infinispan的Map/Reduce？为什么它对Java开发人员来说很重要？

在处理跨大量服务器的分布式数据时，Map/Reduce本身就是个很重要的概念，因为它有更高的CPU和内核利用率，同时能减少网络流量。

Infinispan的Map/Reduce在概念上和Google最初的概念非常接近，但在实现上，我们遵循流畅API、人类易读和直观接口的原则，还有现代Java API设计的通用很好实践。因此，和Hadoop等其他Java Map/Reduce实现不同，我们觉得Infinispan的实现要更为直观、对开发人员非常友好。

InfoQ：Infinispan会成为 JSR-347的参考实现吗？

不会。参考实现需要Apache的许可，而Infinispan则使用了LGPL许可。

InfoQ：我发现Infinispan支持Memcached的文本Wire协议，这是为什么呢？

我们支持Memcached的Wire协议，最初是想让非Java平台接受我们。Memcached有非常多的客户端库，几乎针对所有的平台。支持Memcached的Wire协议就意味着差不多所有系统都能使用Infinispan。

随后我们设计并实现了Hot Rod，用它来替换Memcached的Wire协议，编写完这个“可参考的”Java客户端后，我们就发现社区为Python和Ruby构建了Hot Rod客户端。

Manik接着解释说，Memcached的协议对数据网格解决方案来说太过简单，因为它使用请求/响应方式，完全是客户端/服务器模式。相反，Hot Rod允许服务器连接客户端，把后端拓扑结构的变化推送给客户端，这对弹性来说至关重要，可以在运行时增加新的数据网格节点。Hot Rod以后的版本会添加事件处理，Manik说这会开辟一个充满机遇的世界。尽管Memcached的Wire协议针对分布式缓存，但Hot Rod似乎能突飞猛进，成为事实上的数据网格标准Wire协议。

InfoQ：和Oracle Coherence、Enterprise EhCache、VMWare Gemfire的特性相比，JSR-347或Infinispan的功能怎么样？

刚刚提及的产品已经支持了为JSR-347规划的大部分功能。主要区别在于特定API本身。当然这并不全面，有些产品可能不具备某些功能，比如Map/Reduce，但他们也许有能添加缺失功能的组件。

InfoQ：JSR-347是个NoSQL解决方案规范么？相应的，Infinispan是不是NoSQL解决方案？无论是或与否，原因又是什么呢？要成为一个NoSQL规范，JSR-347还缺少哪些功能？

JSR-347是个标准。它不是个NoSQL标准，只是个数据网格标准。Infinispan会实现JSR-347，所以它只是个数据网格，不过Infinispan也在不断发展，会添加很多NoSQL的特性。照目前的情况看，NoSQL和数据网格之间的差距很小；Infinispan只是进一步去缩小这种差距。

Manik接着解释说，JSR-347是个成熟的NoSQL规范，而且不同寻常的是，它是关注Java的先行者。

很大的区别在于平台独立性。JSR-347仍然是个Java规范，而很多NoSQL数据库则超越了Java平台。

InfoQ：查询是JSR-347的一部分吗？

这需要专家组去决定。

InfoQ：你是怎样界定数据网格、NoSQL、对象缓存的？

我觉得对象缓存是把对象暂时存储在内存里，检索或计算会很费劲。数据网格把这种做法深入了一步，借助其有弹性、分布式的特性，数据网格提供了一定程度的耐久性。NoSQL则采用了另一种做法，NoSQL通常用磁盘存储作为主要的存储引擎，但提供了弹性和可伸缩性，至少在分布式NoSQL引擎的情况下是这样的。

InfoQ：对NoSQL实现来说，最重要的特性是什么？

在我看来，最重要的特性是可伸缩的弹性。否则的话，你还不如使用RDBMS，毕竟你早熟悉了它的安装和使用。

InfoQ：从设计来说，Inifinispan和竞争对手（Coherence、Enterprise EhCache、GemFire）有什么区别？

我不知道专利产品内部是如何设计的。

InfoQ：能描述下Inifinispan的设计理念么？

可插拔和可扩展性是关键。我们期望人们能用Infinispan去做任何事情，而不仅仅成为按我们描述的使用模式去操作的终终用户。用户在某些情况下可以动态添加拦截器、命令和行为。作为开源软件，代码和设计都是透明的，这样人们就很容易去扩展Infinispan。

Manik接着介绍了学习Infinispan和JSR-347的一些方式。Infinispan的下一个版本5.1.0近期会发布测试版本。要看JSR-347是如何进展的，JSR-347的Wiki是个好去处。还有一些关于Inifinispan和CDI集成的视频，Inifinispan和CDI的集成是规范最先做的一部分。他解释说，你可以使用Infinispan的Maven原型快速开始一个项目，并看看JSR-347是什么样子。

 

---