选择分布式共享内存解决方案

时间:2010-06-15 12:40:37

标签: java architecture nosql distributed-caching

我有一项任务是为大规模可扩展的分布式共享内存(DSM)应用程序构建原型。原型只能作为概念验证,但我希望通过选择稍后将在真实解决方案中使用的组件来最有效地利用我的时间。

此解决方案的目的是从外部源获取数据输入,流失它并使结果可用于许多前端。那些“前端”只会从缓存中获取数据并在没有额外处理的情况下提供服务。这些数据的前端命中量实际上可以达到每秒数百万次。

数据本身非常不稳定;它可以(而且确实)变化很快。然而,在最新的处理和缓存之前,前端应该看到“旧”数据。处理和写入由单个(冗余)节点完成,而其他节点仅读取数据。换句话说:没有通读行为。

我正在研究像memcached这样的解决方案,但是这个特定的解决方案不符合所有我们的要求,如下所示:

  1. 解决方案必须至少具有 Java客户端API ,由于其余的应用程序是用Java编写的,我们是经验丰富的Java开发人员,因此维护得相当好;
  2. 解决方案必须完全弹性:应该可以添加新节点而无需重新启动群集中的其他节点;
  3. 解决方案必须能够处理故障转移。是的,我意识到这意味着一些开销,但整体服务的数据大小并不大(最大1G),所以这应该不是问题。 “故障转移”是指在节点出现故障时无需硬编码/更改服务器IP地址(如memcached客户端)的无缝执行;
  4. 理想情况下,应该可以指定数据重叠程度(例如,应在DSM群集中存储相同数据的副本数量);
  5. 无需永久存储所有数据,但可能需要对某些数据进行后处理(例如,序列化到数据库)。
  6. 价格即可。显然我们更喜欢免费/开源,但如果解决方案值得,我们很乐意支付合理的金额。无论如何,支付24小时/天的支持合同是必须的。
  7. 整个事情必须在我们的数据中心中托管,因此像Amazon SimpleDB这样的SaaS产品超出了范围。如果没有其他选择,我们只考虑这个。
  8. 理想情况下,解决方案严格一致(如CAP中);但是,最终一致性可视为一种选择。
  9. 提前感谢任何想法。

8 个答案:

答案 0 :(得分:25)

看看Hazelcast。它是纯Java,开源(Apache许可证)高度可扩展的内存数据网格产品。它确实提供7X24支持。它确实解决了我试图在下面解释每个问题的所有问题:

  1. 它有一个本机Java客户端。
  2. 100%动态。动态添加和删除节点。无需改变任何东西。
  3. 一切都是动态的。
  4. 您可以配置备份节点数。
  5. Hazelcast支持持久性。
  6. Hazelcast提供的所有内容都是免费的(开源),它确实提供了企业级支持。
  7. Hazelcast是单个jar文件。超级好用。只需将jar添加到类路径中即可。看看主页面中的屏幕投射。
  8. Hazelcast严格一致。你永远不能读取过时的数据。

答案 1 :(得分:5)

我建议你使用Redisson - 基于Redis的内存数据网格for Java。实现(BitSetBloomFilterSetSortedSetMapConcurrentMapListQueueDequeBlockingQueueBlockingDequeReadWriteLockSemaphoreLockAtomicLongCountDownLatch,{{在Redis服务器之上的1}},Publish / SubscribeRemoteServiceExecutorServiceLiveObjectService)!它支持主/从,前哨和集群服务器模式。还支持自动群集/标记服务器拓扑发现。这个lib是免费的开源。

借助AWS Elasticache支持,在云中完美运行

答案 2 :(得分:3)

根据您的喜好,我肯定会跟随其他人建议Hazelcast,如果你是从CAP定理到AP,但如果你需要CP,我会选择Redis

答案 3 :(得分:2)

您可能想要查看特定于Java的解决方案,例如Coherence:http://www.oracle.com/global/ru/products/middleware/coherence/index.html

但是,我认为这样的解决方案过于复杂,而且更喜欢使用像memcached这样的解决方案。 memcached的最大缺点是你的目的是缺乏记录锁定,并且没有内置的方法来复制数据以进行故障转移。这就是为什么我会研究键值数据存储。他们中的许多人将完全满足您的需求。

以下是可帮助您完成任务的键值数据存储列表: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores 只需挑选一个你满意的。

答案 4 :(得分:2)

我正在做一个类似的项目,而是针对.NET平台。除了已经提到的解决方案之外,我认为你应该看看ScaleOut StateServerAlachisoft NCache。我担心这些替代品都不便宜,但根据我的判断,它们比商业解决方案的开源更安全。

  1. 两者都提供Java客户端API,即使我只使用过.NET API。
  2. StateServer具有自我发现的新缓存节点,NCache有一个管理控制台,可以添加新的缓存节点。
  3. 两者都应该能够无缝地处理故障转移。
  4. StateServer可以拥有1或2个数据的被动副本。 NCache具有更多缓存拓扑可供选择。
  5. 如果您指的是两者都可用的数据库的直写/后写。
  6. 我不知道您打算使用多少缓存服务器,但以下是完整的价格规格: ScaleOut StateServer Alachisoft NCache
  7. 两者都在您的服务器上本地安装和配置,并且都具有GUI管理。
  8. 我不确定究竟是什么严格一致,所以我会留给你调查..
  9. 总的来说,如果你想跳过配置缓存集群中的每一个细节,StateServer是最好的选择,而NCache有很多功能和缓存拓扑可供选择。

    根据数据对客户端的行为(如果从同一客户端多次读取数据),最好将客户端上的本地缓存与群集中的分布式缓存混合使用(对于两个NCache都可用)和StateServer),只是一个想法。

答案 5 :(得分:1)

看看Terracotta的JVM集群,它是OpenSource;) 它没有API,而它在JVM级别上运行效率很高,当您将值存储在复制对象中时,它将被发送到所有其他节点。 即使是锁定,所有这些工作都是透明的,无需添加任何新代码。

答案 6 :(得分:1)

指定的用例似乎适合Netflix的Hollow。这是一个只读的复制缓存,具有单个生产者和多个使用者。

答案 7 :(得分:0)

您是否考虑使用rabbitmq之类的标准消息传递解决方案? RabbitMQ是AMQP protocol的开源实现。

您的应用程序似乎或多或少像发布/订阅系统。 Publisher节点是进行处理并将消息(已处理数据)放入服务器队列中的节点。 订阅者可以通过各种方式从服务器获取消息。 AMQP将消息的制作者和消费者分离,并且在如何将双方结合起来方面非常灵活。