处理Cassandra的最终一致性

Question

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

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

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

非常感谢帮助。

Answer 1

读取很有可能成功

查看DowngradingConsistencyRetryPolicy此策略允许以低于初始CL的CL重试查询。 使用此策略，当所有节点都可用时，您的查询将具有很强的一致性，如果某个节点发生故障，您将不会失去可用性。