處理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重試查詢。 使用此策略，當所有節點都可用時，您的查詢將具有很強的一致性，如果某個節點發生故障，您將不會失去可用性。