如果所有副本最终都会同步，那么读取修复有何意义？
是否会出现这样的情况:如果您有一个写入被发送到所有副本，然后在写入之前发生读取修复，那么您实际上不会将相同的写入复制两次吗？
最佳答案
有一些事情，阻止读取修复、异步读取修复以及是否需要其中任何一个。
阻止读取修复:仲裁读取暂时保持单调一致。如果你读两遍，你应该得到相同的答案。人们倾向于使用 QUORUM 读取来获得更强的一致性，因此阻塞读取修复会阻止读取及时返回。如果这种行为结束，将会给现有应用程序带来潜在的意外。然而，这些修复的延迟影响已经引起了问题，并且在不久的将来仍然可能会发生变化。您当前无法禁用此行为，它将始终处于开启状态。
异步读取修复:后台修复可以被禁用或仅在一小部分时间内发生，或者(推荐)仅在 DC 内进行。这减少了背景影响，因为没有太多的跨 DC 流量。这是由 dc_local 和全局读取修复机会设置控制的。当您执行 ONE 或 LOCAL_ONE 等查询时，它将根据该机会等待其余响应并比较读取修复的结果。
据统计，您更有可能对异步读取修复进行不必要的工作，因为在正常运行的完美系统上不需要它们。然而，提示切换并不完美，并且存在提示丢失的情况。在这些情况下，只有运行反熵修复才能满足一致性(应该每周甚至每天一次，具体取决于修复的运行方式，包括或完整等)。
因此，除了为了单调一致性(阻塞 QUORUM+ 请求)之外，读修复并不是真正重要或需要的。人们用它来统计地使集群更快(也许)处于更一致的状态。很多人在没有异步读取修复的情况下运行(您当前无法禁用读取修复机制fwiw)，甚至还有serious talk of removing options around it completely由于误解。
关于cassandra - 如果所有副本最终都会同步，那么读取修复有何意义？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46479097/