分布式系統中乙個重要的問題就是資料複製，資料複製一般是為了增強系統的可用性或提高效能。而實現資料複製的乙個主要難題就是保持各個副本的一致性。本文首先討論資料複製的場景中一致性模型如此重要的原因，然後討論一致性模型的含義，最後分析常用的一致性模型。
資料複製主要的目的有兩個：可用性和效能。首先資料複製可以提高系統的可用性。在保持多副本的情況，有乙個副本不可用，系統切換到其他副本就會恢復。常用的 mysql 主備同步方案就是乙個典型的例子。另一方面，資料複製能夠提供系統的效能。當分布式系統需要在伺服器數量和地理區域上進行擴充套件時，資料複製是乙個相當重要的手段。有了多個資料副本，就能將請求分流；在多個區域提供服務時，也能通過就近原則提高客戶端訪問資料的效率。常用的 cdn 技術就是乙個典型的例子。 但是資料複製是要付出代價的。資料複製帶來了多副本資料一致性的問題。乙個副本的資料更新之後，其他副本必須要保持同步，否則資料不一致就可能導致業務出現問題。因此，每次更新資料對所有副本進行修改的時間以及方式決定了複製代價的大小。全域性同步與效能實際上是矛盾的，而為了提高效能，往往會採用放寬一致性要求的方法。因此，我們需要用一致性模型來理解和推理在分布式系統中資料複製需要考慮的問題和基本假設。
資料儲存：在分布式系統中指分布式共享資料庫、分布式檔案系統等。
讀寫操作：更改資料的操作稱為寫操作（包括新增、修改、刪除），其他操作稱為讀操作。
下面是一致性模型的定義：一致性模型本質上是程序與資料儲存的約定：如果程序遵循某些規則，那麼程序對資料的讀寫操作都是可預期的。
一致性模型主要可以分為兩類：能夠保證所有程序對資料的讀寫順序都保持一致的一致性模型稱為強一致性模型，而不能保證的一致性模型稱為弱一致性模型。
線性一致性也叫嚴格一致性（strict consistency）或者原子一致性（atomic consistency），它的條件是：
任何一次讀都能讀取到某個資料最近的一次寫的資料。所有程序看到的操作順序都跟全域性時鐘下的順序一致。
線性一致性是對一致性要求最高的一致性模型，就現有技術是不可能實現的。因為它要求所有操作都實時同步，在分布式系統中要做到全域性完全一致時鐘現有技術是做不到的。首先通訊是必然有延遲的，一旦有延遲，時鐘的同步就沒法做到一致。當然不排除以後新的技術能夠做到，但目前而言線性一致性是無法實現的。
任何一次讀寫操作都是按照某種特定的順序。所有程序看到的讀寫操作順序都保持一致。
首先我們先來分析一下線性一致性和順序一致性的相同點在**。他們都能夠保證所有程序對資料的讀寫順序保持一致。線性一致性的實現很簡單，就按照全域性時鐘（可以簡單理解為物理時鐘）為參考係，所有程序都按照全域性時鐘的時間戳來區分事件的先後，那麼必然所有程序看到的資料讀寫操作順序一定是一樣的，因為它們的參考係是一樣的。而順序一致性使用的是邏輯時鐘來作為分布式系統中的全域性時鐘，進而所有程序也有了乙個統一的參考係對讀寫操作進行排序，因此所有程序看到的資料讀寫操作順序也是一樣的。
那麼線性一致性和順序一致性的區別在**呢？通過上面的分析可以發現，順序一致性雖然通過邏輯時鐘保證所有程序保持一致的讀寫操作順序，但這些讀寫操作的順序跟實際上發生的順序並不一定一致。而線性一致性是嚴格保證跟實際發生的順序一致的。
因果一致性是一種弱化的順序一致性模型，因為它將具有潛在因果關係的事件和沒有因果關係的事件區分開了。那麼什麼是因果關係？如果事件 b 是由事件 a 引起的或者受事件 a 的影響，那麼這兩個事件就具有因果關係。 舉個分布式資料庫的示例，假設程序 p1 對資料項 x 進行了寫操作，然後程序 p2 先讀取了 x，然後對 y 進行了寫操作，那麼對 x 的讀操作和對 y 的寫操作就具有潛在的因果關係，因為 y 的計算可能依賴於 p2 讀取到 x 的值（也就是 p1 寫的值）。 另一方面，如果兩個程序同時對兩個不同的資料項進行寫操作，那麼這兩個事件就不具備因果關係。無因果關係的操作稱為併發操作。這裡只是簡單陳述了一下，深入的分析見我之前寫的文章《分布式系統：向量時鐘》。 因果一致性的條件包括：
所有程序必須以相同的順序看到具有因果關係的讀寫操作。不同程序可以以不同的順序看到併發的讀寫操作。
下面我們來分析一下為什麼說因果一致性是一種弱化的順序一致性模型。順序一致性雖然不保證事件發生的順序跟實際發生的保持一致，但是它能夠保證所有程序看到的讀寫操作順序是一樣的。而因果一致性更進一步弱化了順序一致性中對讀寫操作順序的約束，僅保證有因果關係的讀寫操作有序，沒有因果關係的讀寫操作（併發事件）則不做保證。也就是說如果是無因果關係的資料操作不同程序看到的值是有可能是不一樣，而有因果關係的資料操作不同程序看到的值保證是一樣的。
最終一致性是更加弱化的一致性模型，因果一致性起碼還保證了有因果關係的資料不同程序讀取到的值保證是一樣的，而最終一致性只保證所有副本的資料最終在某個時刻會保持一致。從某種意義上講，最終一致性保證的資料在某個時刻會最終保持一致就像是在說：「人總有一天會死」一樣。實際上我們更加關心的是：
「最終」到底是多久？通常來說，實際執行的系統需要能夠保證提供乙個有下限的時間範圍。多副本之間對資料更新採用什麼樣的策略？一段時間內可能資料可能多次更新，到底以哪個資料為準？乙個常用的資料更新策略就是以時間戳最新的資料為準。
由於最終一致性對資料一致性的要求比較低，在對效能要求高的場景中是經常使用的一致性模型。
前面我們討論的一致性模型都是針對資料儲存的多副本之間如何做到一致性，考慮這麼一種場景：在最終一致性的模型中，如果客戶端在資料不同步的時間視窗內訪問不同的副本的同乙個資料，會出現讀取同乙個資料卻得到不同的值的情況。為了解決這個問題，有人提出了以客戶端為中心的一致性模型。以客戶端為中心的一致性為單一客戶端提供一致性保證，保證該客戶端對資料儲存的訪問的一致性，但是它不為不同客戶端的併發訪問提供任何一致性保證。舉個例子：客戶端 a 在副本 m 上讀取 x 的最新值為 1，假設副本 m 掛了，客戶端 a 連線到副本 n 上，此時副本 n 上面的 x 值為舊版本的 0，那麼一致性模型會保證客戶端 a 讀取到的 x 的值為 1，而不是舊版本的 0。一種可行的方案就是給資料 x 加版本標記，同時客戶端 a 會快取 x 的值，通過比較版本來識別資料的新舊，保證客戶端不會讀取到舊的值。
以客戶端為中心的一致性包含了四種子模型：
單調讀一致性（monotonic-read consistency）：如果乙個程序讀取資料項 x 的值，那麼該程序對於 x 後續的所有讀操作要麼讀取到第一次讀取的值要麼讀取到更新的值。即保證客戶端不會讀取到舊值。
單調寫一致性（monotonic-write consistency）：乙個程序對資料項 x 的寫操作必須在該程序對 x 執行任何後續寫操作之前完成。即保證客戶端的寫操作是序列的。
讀寫一致性（read-your-writes consistency）：乙個程序對資料項 x 執行一次寫操作的結果總是會被該程序對 x 執行的後續讀操作看見。即保證客戶端能讀到自己最新寫入的值。
寫讀一致性（writes-follow-reads consistency）：同乙個程序對資料項 x 執行的讀操作之後的寫操作，保證發生在與 x 讀取值相同或比之更新的值上。即保證客戶端對乙個資料項的寫操作是基於該客戶端最新讀取的值。
資料複製導致了一致性的問題，為了保持副本的一致性可能會嚴重地影響效能，唯一的解決辦法就是放鬆一致性的要求。通過一致性模型我們可以理解和推理在分布式系統中資料複製需要考慮的問題和基本假設，便於結合具體的業務場景做權衡。每種模型都有效地限制了對乙個資料項執行度操作應返回的值。通常來說限制越少的模型越容易應用，但一致性的保證就越弱。
《分布式系統原理與范型》
分布式三 雲計算 分布式系統范型
雲計算是乙個新技術，同時也是乙個新概念，乙個新模式，而不是單純的指某項具體的應 用和標準。方便 按需 2.雲計算分類 1 按照是否公開發布服務分類 訪問物件 公有雲 所有客戶 私有雲 企業內部 混合雲 重點 2 按照服務模式，雲計算可以分為 iaas paas saas三種型別。iaas infra...
分布式計算范型
1 訊息傳遞范型 訊息傳遞是程序間通訊的基本途徑。兩個程序間傳遞訊息，乙個為傳送者，乙個為接收者。傳送者傳送一條請求訊息，該訊息被傳送到接收者，由接收著處理後返回一條應答訊息。2 客戶 伺服器范型 網路應用中使用最多的一種分布式計算型別。由客戶端和伺服器組成，將非對稱角色分配各兩個協作程序，客戶程序...
分布式計算范型
布式計算范型 1 訊息傳遞范型 1 訊息傳遞泛型 2 訊息系統泛型 2 客戶 伺服器傳遞范型 當前最流行的網際網路應用www 或稱為萬維 網 是基於客戶 伺服器范型的乙個典型分布式應用 3 p2p范型 在p2p網路中，每個使用者端既是乙個節點，又有伺服器的功能，任何乙個節點無法直接找到其他節點，必須...