如何計算最終一致性需要多久才能保持一致？

Question

我開始調查nosql和麪向文檔的數據庫來存儲我們將在我們的網站上提供的HTML5應用程序的資產。這是爲了替換文件系統上的文件。它們將是小型的網頁優化文件，包括html，js，css和xml等文本文件，以及圖像，聲音和字體等二進制文件。

因爲我對容錯感興趣，所以我在看的解決方案（riak，Cassandra）使用最終的一致性。雖然我在抽象層面理解概念，但當我與經理和決策者交談時，我無法用實際的術語解釋最終一致性需要多長時間才能保持一致。毫秒？秒？分鐘？由於我在這個領域沒有任何經驗，所以我正在尋找真實世界的經驗。

我知道不同的變量將確定任何配置需要多長時間，但我需要能夠開始瞭解需要構建哪些基礎結構以支持我們的需求。所以我在尋找的是如果我們需要優化網絡延遲，節點數量等來支持我們的特定需求。

我們希望能夠選擇要測試的平臺，在我們陷入任何特定解決方案之前，我們希望能夠說「不，這不適用於我們。 「

我們的系統現在使用嚴格的一致性（例如我們的web服務器和我們的mysql數據庫上的文件系統），所以我們的管理習慣於像加載和超時這樣的概念，而事情正在「停滯」。但我無法與他們溝通「是的，數據不可用現在，但它並沒有關閉;它將可用最終」。他們想知道「那麼，最終'多久'？」

我該如何判斷一個最終一致的系統是否能夠實際運行於我們的網站？

Answer 1

由於我比卡桑德拉更加熟悉Riak，因此我將討論Riak的最終一致性如何應用。

在正常運行期間，Riak支持tuneable consistency，它允許您針對您的應用程序要求定製一致性行爲。然而，默認設置非常明智，適用於大多數場景，因爲它們需要大部分replicas才能在讀取或寫入之前對其進行響應，才能被視爲成功。

雖然所有複製品可能不會在每個時間點處於完全相同的狀態，但這些一致性設置將確保您閱讀所寫內容。不一致性通常在通過名爲read-repair的過程進行讀取時得到糾正，但如果啓用了主動反熵（Riak版本1.3中的新功能），也可以定期進行糾正。

Eventual consistency主要在各種故障情況下被考慮。如果例如一個節點與羣集的其餘部分分離，它將（使用默認設置）繼續能夠接受寫入和讀取，它將根據其保存的數據/副本盡其所能地發揮作用。由於在此期間無法與羣集的其他部分進行通信，因此可能會出現不一致。但是，一旦羣集恢復到正常運行狀態，這些問題就會得到解決。這可能需要多長時間取決於許多外部因素，如果需要手動干預來糾正問題，可能需要幾分之一秒的時間來處理臨時網絡故障，或者幾分鐘或幾小時。