附件C-一致性模型
對一致性模型的描述主要從三個出發點進行考慮：
(1)響應前還是響應後，即在完成對所有副本數據集的同步前返回用戶，還是完成同步後再給用戶反饋。
(2)進行同步對象的多少，是對每次更新進行同步還是在多次更新後再同步。
(3)對更新順序的維護，維護更新操作間不同的順序會提供不同的一致性，當完全不考慮更新順序，甚至更新的類型時，只提供最終數據的相互一致，則是最終一致性。
1.相互一致性
文獻[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。
2.強一致性
強一致性爲：任意一個客戶端做的更新，其它客戶端在後續的訪問中都能獲得
我們從最簡單的一致性模型開始，然後一步步增加問題的複雜性。最簡單的一致性模型應該就是隻有單一服務器，多客戶端模型，如上圖所示。垂直線表示真實時間。含有箭頭的線段表示從一臺電腦發送給另一臺電腦的消息，線段的傾斜角度表示網絡延遲，傾斜角度大，說明該消息從發送節點到達接收節點經過的時間長，故網絡延遲大。上圖我們忽略掉服務器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對外不提供服務。
3.弱一致性
爲了提高系統的可用性，在許多應用中會放鬆對一致性的需求。下面先來看一個例子，從而說明什麼是弱一致性。然後將說明不同約束下的弱一致性。
上圖中，完成多副本間的同步也需要一定的時間，但在這個時間內，系統對外一直提供服務。不過C2並不能在C1提交完更新後就獲得最新的更新內容，C2會獲得數據對象1的歷史數據。我們稱不同副本完成同步需要的時間爲系統的不一致窗口。如上圖，兩條虛線間表示不一致窗口
弱一致性指，系統無法提供在更新完成後，任意節點都會立即獲得最新的更新內容。
3.1 Read-your-write
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約束。
3.2 Session consistency
Session一致性是read-your-write的一個特例。C1首先提交了write(1,5),隨後提交了read(1)，如果這兩個請求在同一個session的作用範圍內，那麼C1將看到自己之前提交的更新。如上圖虛線方框內的連續兩個請求。如果C1的寫、讀兩個請求並不在同一個session範圍內，那麼系統將不能保證後面的讀請求一定會獲取前面寫請求的更新值。這裏有多種原因爲造成這樣的結果。比如，兩個副本節點完成同步的時間大於Session的有效期，並且C1的read(1)被負載到了未完成同步的節點。如上圖，代箭頭的虛線就是落在session一致性約束外的請求，獲取的返回值可能是（1,0）或者（1,5）。
3.3 單調讀一致性Monotonic read consistency
單調一致性指，當一個客戶端在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。
3.4 單調寫一致性Monotonic write 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)。
3.5 因果一致性Causal consistency
前面描述的弱一致性，一直是對從一個客戶端的角度分析。如果兩個客戶端的操作存在一定的先後順序，該如何保證一致性。因果一致性就是對來自不同客戶端，存在先後的請求提供一致性保證。
因果一致性，指如果不同客戶端的請求存在先後順序，那麼多副本系統對請求的返回結果也要符合該請求間的先後順序。
如上圖，C1發送請求write(1,5)，然後C1通知C2它完成更新（點線表示該通知），這時C2發送請求read(1)。如果系統對C2的read(1)返回（1,5），則該系統遵從了因果一致性，如果系統返回(1,0)則該系統併爲提供因果一致性。對於無請求先後順序關係的客戶端，如C3節點，同樣請求read(1)，系統將不提供任何一致性保證，C3獲得的返回值可能是（1,0）,也可能是(1,5)。
4.最終一致性
最終一致性是弱一致性的特例[73]。弱一致性對更新操作在不同副本節點間的傳播順序，以及執行順序進行了約束，從而實現不同的弱一致性。最終一致性對於不同副本節點間傳播的更新，執行順序沒有任何約束，甚至在節點間傳播的更新並不總是用戶在客戶端直接執行的更新操作。最終一致性，只要求如果對於數據對象不再有任何更新後，那麼最終所有的訪問都將獲得最後更新的值。