如果所有副本最终都会同步，那么读取修复的重点是什么？

Question

如果所有副本最终都会同步，那么读取修复的重点是什么？

如果您有一个写入发送到所有副本的情况，那么您是否会遇到这样的情况，然后在写入之前进行读取修复，您不会基本上复制相同的写入两次吗？

Answer 1

有一些事情，阻止读取修复，异步读取修复，以及是否需要。

阻止读取修复：仲裁读取在一段时间内是单调一致的。如果你读了两遍，你应该得到相同的答案。人们倾向于使用QUORUM读取来获得更强的一致性，因此阻塞读取修复会阻止读取及时返回。如果此行为结束，则会对现有应用程序造成潜在意外。然而，这些修复的延迟影响已经引起问题，并且在不久的将来可能仍会改变。您目前无法禁用此行为，并且它始终处于打开状态。

异步读取修复：可以禁用或仅在一小部分时间内进行背景修复，或仅在DC内进行修复（推荐）。这减少了背景影响，因为没有多少交叉DC流量。这由dc_local和全局读取修复机会设置控制。当您执行ONE或LOCAL_ONE等查询时，它将依赖于等待其余响应的机会并比较读取修复的结果。

从统计上来说，您更有可能使用 async 进行不必要的工作，因为在正常运行的完美系统上不需要它们。然而，Hinted Handoff并不完美，并且有些提示会丢失。在这些情况下，在进行反熵修复之前不会满足一致性（应该是每周甚至每天，具体取决于修复运行，包括或完整等）。

除了单调一致性（阻止QUORUM +请求）之外，读取修复不非常关键或需要。人们已经习惯于在统计上将群集更快地（可能）置于更一致的状态。很多人在没有异步读取修复的情况下运行（你当前无法禁用读取修复机制fwiw），并且由于误解，甚至会serious talk of removing options around it completely。

Answer 2

对我来说有意义的一个场景是：

1. 您将数据写入节点（或群集的子集）
2. 您读取数据（使用Quorum），其中一个节点具有更新的数据。

因为您指定了QUROUM，所以在将响应发送到客户端之前，会要求多个节点提供该值。但由于数据在一个节点上更新，因此必须首先进行阻塞读取修复，以更新所有节点。

在这种情况下，需要进行读取修复，因为“最终更新”尚未发生。

Answer 3

在具有许多节点的高度动态应用程序中，有时候最终一致的写入不会在该节点上对该数据的读取请求之前进入节点。这在小型群集负载较重的环境，未知硬件问题和其他原因中很常见。也可能将写入一致性设置为1，而读取一致性设置为local_quorum。

示例1：随机＆amp;由于未知网络交换机故障导致的零星网络丢失会影响对节点的写入，但不会影响读取。

示例2：写入发生在峰值加载时间段内，因此在读取请求之前不会使其进入过载节点。