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

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

此解决方案的目的是从外部源获取数据输入，对其进行搅动，并使结果可用于多个前端。这些“前端”只会从缓存中获取数据并提供服务，而无需额外的处理。此数据的前端命中量实际上可能是每秒数百万次。

数据本身非常不稳定;它可以（并且确实）迅速变化。但是，在处理和缓存最新数据之前，前端应看到“旧”数据。处理和写入由单个（冗余）节点完成，而其他节点仅读取数据。换句话说：没有通读行为。

我正在研究像memcached这样的解决方案，但是这个特定的解决方案并不能满足下面列出的所有要求：

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

提前感谢您的任何想法。