处理Cassandra中的最终一致性

Question

我有一个带有RF=2的3节点cassandra集群，读取一致性级别，称为CL，设置为1。

我知道无论何时CL=1，当对Cassandra执行读操作时，如果它返回不一致的数据，读修复就会发生。我喜欢使用CL=1而不是将其设置为2的想法，因为这样即使节点出现故障，我的系统也可以正常运行。通过CAP定理思考，我希望我的系统是AP而不是CP。读请求很少(更像是每秒2-3次)，但对业务非常重要。它们是针对类似日志的数据执行的(该数据是不可变的，因此永远不会更新)。我的临时解决方案是多次运行查询，比如运行3次，而不是运行一次。这样，我可以确定即使我在第一次读请求中没有得到我的数据，系统也会触发读修复，我最终会在第二次或第三次读请求中获得我的数据。当然，这3个查询一个接一个地发生，没有任何阻塞。

有没有什么方法可以让Cassandra在后台执行读取修复，而不需要实际执行读取请求来触发修复？基本上，我正在寻找一种方法来调整我的系统，以规避“最终一致性”模型，通过该模型，我的阅读将有很高的成功概率。

我们将非常感谢您的帮助。

Answer 1

读取成功的概率很高

看看DowngradingConsistencyRetryPolicy这个策略允许用比初始查询更低的CL重试查询。