一致性级别的读/写策略

Question

基于Read Operation in Cassandra at Consistency level of Quorum?

there are 3 ways to read data consistency:
a. WRITE ALL + READ OoNE
b. WRITE ONE + READ ALL
c. WRITE QUORUM + READ QUORUM

对于数据，写操作通常发生一次，但经常发生读操作。 但是要注意读取的一致性，是否可以合并a和b？ 这是，WRITE ONE - ＆gt;阅读一个 - ＆gt;如果没有找到 - ＆gt;全部阅读。 该方法通常只执行一次读/写操作吗？ 在没有数据的节点上，第一次只读取ALL。

那么我的理解是否正确？

威利安，谢谢你的精心阐述。我想我需要描述我的用例，如下所示。我实现了一个时间轴使用可以发布到。用户可以关注有趣的帖子。因此，通知将发送给粉丝。为了节省带宽，用户在CL ONE上写/读帖子。最终，用户总是可以通过读取修复一段时间阅读帖子。如果他们收听帖子，关注者将收到添加到帖子中的评论通知。这是我的问题。如果通知发送给粉丝，必须确保粉丝可以阅读评论。所以我缩进使用CL ONE检查注释是否同步到查询的节点。如果没有结果，请尝试CL ALL同步评论。因此，节点的其他关注者查询不需要同步其他节点，因为之前完成了CL ALL，这可以节省带宽并降低服务器开销。因此，对于您的最终方案，我不关心该值是旧的还是最新的，因为数据是根据通知同步的。如果通知发送给粉丝，我需要确保用户可以收到评论。

Answer 1

从the answer到相关问题，Carlo Bertuccini写道：

  

什么保证了一致性是以下的不一致

     

(WRITE CL + READ CL) > REPLICATION FACTOR

这个问题中的案例A，B和C似乎是指满足这种不平等的三种最小方式，如同一答案所示。

案例A

WRITE ALL会将数据发送至all replicas。如果您的复制因子（RF）是三（3），那么WRITE ALL会在报告成功写入客户端之前写入三个副本。但是，在下次读取相同数据密钥之前，您无法看到发生了写入。最低限度，READ ONE将从上述复制品中的一个复制品中读取，并满足必要条件：WRITE(3) + READ(1) > RF(3)

<案例B

WRITE ONE会将数据仅发送到一个副本。在这种情况下，获得一致性读取的唯一方法是从所有中读取它们。协调器节点将获得所有答案，找出哪一个是最新的，然后发送＆＃34;提示＆＃34;到过时的复制品，通知他们有更新的价值。提示以异步方式发生，但仅在READ ALL发生后才满足必要条件：WRITE(1) + READ(3) > RF(3)

案例C

QUORUM操作必须涉及FLOOR(RF / 2) + 1个副本。在我们的RF = 3示例中，即FLOOR(3 / 2) + 1 == 1 + 1 == 2。同样，一致性取决于读取和写入。在最简单的情况下，读操作会与写操作使用的完全相同的副本进行对话，但这种复制从未得到保证。在一般情况下，执行读取的协调器节点将与写入所使用的副本中的至少一个进行通信，因此它将看到更新的值。在这种情况下，就像READ ALL情况一样，协调器节点将获得所有答案，找出哪一个是最新的，然后发送＆＃34;提示＆＃34;到过时的复制品。当然，这也满足了必要条件：WRITE(2) + READ(2) > RF(3)

对于OP的问题......

是否可以＆＃34;合并＆＃34;案例A和B？

为确保一致性，只能＆＃34;合并＆＃34;如果你的意思是WRITE ALL + READ ALL，因为在上述情况下，你总能增加读者或作者的数量。

但是，如果您需要阅读一致的数据，WRITE ONE + READ ONE不是一个好主意，所以我的回答是：没有。再次，使用该方法和我们的示例RF = 3：WRITE(1) + READ(1) > RF(3) 不成立。如果您要使用此配置，则会收到无值 的答案无法信任 - 这只表示已联系一个副本做读取没有价值。但是值可能存在于一个或多个其他副本上。

从这个逻辑来看，似乎在接收无值答案时执行READ ALL可以解决问题。对于那个用例，它会考虑另一个：如果你从READ ALL得到某些值怎么办... 你怎么知道< / strong>返回的值是＆＃34;最新的＆＃34;一？当我们想要一致性时，这意味着什么。如果你关心阅读最近的写作，那么你需要满足不适。

关于＆＃34;时间线＆＃34;的使用案例已编辑问题中的通知

如果我对您描述的场景的理解是正确的，那么这些是您的用例的主要内容：

• 大多数（但不是全部？）时间轴条目将是一次写入（稍后不再修改）
• 可以遵循任何此类条目（有关注者列表）
• 任何此类条目都可以评论（有评论列表）
• 对时间表条目的任何评论都应触发对该时间表条目的关注者列表的通知
• 尝试最小化＆＃34;正常＆＃34;的成本（在这种情况下，以带宽衡量）。情况下
• 愿意依赖Cassandra内置的反熵功能（例如阅读修复）

  

如果通知已发送给关注者，我需要确保用户可以收到评论。

由于您的大多数条目都是一次性写入，并且您更关心条目的存在而不一定是该条目的最新内容，因此您可能可以使用{{{ 1}}如果你没有记录某些某些其他迹象它应该存在（例如来自通知）的记录，则回退到WRITE ONE + READ ONE。对于时间轴条目内容，它听起来不像您的情况取决于时间线条目的用户内容的一致性。

如果你不关心一致性，那么这个讨论没有实际意义;使用任何一致性级别读/写，让Cassandra的异步复制和反熵功能完成它们的工作。也就是说，虽然您的目标是最大限度地减少网络流量/成本，但如果您的工作负载主要是读取，那么在CL READ ALL或{{}处执行写入的额外成本1}}可能实际上并没有那么多。

你也说过：

  

如果他们收听帖子，关注者会收到添加到帖子中的评论通知。

此声明表示您不仅关心关注者 是否存在，还关注其内容（用户正在关注） 。您还没有详细说明如何存储/跟踪关注者，但除非您确保此数据的一致性，否则一个或多个关注者可能未通知新的注释，因为您检索了跟随者列表的过时版本。或者，某人＆＃34;取消关注＆＃34;由于同样的原因，帖子仍然可以收到通知。

Cassandra非常灵活，允许每个离散的读写操作使用不同的一致性级别。充分利用这一点，并确保在需要的地方保持一致性，并在您确定＆＃34;阅读最新的写入＆＃34;对你的应用程序的逻辑和功能来说并不重要。