我们正在寻找缓存问题的良好解决方案。我们希望在一组Web服务器中分发相对少量的数据（可能是10 GB），这样：
我们对缓存解决方案的动机是我们目前只有一个故障点：SQL Server数据库。遗憾的是，我们无法为此数据库设置故障转移群集。我们已经在很大程度上使用Memcached，但是我们想要避免这样的问题，即如果Memcached节点出现故障，我们突然会遇到大量的缓存未命中，因此会遇到大量的请求到一个端点。
我们宁愿在每个Web服务器节点上都有本地持久性缓存，以便分配生成的负载。在进行检索时，它将通过以下内容：
当数据发生变化时，缓存密钥在两个缓存层都无效。
我们一直在寻找一系列潜在的解决方案，但它们似乎都不符合我们的需求：
这非常接近;我们想要缓存的数据模型非常面向文档。但是，它的复制模型并不是我们正在寻找的。在我看来，复制是一个动作，你必须执行而不是节点之间的永久关系。您可以设置连续复制，但这不会在重新启动之间保持不变。
此解决方案似乎主要针对那些存储要求较高的解决方案。我们有大量用户，但数据量很少。 Cassandra看起来能够支持 n 多个故障转移节点，但节点之间的100％复制似乎并不是它的目的;相反，它似乎更倾向于分配。
一个有吸引力的想法是我们可以在SAN或类似类型的设备上存储一堆文件。我之前没有使用过这些，但似乎这仍然是单点故障;如果SAN出现故障，我们会突然转到数据库以查找所有缓存未命中情况。
简单的Google搜索显示了这一点。它似乎做了我们想要的;它跨复制群集中的所有节点同步文件。但是营销文本使它看起来更像是一个确保文档被复制到不同办公地点的系统。此外，它有限制，如文件数最大值，对我们来说效果不佳。
你们中有没有人对我们有类似的要求，并找到了满足你需求的好解决方案？
答案 0 :(得分：1)
我们已经成功使用Riak几个月了，因为这个问题与你描述的有些相似。我们之前也对CouchDB和Cassandra进行了评估。
Riak在这类问题中的优势在于分发和数据复制是系统的核心。你可以定义你想要的集群中数据的副本数量，它会处理其余的数据（当然，这比复杂程度要复杂一点，但这才是最重要的）。我们经历了添加节点，删除节点，节点粉碎，并且它被证明具有惊人的弹性。
在其他方面与Couch非常相似 - 面向文档，REST界面，Erlang。
答案 1 :(得分：0)
您可以查看hazelcast。 它不会保留数据，但会提供故障转移系统。如果节点发生故障，每个节点可以有多个节点来备份它的数据。