對一致性模型的描述主要從三個出發點進行考慮：
(1)響應前還是響應後，即在完成對所有副本資料集的同步前返回使用者，還是完成同步後再給使用者反饋。
(2)進行同步物件的多少，是對每次更新進行同步還是在多次更新後再同步。
(3)對更新順序的維護，維護更新操作間不同的順序會提供不同的一致性，當完全不考慮更新順序，甚至更新的型別時，只提供最終資料的相互一致，則是最終一致性。
文獻[70]
對一致性的定義為，設定在資料上的約束。這種約束在不同應用中是不同的。違反這樣的約束就稱違反了資料的一致性。對於分布式中，複製技術最重要的約束就是副本節點資料的相互一致。請求對乙個副本上的資料進行了修改，如果系統沒有及時的將更新傳播並應用到其它節點，路由到其它節點的請求就會獲取到不一致的資料內容。維護節點間的相互一致性就稱為了複製系統的關鍵。同時一致性模型也是資料同步的重要模型。
yu和vahdat 2002[13]
為定義副本間的不一致性判斷設計了三個相互獨立的座標軸：副本之間的數值偏差、副本之間新舊程度的偏差以及更新操作順序的偏差。資料具有數值語義的應用程式可以按數值偏差來度量不一致性。例如，**市場**記錄的複製。在這種應用中，應用程式可能會指定兩個副本的偏差不能超過0.02美元，這就是絕對數值偏差。也可以指定相對數值偏差，表示兩個副本之間的差別不能超過多少（0.5%）新舊偏差與副本最近一次更新有關。多某些應用程式來說，只要副本提供的舊資料不是太舊，它是可以容忍的。例如，天氣預報通常要滯後一段時間（如幾個小時）。在這種情況下，主伺服器會定期地接收更新訊息，但在一段時間內只給副本傳送一次更新資訊。在有些應用程式中，只要可以界定副本之間的差異，就允許不同的副本採用不同的更新順序。
下面我們來談一談不同的一致性約束。不同的一致性約束是系統對外提供服務的不同特性，開發人員在使用乙個儲存系統前，最先應當了解該系統提供的一致性約束。
我們這裡對於一致性約束的描述是以客戶端-伺服器為模型[52,73]
。站在客戶端的角度來分析客戶端自己所做的更新在不同一致性約束下的不同表現結果。為了後續描述的簡單，我們這裡做一些約定。c表示客戶端，c1,c2,c3個客戶端。s表示伺服器，s1和s2兩個伺服器。資料物件的編址為1,2,3,4，即有四個資料物件。對資料的讀操作為read(i)括號內i為資料的編址。對資料的寫操作為write(i,n)，i為資料的編址，n為寫入的數值。為了描述單調寫一致性，支援write(i,++)操作，即對編址為i的資料進行自動加1操作。所有編址內資料的初始值為0。
強一致性為：任意乙個客戶端做的更新，其它客戶端在後續的訪問中都能獲得
我們從最簡單的一致性模型開始，然後一步步增加問題的複雜性。最簡單的一致性模型應該就是只有單一伺服器，多客戶端模型，如上圖所示。垂直線表示真實時間。含有箭頭的線段表示從一台電腦傳送給另一台電腦的訊息，線段的傾斜角度表示網路延遲，傾斜角度大，說明該訊息從傳送節點到達接收節點經過的時間長，故網路延遲大。上圖我們忽略掉伺服器s1執行操作的時間。c2的read(1)請求在c1的write(1,5)之後進行，所以將獲得最新的更新內容（1,5）。同理c1的read(2)在c2的write(2,7)之後進行，將獲得最新的更新內容（2,7）。
增加一台伺服器，同時每個資料物件存在兩個副本，分別放置在兩台伺服器上。由於更新需要應用在多個副本上，所以更新的執行時間就不能被忽略。從圖中我們可以看到，c2多次請求資料物件1的內容。當read（1）請求在副本節點執行同步前進行，會返回（1，0）。當伺服器正在執行同步時收到請求，則將不返回內容給c2,或者可以返回提示資訊表示資料正在同步。當伺服器完成同步後，c2的read(1)請求會得到最新的更新值（1,5）。
在多副本的系統中，系統為了保證對外提供資料的強一致性，必然會在系統的可用性上做出一定的犧牲。上圖中，對於資料物件1系統在各個服務進行同步的過程中，資料物件1對外不提供服務。
為了提高系統的可用性，在許多應用中會放鬆對一致性的需求。下面先來看乙個例子，從而說明什麼是弱一致性。然後將說明不同約束下的弱一致性。
上圖中，完成多副本間的同步也需要一定的時間，但在這個時間內，系統對外一直提供服務。不過c2並不能在c1提交完更新後就獲得最新的更新內容，c2會獲得資料物件1的歷史資料。我們稱不同副本完成同步需要的時間為系統的不一致視窗。如上圖，兩條虛線間表示不一致視窗
弱一致性指，系統無法提供在更新完成後，任意節點都會立即獲得最新的更新內容。
c1在提交完write(1,5)更新請求後，緊接著提交了read(1)請求。read-your-write一致性的約束，是保證c1將會看到自己所做的更新，即c1將會讀取到（1,5）。
然後因為存在多個副本節點，c1首先提交的write(1,5)更新請求由s1執行，但是c1隨後提交的read(1)請求不一定會在s1上執行。如上圖，兩條虛線表示不一致視窗。代箭頭的虛線表示read(1)由s2執行，此時s2未完成對資料物件1的同步，那麼c1將會訪問到資料物件1的舊值（1，0），這就違反了read-your-write約束。
一致性是read-your-write的乙個特例。c1首先提交了write(1,5),隨後提交了read(1)，如果這兩個請求在同乙個session的作用範圍內，那麼c1將看到自己之前提交的更新。如上圖虛線方框內的連續兩個請求。如果c1的寫、讀兩個請求並不在同乙個session範圍內，那麼系統將不能保證後面的讀請求一定會獲取前面寫請求的更新值。這裡有多種原因為造成這樣的結果。比如，兩個副本節點完成同步的時間大於session的有效期，並且c1的read(1)被負載到了未完成同步的節點。如上圖，代箭頭的虛線就是落在session一致性約束外的請求，獲取的返回值可能是（1,0）或者（1,5）。
單調一致性指，當乙個客戶端在read請求時獲得了某乙個特定的值，該客戶端隨後的read請求不允許獲得該資料物件之前的舊值。上圖，客戶端c1先後執行write(1,5)和read(1)，得到(1,5)。然後c1再多次傳送read(1)請求，如果後續的read(1)請求返回的結果都是(1,5)那麼就稱系統遵循了monotonic read consistency。但是如上圖，代箭頭虛線所示，c1後續的read(1)請求的返回結果為（1，0），這就違反了monotonic read consistency。
單調寫一致性，指對於同乙個客戶端，它連續的寫操作是基於前面寫操作的結果進行。上圖中，c1發起連續的兩個寫操作，分別是write(1,5),write(1,++)，即先將資料物件1設定為5，然後讓資料物件1完成自動加1操作。正確的執行結果應該是（1,6）。
上圖中在右側（1,5）（1,0）表示，當某一副本節點執行完c1請求時，在兩個副本節點上資料物件1的值。例如，當c1提交write(1,5)，s1完成操作，s2未完成同步，則此時的資料物件1在s1上為（1,5），在s2上為(1,0)。
如果c1第二個寫請求write(1,++)，仍由s1執行，則c1將會看到的正確的執行結果（1,6）。但是如果請求由s2執行，c1將會看到（1,1）這樣的結果，這樣就違反了單調寫一致性。
當然，在s1和s2完成同步後，write(1,++)由s2執行，c1仍可以看到正確的執行結果(1,6)。
前面描述的弱一致性，一直是對從乙個客戶端的角度分析。如果兩個客戶端的操作存在一定的先後順序，該如何保證一致性。因果一致性就是對來自不同客戶端，存在先後的請求提供一致性保證。
因果一致性，指如果不同客戶端的請求存在先後順序，那麼多副本系統對請求的返回結果也要符合該請求間的先後順序。
如上圖，c1傳送請求write(1,5)，然後c1通知c2它完成更新（點線表示該通知），這時c2傳送請求read(1)。如果系統對c2的read(1)返回（1,5），則該系統遵從了因果一致性，如果系統返回(1,0)則該系統並為提供因果一致性。對於無請求先後順序關係的客戶端，如c3節點，同樣請求read(1)，系統將不提供任何一致性保證，c3獲得的返回值可能是（1,0）,也可能是(1,5)。
最終一致性是弱一致性的特例[73]
。弱一致性對更新操作在不同副本節點間的傳播順序，以及執行順序進行了約束，從而實現不同的弱一致性。最終一致性對於不同副本節點間傳播的更新，執行順序沒有任何約束，甚至在節點間傳播的更新並不總是使用者在客戶端直接執行的更新操作。最終一致性，只要求如果對於資料物件不再有任何更新後，那麼最終所有的訪問都將獲得最後更新的值。
來自為知筆記(wiz)
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
記憶體一致性模型
cache coherence 本文主要討論的是記憶體一致性問題 memory consistency 和快取一致性 cache coherence 是不同的。在 計算機體系結構 量化方法研究 第五章中，memory consistency是由cache coherence引出的，所以我們就先來說說...
一致性hash演算法 面試必備 一致性hash演算法
最近公司在招人，我們準備的問題中有一道是關於一致性hash演算法的問題，只有一些面試者能夠回答上來，而且答的也不是很全面，有的面試者只是聽說過，有的連聽都沒聽過，下面我把一致性hash演算法整理一下分享給大家 一致性雜湊演算法在1997年由麻省理工學院的karger等人在解決分布式cache中提出的...