我们有3个DC [美国，欧盟，亚洲]，每个都有3个节点，所以共有9个节点。我们正在进行实验，所以如果需要我们可以增加。
我们计划使用每DC 2的RF。在那种情况下，我们的法定人数达到2。
使用local_quorum的R / W一致性，因为我们可以容忍每个DC 1个节点的故障，我假设。只有当数据中心的第二个节点出现故障时，我们才遇到麻烦。
但this calculator另有说明。在这里，如果我们选择3的簇大小和RF：2，WL / RL作为法定数量 - 它说我们可以在无节点的情况下存活。我遗漏了与Quorum大小和群集中机器总数相关的内容吗？
答案 0 :(得分：5)
但是这个计算器另有说明。这里，如果我们选择3的簇大小和RF：2，WL / RL作为仲裁 - 它说我们可以在没有节点丢失的情况下存活。我遗漏了与仲裁大小相关的东西和集群中的机器总数？
那个计算器是正确的。
假设您使用“A”键将数据写入群集。 3个DC中的3个节点和2的RF，您的写入将如下所示：
US EU ASIA
node1- A node1- A node1- A
node2- A node2- A node2- A
node3- node3- node3-
我们可以容忍每个DC 1个节点的故障
由于高可用性是您要解决的问题，让我问一个问题：
如何确保节点发生故障时，它始终是node3？
有时它会。但有时您可能会丢失node1或node2，其中包含数据“A”的副本。当发生这种情况，并且您在LOCAL_QUORUM查询时，它将在DC中查找两个副本。如果一个节点关闭，并且该节点恰好包含“A”的副本，则查询将失败。
这里有两点。 MarcintheCloud是对的，如果可用性确实是您的关注点，那么您应该将RF增加到3。
第二，你应该问自己是否真的需要在LOCAL_QUORUM查询。 Netflix在2013 Cassandra峰会上做了一个演讲，讨论了他们如何尝试“最终的一致性”和LOCAL_ONE。这是相当不错。它会让你仔细思考你真正需要使用QUORUM一致性的程度。
A Netflix Experiment: Eventual Consistency != Hopeful Consistency
答案 1 :(得分：4)
你提到的法定人数是多数（1/2 + 1）。在RF = 2的情况下，多数是1 + 1 = 2。这意味着您需要来自副本节点的2个确认才能使请求成功。因此，如果您的两个副本中的一个出现故障，则无法实现一致性，请求将失败。
为了能够处理中断并且仍然执行法定数量，我建议将复制因子提高到3.