本文是摘取了一些Werner Vogels關於最終一致性博客內容進行翻譯，並在有些地方重新組織，加上了自己理解。
一致性問題的歷史發展
完美的一致性模型是：當做了一個更新操作，所有的觀察者將看到這個更新。
服務器端一致性
一致性問題的歷史發展
完美的一致性模型是：當做了一個更新操作，所有的觀察者將看到這個更新。
在70年代後期的數據庫系統，這個完美的一致性模型第一次被認爲很難達到。
在90年代中期，隨着更大規模的互聯網系統的出現，許多之前的實踐被修正。人們開始思考有效性可能不是系統最重要的特性，同時他們在努力尋找什麼應該被權衡考慮。
在2000年 Principles of Distributed Computing大會上Eric Brewer發表了CAP理論。CAP理論：共享數據系統的三個特性-數據一致性、系統有效性、分區容忍性- 在任何給定時間，只能有其中兩個能夠達到。
在2002年, Seth Gilbert和Nancy Lynch發表了更加正式的CAP理論論證。
CAP理論的討論：
| Data Consistency（數據一致性） | System Availibility(系統有效性） | Tolerance to network partition（分區容忍性) | 說明 |
| 不滿足 | 在事務協議中，客戶端和存儲系統必須在相同的環境中。在某些場景中，他們會爲一個整體失敗。正是這樣，客戶端不能觀察多個分區。 | ||
| 滿足 | 在大規模的分佈式系統，需要實現網絡分區，因此一致性和有效性不能同時達到。 要麼犧牲一致性，獲得高有效性； 要麼犧牲有效性，獲得一致性。 客戶端開發人員需要意識到系統是哪一種選擇。 |
||
| 滿足 | 不滿足 | 滿足 | 如果系統強調一致性，開發人員需要處理系統無效的情況。 例如，寫操作。如果因爲系統無效導致寫失敗，那麼開發者將需要處理那些需要被寫入的數據。 |
| 不滿足 | 滿足 | 滿足 | 如果系統強調有效性，它可能會總是接收寫操作，但是在有些條件下，讀操作將不能返回最近寫操作的結果。 開發人員需要決定客戶端是否總是需要訪問最近的更新。 |
在2007年，Werner Vogels提出了最終一致性。並在2008年進行了修正發表在ACM Queue中。
一致性-客戶端和服務器端
有兩種衡量一致性的方式，
客戶端一致性：從開發者/客戶端的角度：他們如何觀察數據更新。
服務器端一致性：從服務器端的角度：更新時如何流經系統，和系統對更新有和保證。
客戶端一致性
強一致性：在更新操作完成之後，任何後續的訪問將返回更新的值。
弱一致性：系統不能保證後續訪問返回更新的值。需要在一些條件滿足之後，更新的值才能返回。從更新操作開始，到系統保證任何觀察者總是看到更新的值的這期間被稱爲不一致窗口。
最終一致性：這是弱一致性的特殊形式；存儲系統保證如果沒有對某個對象的新更新操作，最終所有的訪問將返回這個對象的最後更新的值。
最終一致性模型有如下對考慮者很重要的變種。在基本的最終一致性模型規則上加上了一些額外的規定。
因果一致性：如果進程A通知進程B它已經更新了一個數據項，那麼進程B的後續訪問將返回更新後的值，並且寫操作將被保證取代前一次寫入。和進程A沒有因果關係的C的訪問將遵循正常的最終一致性規則。
讀己之所寫一致性：這是一個重要的模型。進程A更新了一個數據項之後，總是訪問到更新後的值而不會看到舊值。這是因果一致性模型的一個特例。
會話一致性：這是上一個模型的實用版本。進程在一個會話上下文中訪問存儲系統。只要會話存在，系統保證讀己之所寫一致性。如果會話由於某個失敗場景而終止，一個新的會話需要被創建，並且保證不和之前會話重疊。
單調讀一致性：如果一個進程已經看到某個對象的一個特定的值，那麼任何後續的訪問將不會 返回任何先前的值。
單調寫一致性：系統保證在同一個進程中串行化寫操作。不能保證這種一致性級別的系統是衆所周知地難以編程。
這些屬性可以組合起來。例如，單調讀和會話一致性可以組合在一起。
在服務器端，我們需要更加深入地分析更新是如何流經系統，並由此來理解什麼驅動了不同模式。這些模式正是系統的開發者能夠體驗到的。讓我們先作如下定義。
N=存儲數據副本的結點數量
W=在更新完成之前，需要同時認可接收的副本數量
R=當讀操作訪問數據對象，需要訪問的副本數量
如果W+R>N, 那麼寫集合和讀集合總是重疊並且能保證強一致性。 如在主備RDBMS中，如果使用了同步副本的方式，N=2，W=2和R=1。不管客戶端讀哪個副本，它總是獲得一致性結果。
如果W+R<=N, 那麼不能保證強一致性，只能是弱一致性或最終一致性。如在主備RDBMS中，使用異步同步副本，並開啓從副本讀功能的方式，那麼N=2, W=1和R=1。在這種情況下，R+W=N, 一致性不能得到保證。
