- 強一致性：要求無論更新操作是在哪個資料副本上執行，之後所有的讀操作都要能獲得最新的資料。對於單副本資料來說，讀寫操作是在同一資料上執行的，容易保證強一致性。對多副本資料來說，則需要使用分散式事務協定(如兩階段提交或Paxos)。
- 弱一致性：在這種一致性下，用戶讀到某一操作對系統特定資料的更新需要一段時間，我們將這段時間稱為“不一致性視窗”。
- 最終一致性：是弱一致性的一種特例，在這種一致性下系統保證使用者最終能夠讀取到某操作對系統特定資料的更新(讀取操作之前沒有該資料的其他更新操作)。此種情況下，如果沒有發生失敗，“不一致性視窗”的大小依賴於交互延遲、系統的負載，以及複製技術中replica的個數(這個可以理解為master/slave模式中，slave的個數)。DNS系統可以說是在最終一致性方面最出名的系統，當更新一個功能變數名稱的IP以後，根據配置策略以及緩存控制策略的不同，最終所有的客戶都會看到最新的值。
最終一致性模型根據其提供的不同保證可以劃分為更多的模型。
- 因果一致性(Causal Consistency)：假如有相互獨立的A、B、C三個進程對資料進行操作。進程A對某資料進行更新後並將該操作通知給B，那麼B接下來的讀操作能夠讀取到A更新的資料值。但是由於A沒有將該操作通知給C，那麼系統將不保證C一定能夠讀取到A更新的資料值。
- 讀自寫一致性(Read Your Own Writes Consistency)：這個一致性是指使用者更新某個資料後讀取該資料時能夠獲取其更新後的值，而其他的使用者讀取該資料時則不能保證讀取到最新值。
- 會話一致性(Session Consistency)：是指讀取自寫更新一致性被限制在一個會話的範圍內，也就是說提交更新操作的用戶在同一個會話裡讀取該資料時能夠保證資料是最新的。
- 單調讀一致性(Monotonic Read Consistency)：是指使用者讀取某個資料值，後續操作不會讀取到該資料更早版本的值。
- 時間軸一致性(Timeline Consistency)：要求資料的所有副本以相同的循序執行所有的更新操作，另一種說法叫單調寫一致性(Monotonic Write Consistency)。
系統選擇哪種一致性模型取決於應用對一致性的需求，所選取的一致性模型還會影響到系統如何處理使用者的請求以及對副本維護技術的選擇等。
