分布式一致性

分布式系統的乙個重要問題是資料的複製。對資料的複製一般有兩個原因：

資料複製的主要難題是保持各個副本的一致性。即在更新乙個副本時，必須確保同時更新其他的副本，否則資料的各個副本將不再相同。

一致性模型實質上是程序和資料儲存之間的乙個約定。正常情況下，乙個資料項上執行讀操作時，它期待該操作返回的是該資料在其最後一次寫操作之後的結果。在沒有全域性時鐘的情況下，精確的定義哪次寫操作是最後一次寫操作是十分困難的。於是就產生了一系列用其他方式定義的一致性模型。

2.1 持續一致性

有人提定義了區分不一致性的三個互相獨立的座標軸：副本之間的數值偏差，副本之間新舊程度偏差以及更新操作順序的偏差。

數值偏差可以這樣理解：已應用於其他的副本，但還沒有應用於給定副本的更新數目。

文中使用了向量時鐘來舉例對一致性單元進行持續抑制性分析，

2.2 嚴格一致性

任意 read(x)操作都要讀到最新的 write(x)的結果。

依賴於絕對的全域性時鐘，實際系統不可能做到。

2.3 順序一致性

對於一些讀寫寫操作的集合，所有程序看到的都是同樣的順序。也就是將並行的操作序列化，而且每個程序得到的序列都相同。

那麼，很自然對於同乙個程序執行的操作，必然要按照它們執行的順序出現。

2.4 因果一致性（casual consitency）

要求：有因果關係的寫操作必須按照它們的因果關係的順序被看到，沒有因果關係的寫操作可以以任意順序被別的程序看到。

例如：(其中[….]是佔位符，表示沒有操作)

程序 1 w(x)a 將 x 寫成 a

程序 2 [..]r(x)a w(x)b

程序 3 [….]r(x)a r(x)b

程序 4 [….]r(x)b r(x)a

相比順序一致性，去掉了那些沒有聯絡的操作達成一致順序觀點的要求，只是保留那些必要的順序（有因果關係的）。

2.5 入口一致性（entry consistency）

其實也就是對每個共享資料定義乙個同步變數（即：鎖）。當然，沒有進行同步就進行的讀操作結果是不保證的。

也就是從使用者視角來看資料是一致的。只是關心資料最終會一致（eventually consitent）。

只要保證對於同乙個使用者，他訪問到的資料是一致的就可以了。如果使用者只是訪問乙個副本，這個就很好實現，否則就需要一定策略了。當沒有更多的更新的時候，要保證當前的更新會最終傳播到所有的副本上。著名的例子有：dns 系統，全球資訊網。

但最終一致性需要注意乙個典型的問題。即當客戶訪問不同的副本時，問題就出現了。更具體的例子比如，部落格作者更改了一篇博文內容，在 a 地的使用者先訪問到最新的內容，而 b 地由於離部落格伺服器遠，看到的還是原先的內容。

對於最終一致性的的資料儲存而言，這個示例很有代表性。問題是由使用者有時可能對不同的副本進行操作的事實引起的。以客戶為中心的一致性分為如下幾大類：

3.1 單調讀（monotonic reads）

當程序從乙個地方讀出資料 x，那麼這個以後再讀到的 x 應該是和當前 x 相同或比當前更新的版本。也就是如果程序遷移到了別的位置，那麼對 x 的更新應該比程序先到達。這裡的客戶就是指這個程序。

3.2 單調寫（monotonic writes）

跟單調讀相應，如果乙個程序寫乙個資料 x，那麼它在本地或者遷移到別的地方再進行寫操作的時候，原來的寫操作必須要先傳播到這個位置。也就是程序要在任何地方至少和上一次寫一樣新的資料。

3.3 read your writes

乙個程序對於資料 x 的寫操作，那麼程序無論到任何副本上都應該看到這個寫操作的影響，也就是看到和自己寫操作的影響或者更新的值。

3.4 writes follow reads

顧名思義了，也就是在讀操作後面的寫操作要是基於至少跟上一次讀出來一樣新的值。也就是如果程序在地點 1 讀了 x，那麼在地點 2 要寫 x 的副本的話，至少寫的時候應該是基於至少和地點 1 讀出的一樣新的值。

4.1 放置的三個方法

permanent replica/永久副本: 選幾個固定位置放置副本，映象呈現。

server-initiated/服務端發起: 服務端動態決定什麼時候向什麼地方分發副本，又稱 push cache

client-initiated/客戶端發起: 客戶端快取,client cache

4.2 更新傳播

4.2.1 傳播什麼？

4.2.2 誰來傳播

4.2.3 傳播協議？

4.3 複製協議（replication protocols）

4.3.1 遠端寫（remote-write）協議

對於資料 x 有乙個主副本，當沒有 x 副本的伺服器操作 x 的時候就會得到乙個 x 的副本。而有 x 副本的伺服器響應客戶讀請求的時候可以立刻返回。而當客戶進行寫操作的時候，寫操作首先在主副本完成，然後再通知其他副本更新。

4.3.2 本地寫（local-write）協議

和遠端寫比較類似，不同點是當乙個伺服器得到了副本以後就成了新的主副本，以後的寫操作首先在本地完成，然後再通知其他的副本，本地寫的名字由此而來。

4.3.3 主動複製（active replication）

對於副本的操作要設計到另外乙個單一物件。比如，n 個副本**物件 c 的乙個介面，如果向所有副本發出請求，每個副本都會發乙個請求到 c，那麼同樣的操作就執行了 n 次。所以需要乙個協調者。另外，多副本返回值的時候也會有同樣的情況。所以這種只執行一次的動作需要副本種有乙個協調者，保證操作只被執行一次或者只返回一次。

3.3.4 基於候選團（quorum-based）協議

也就是讀操作要得到 r 個伺服器的同意，寫操作要得到 w 個程序的同意。總共有 n 個程序。r 和 w 要滿足以下條件：

也就是類似於投票獲得讀寫的鎖。在 dynamo 系統中可以配置這種 wrn 引數以自持特定的一致性。

分布式一致性

分布式一致性是指在分布式環境中對某個副本資料進行更新操作時，必須確保其他副本也會更新，避免不同副本資料不一致。分布式系統乙個重要的問題時解決資料複製,一是為了增加系統的可用性防止單點故障，二是提高系統可用性，通過負載聚恆，使分布在不同位置的資料副本能夠提供服務。理想狀態下，當然希望分布式系統能夠實現...

分布式一致性方案

首先，先說一下。老外提出了乙個快取更新套路，名為 cache aside pattern 其中就指出 不是的。假設這會有兩個請求，乙個請求a做查詢操作，乙個請求b做更新操作，那麼會有如下情形產生 快取剛好失效 請求a查詢資料庫，得乙個舊值 請求b將新值寫入資料庫 請求b刪除快取 請求a將查到的舊值寫...

分布式一致性方案

首先，先說一下。老外提出了乙個快取更新套路，名為 cache aside pattern 其中就指出 失效 應用程式先從cache取資料，沒有得到，則從資料庫中取資料，成功後，放到快取中。命中 應用程式從cache中取資料，取到後返回。更新 先把資料存到資料庫中，成功後，再讓快取失效。不是的。假設這...