Tanenbaum將分布式系統(tǒng)定義為“分布式系統(tǒng)是一組獨立的計算機，它們看起來像是一個用戶的單一、連貫的系統(tǒng)”，在“分布式系統(tǒng)原理和范式”當中。

區(qū)塊鏈，通過構(gòu)建一個全球性的分布式系統(tǒng)，試圖實現(xiàn)分散的新的數(shù)據(jù)存儲和組織結(jié)構(gòu)。

首先，面向分布式系統(tǒng)的原因主要是可擴展性、局部性和可用性。區(qū)塊鏈也不例外。地理可擴展性，以形成用于信息保護的全局值存儲網(wǎng)絡/位置，包括非集中式結(jié)構(gòu)/零停機時間的可用性下的防篡改。這些都是用分布式系統(tǒng)實現(xiàn)的。

1.引言（一致性概述和一致性原因）

在分布式系統(tǒng)中，數(shù)據(jù)主要是為了“可靠性”和“性能”而復制的。復制是必需的，特別是如果分布式系統(tǒng)需要在數(shù)量上和地理上增長。復制是縮放技術(shù)中的一種。此外，它還可以應對數(shù)據(jù)損壞和副本崩潰。

此時，需要保持數(shù)據(jù)和副本的狀態(tài)的一致性。然而，這直接導致可擴展性問題。當你考慮一致性時，理想的情況是“保持所有副本處于完全相同的狀態(tài)和操作”，即，實現(xiàn)了原子性，但這是一個相當大的挑戰(zhàn)。

在現(xiàn)實中，我們不能解決可擴展性問題，除非我們放棄一些一致性約束。因此，有必要了解系統(tǒng)需要多少一致性，以及如何實現(xiàn)一致性的程度。

在本章中，副本之間的一致性將按以下順序解釋。

有什么樣的一致性模型？

關(guān)于復制管理

-何時何地進行復制

-誰放置伺服器（客戶端）？服務器？）

如何保證拷貝之間的一致性

特定一致性協(xié)議實例及實現(xiàn)

2.以數(shù)據(jù)為中心的一致性模型

傳統(tǒng)上，主要從數(shù)據(jù)（數(shù)據(jù)存儲）來討論一致性。

在分布式系統(tǒng)中，每個進程都保存自己的本地副本。此時，包括每個本地副本的存儲數(shù)據(jù)集合被稱為分布式數(shù)據(jù)存儲。

當進程從數(shù)據(jù)存儲中讀取時，它期望最后寫入操作的結(jié)果作為數(shù)據(jù)返回。為了闡明哪一個是最后一個寫，我們把序關(guān)系稱為一致性。

如第1節(jié)所述，幾乎不可能保持完全一致性。允許某種程度的不一致導致兼容性與性能，但它取決于你的應用程序，你可以容忍什么，你可以容忍多少。你應該根據(jù)應用程序、系統(tǒng)選擇一個一致性級別。因此，有必要首先理解什么樣的一致性存在。

順序一致性是最流行和最重要的一致性模型。偶然一致性是其弱變量。

2–1.序列一致性

當滿足以下條件時，數(shù)據(jù)存儲順序一致。

任何執(zhí)行序列的結(jié)果是，所進程到數(shù)據(jù)存儲區(qū)的讀/寫操作與以特定順序特定順序執(zhí)行的結(jié)果相同，并且各個進程的操作按其進程所指定的順序執(zhí)行。

關(guān)鍵在于，當比較每個過程的操作時，它們處于完全相同的順序。

在下面的圖中，（a）順序一致，但是（b）不是因為處理P3和處理P4中的讀數(shù)順序不同。具體而言，在P3中，P1將由處理P2的寫入結(jié)果的值r（x）b改變?yōu)橹祌（x）a，但在P4中相反。

W（x）a表示寫入數(shù)據(jù)“x”的值“a”，R（x）b表示從數(shù)據(jù)“x”讀取值“b”。

2–2．偶然一致性

當滿足以下條件時，數(shù)據(jù)存儲是偶然一致的。

潛在因果關(guān)系的寫入必須按所有進程以相同的順序來觀察。對于不同的機器，可以以不同的順序觀察并發(fā)寫入。

換句話說，它減少了序列一致性的約束，并且沒有因果關(guān)系的處理序列可以處于不同的順序。

此時，每個操作取決于哪些操作（其中兩個操作是否具有因果關(guān)系）非常重要，為此，使用“向量時間戳”是有效的。

在下面的圖中，在上面的圖中，由于值“b”和值“c”的寫入是并行操作，因此它滿足因果一致性。

2–3．入口一致性

首先，準備同步變量。通過獲取同步變量并僅允許具有同步變量的進程更新數(shù)據(jù)，還可以保持一致性。這就是所謂的“條目一致性”。

為了保持條目的一致性，同步變量在獨占模式訪問時不應該有兩個所有者，比如寫入。在可讀但不可寫的非排他模式中，多個進程可以同時擁有同步變量。

在下面的圖中，由于Process2不擁有對數(shù)據(jù)項“y”的訪問權(quán)（=同步變量），所以讀取結(jié)果變成NIL。

此時，如何正確地關(guān)聯(lián)數(shù)據(jù)和同步變量成為一個問題。在面向?qū)ο蟮那闆r下，可以通過隱式地將同步變量與每個對象相關(guān)聯(lián)來實現(xiàn)。

3.以客戶為中心的一致性模型

最終一致性和以客戶為中心的一致性模型

一般來說，過程之間的不一致在某種程度上是可以接受的。例如，在Web緩存中，響應客戶機的緩存頁面可能比實際存在的Web服務器版本要舊。然而，對于許多用戶來說，這種不一致在某種程度上是可以接受的。

即使如上所述的不一致，隨著時間的推移，所有的副本也將逐漸變得一致。這種形式的一致性被稱為最終一致性。

只有客戶端總是訪問相同的副本，最終一致的數(shù)據(jù)存儲才正常工作。然而，如果移動用戶在短時間內(nèi)移動和訪問不同的副本，又會怎樣呢？例如，如果你使用Express， 客戶端將在短時間內(nèi)移動到另一個位置并訪問不同的副本，但是在這里，除非已經(jīng)傳播了之前完成的更新，否則它看起來是不一致的。

對于上述問題，引入以客戶為中心的一致性是一種解決方案。與前一節(jié)中的以數(shù)據(jù)為中心的一致性模型不同，該模型旨在保證單個客戶端的一致性。

單調(diào)閱讀

下面的句子是滿足單調(diào)閱讀一致性的條件。

如果進程讀取數(shù)據(jù)項x，則該進程對x的任何后續(xù)讀取要么使用相同的值進行應答，要么使用更新的值進行應答。

在下面的圖中，在（b）中，不能保證寫入操作WS（x1）的內(nèi)容包含在L2的讀取結(jié)果中，因此不存在單調(diào)的讀取一致性。

無論何時在任何地方連接到郵件服務器，都保證在訪問服務器時直到最后一次都可以讀取的所有郵件在目的地讀取。

單調(diào)令狀

下面的句子是滿足單調(diào)寫作一致性的條件。

通過一個進程到數(shù)據(jù)項X的寫入操作在同一進程的任何后續(xù)寫入到X之前完成。

單調(diào)寫入一致性類似于以數(shù)據(jù)為中心的FIFO一致性。FIFO一致性的本質(zhì)是以相同的順序進行寫入操作，其順序是正確的。在單調(diào)寫入一致性中，它是相同的順序約束，但是僅針對單個進程，而不是并發(fā)進程集合。

讀寫你編寫的文章

以下句子是在寫作后滿足閱讀一致性的條件。

通過對同一過程的后續(xù)讀取操作，總是觀察到對數(shù)據(jù)項X的寫入操作的結(jié)果。

也就是說，寫入操作總是在相同進程執(zhí)行的后續(xù)讀取操作之前完成，而不管在哪里完成。

示例1：在更新網(wǎng)頁之后，新瀏覽器內(nèi)容將始終顯示在瀏覽器中。

示例2：當密碼被更新時，保證更新的密碼可以在你移動到的地方使用。

寫后續(xù)閱讀

以下句子是閱讀后滿足寫作一致性的條件。

通過對同一過程的后續(xù)讀取操作，總是觀察到對數(shù)據(jù)項X的寫入操作的結(jié)果。

4. 復制管理

到目前為止，我們已經(jīng)詳細地解釋了一致性的類型。在本節(jié)中，我們將解釋復制安排、放置副本的位置、時間、時間和方式，以及如何實現(xiàn)一致性。

復制放置有兩種類型：

1. 復制服務器放置問題

2. 內(nèi)容放置問題

4–1.復制服務器布局問題

對于服務器放置問題，有一種方法基于客戶端和服務器之間的距離來安排它。距離可以通過傳輸延遲和帶寬來測量。選擇一個服務器是很好的，使得服務器和客戶端之間的平均距離最小化。

作為另一種選擇，有一種考慮網(wǎng)絡拓撲的方法。將服務器放置在具有最大網(wǎng)絡接口數(shù)（即鏈路）的路由器上是很好的方法。

它們的問題是大量的計算復雜度。它不能容忍在“閃光云”（一個特定地點的突然爆炸請求）時的計算。此時，有一些解決方案來提高效率，例如通過劃定區(qū)域?qū)ふ易罱咏膮^(qū)域。

4–2.內(nèi)容復制與布局

關(guān)于內(nèi)容，三種不同類型的副本被區(qū)分和組織，如下圖所示。

永久復制品

這是組成分布式數(shù)據(jù)存儲區(qū)的初始副本集。在許多情況下，永久性復制品的數(shù)量很小。

服務器啟動副本

通過啟動數(shù)據(jù)存儲區(qū)所有者生成的用于提高性能的數(shù)據(jù)存儲的副本。動態(tài)放置復制意味著動態(tài)地將性能需要改進的文件復制到Web托管服務中的服務器。

例如，對于紐約的web服務器，如果在遠離服務器的某個意外位置的客戶端幾天內(nèi)請求的數(shù)量爆炸性的增加，則臨時在該區(qū)域放置副本是有效的。

客戶端啟動副本

這通常被稱為客戶端緩存。這僅用于改善對數(shù)據(jù)的訪問時間。當需要讀取相同的數(shù)據(jù)時，將副本僅保存在客戶端有限時間的緩存函數(shù)是有效的。

4–3．內(nèi)容分發(fā)

復制管理還包括將更新內(nèi)容傳遞到復制服務器（如何更新）。

要傳播的信息類型

實際傳播的信息有三種可能性。

只傳播通知更新

將更新數(shù)據(jù)從一個副本發(fā)送到另一個副本

將更新操作傳播到其他副本

1通知的傳播是通過無效通知協(xié)議來完成的。你只能注意到副本信息不再有效。有利地，它使用很少的網(wǎng)絡帶寬，并且當副本不需要頻繁更新時使用它。

2是在副本之間傳輸更新的數(shù)據(jù)。更新往往更有效和實用。

3只通知應該執(zhí)行什么類型的更新操作。此時，可以假設(shè)每個副本始終具有保持數(shù)據(jù)最新的能力，因此一致性從1得到改進。

拉與推

有兩種方法的更新傳播，拉和推。

當讀/寫比率高時，效率更好，因為當從服務器推送更新時，保持一致性。

另一方面，當讀寫比低時，高更新頻率會浪費帶寬等資源，因此拉動更合適。

推拉有以下特點。

*輪詢：用于平滑地鏈接多個設(shè)備和軟件的控制方法之一，用于主系統(tǒng)詢問其他系統(tǒng)是否存在定期間隔的方法。

單播與多播

通過使用組播，可以有效地實現(xiàn)基于推送的方法。相反，單播是基于拉的方法最有效的解決方案。

5．一致性協(xié)議

在這一節(jié)中，我們將具體檢查具體的協(xié)議。

5–1．基本基礎(chǔ)協(xié)議

主要基礎(chǔ)協(xié)議通常用于實現(xiàn)順序一致性。在該協(xié)議中，與項目X相關(guān)聯(lián)的主服務器負責地執(zhí)行其寫入操作。

主要基礎(chǔ)協(xié)議有兩種方式。

?確認主服務器到特定服務器的方法

?在將主服務器移動到啟動寫入操作的服務器之后執(zhí)行寫操作的方法

5–1–1．遠程寫入?yún)f(xié)議

所有的寫入操作被傳輸?shù)焦潭ǖ膯蝹€主服務器并執(zhí)行。在遠程寫協(xié)議（主備份協(xié)議）中，它直接實現(xiàn)了順序一致性，因為主服務器可以按照全局唯一時間順序?qū)λ袑戇M行排序。

（然而，該協(xié)議具有相對長的等待時間的性能問題，這通過采用非阻塞方法得到改進，但是是更新可靠性的折衷。）

5–1–2.本地寫協(xié)議

一種移動權(quán)限的協(xié)議，以便運行寫操作的服務器可以作為主副本操作。它被應用到許多分布式存儲系統(tǒng)中。

5–2。復制寫協(xié)議

在主基本復制中，對一個副本執(zhí)行寫操作，但是在復制寫協(xié)議中，對多個副本執(zhí)行寫操作。

復制的寫協(xié)議有兩種方式，

?主動復制協(xié)議將操作指令傳輸?shù)剿懈北?/p>

?基于多數(shù)表決的一致性協(xié)議

5–2–1 主動復制協(xié)議

每個副本具有執(zhí)行更新操作的過程，并且執(zhí)行寫入操作。此時，所有RePCAS必須以相同的順序執(zhí)行操作。

利用Lamport時鐘的全序組播可以實現(xiàn)訂購，但是很難將規(guī)模擴展到大型分布式系統(tǒng)，通常使用中央?yún)f(xié)調(diào)器或定序器來實現(xiàn)全序化。

5–2–2 恒基協(xié)議

這是用投票實現(xiàn)的復制操作。基本上，在執(zhí)行數(shù)據(jù)項的讀寫之前，向多個復制服務器發(fā)出操作請求許可，并且當獲得許可時執(zhí)行該操作。

此時，如果N是服務器的數(shù)量，NR是讀取常數(shù)，NW是寫入常數(shù)，那么我們有以下限制：

1。NW+NR》 N

2。NW》 N／2

當滿足這兩種情況時，可以防止閱讀和寫作比賽和寫作比賽。這兩個常數(shù)根據(jù)每個讀/寫的頻率進行優(yōu)化。

5–3 緩存一致性協(xié)議

與前兩個不同的是，一致性由客戶端控制，而不是服務器。緩存一致性協(xié)議可以分為幾種設(shè)計方法。

首先，根據(jù)檢測不一致的情況，可以將其劃分如下。

?在交易期間訪問緩存的數(shù)據(jù)項時驗證一致性的情況

?你希望交易在驗證數(shù)據(jù)項時繼續(xù)進行的情況。

?只有在交易提交時才驗證一致性。

接著，根據(jù)副本之間保持一致性的方法，將其劃分如下。

?更新時，服務器總是使所有緩存無效。

?當簡單地傳播更新時

在許多情況下，更新操作僅由服務器完成，并且更新由客戶端從拉基傳播。

還有一種類似于主基本地寫協(xié)議的方法，它允許客戶端修改緩存的數(shù)據(jù)。該方法用于分布式文件系統(tǒng)，稱為寫通緩存方法。此時，為了保證順序一致性，客戶端需要保留獨占的寫權(quán)限。如果延遲更新的電磁波，并在通知服務器之前允許多次寫入，則可以進一步提高性能，這稱為回寫緩存。

6. 區(qū)塊鏈的一致性

正如我們提到的，為了在分布式系統(tǒng)中保持過程和數(shù)據(jù)之間的一致性，需要各種各樣的獨創(chuàng)性。

通常，在大型分布式系統(tǒng)中保持一致性是一項非常艱難的任務。區(qū)塊鏈確實是實現(xiàn)分布式系統(tǒng)的精確機制，但它是一種新技術(shù)，通過其將區(qū)塊連接在鏈中的基本體系可以實現(xiàn)完全順序一致性。

6–1 區(qū)塊鏈序列一致性

在區(qū)塊鏈中，兩個交易之間的順序總是一致的。例如，在比特幣的情況下，關(guān)于某個比特幣的交易的命令，例如A的UTXO轉(zhuǎn)移到B，然后B通過該UTXO向C付款，在每個節(jié)點上是一致的。這是由于包含交易的區(qū)塊在鏈上連接的特點。此外，這是由于比特幣的特性使得對于創(chuàng)建新區(qū)塊達成了共識，并且除非交易與過去的交易一致，否則不會批準交易。

從上面的特性中可以看出，缺省情況下，對于所有節(jié)點中的區(qū)塊鏈上的交易，都保持順序一致性。通過這種方式，可以說區(qū)塊鏈通過一種非常簡單的機制來實現(xiàn)分布式系統(tǒng)及其一致性。

然而，考慮到鏈鏈的一致性更精確，可以說它是相當不一致的一致性。為了進一步考慮，我想首先確認CAP定理。

6–2 CAP定理與區(qū)塊鏈

“CAP定理”是Brewer在2000年預測并隨后由Gilbert等人制定和驗證的分布式系統(tǒng)的性質(zhì)。CAP定理指出，分布式系統(tǒng)可以滿足一致性、可用性和碎片化兩個系統(tǒng)，但不能同時滿足這三個系統(tǒng)。

在采用PoW作為協(xié)商一致算法（如比特幣）的許可較少的公共區(qū)塊鏈中（詳細信息在“區(qū)塊鏈比較公共私有聯(lián)合體類型”的文章中），它處于可用性和分區(qū)容忍性的高標準中。即使某些節(jié)點出現(xiàn)故障，區(qū)塊鏈網(wǎng)絡仍然繼續(xù)移動（可用性），即使網(wǎng)絡斷開，它也可以通信（分區(qū)容忍）。另一方面，在一致性方面則是不完善的。如前節(jié)所述，盡管交易的順序一致性的確是隨著時間推移而建立的，但是在PoW.每個小號都在自己的時間廣播，當他們找到一個隨機數(shù)和更新到最新的狀態(tài)，所以頻繁的叉子發(fā)生。將其應用于CAP定理，我們在一定程度上選擇了可用度和劃分容限和犧牲一致性。

然而，隨著時間的推移，它的一致性將變得更加確定。盡管沒有終結(jié)性的事實仍然被當作一個問題來討論，即使討論仍在進行中，它是一個極好的系統(tǒng)，它隨時間保持完全的順序一致性，并且還具有抗篡改性。這就是為什么區(qū)塊鏈技術(shù)在當今世界越來越受到關(guān)注的原因之一。

Seth Gilbert和Nancy Lynch。Brewer猜想和一致性、可用性、可區(qū)分性的Web服務的可行性。

6–3 區(qū)塊鏈與復制管理

正如我們在本文中提到的，在運行分布式系統(tǒng)時，復制管理的問題很重要；在何時、由誰來管理復制，應采取何種機制來確保復制之間的一致性。那么，如何在連區(qū)塊鏈中進行復制管理呢？

首先，關(guān)于副本服務器放置問題。通常，在考慮服務器布局問題時，我們發(fā)現(xiàn)最有效的布局是基于通信集中的位置等。然而，諸如比特幣之類的區(qū)塊鏈正在進行非集中式管理，這取決于每個參與者是否以全部節(jié)點的形式加入網(wǎng)絡。也就是說，難以全面靈活地安排系統(tǒng)。

那么，副本之間的更新內(nèi)容的分布是如何操作？正如我們所提到的，在更新時信息傳播的可能性有三種。

1. 只傳播通知更新

2. 將更新數(shù)據(jù)從一個副本發(fā)送到另一個副本

3. 將更新操作傳播到其他副本

在區(qū)塊鏈中，為了防止分叉或篡改，希望所有節(jié)點盡可能保持網(wǎng)絡上的最新信息。此外，因為只有最長的鏈條被認為是合法的鏈，所以設(shè)計一個激勵結(jié)構(gòu)，使所有礦工能夠快速捕獲最新區(qū)塊的信息，以便盡快找到下一個現(xiàn)值。由于上述原因，在區(qū)塊鏈中，更新數(shù)據(jù)本身在副本之間傳輸，并且盡快執(zhí)行更新內(nèi)容的交換。也就是說，“傳播更新操作到其他副本”是區(qū)塊鏈中所選擇的方法。

此外基本上，非集中式系統(tǒng)區(qū)塊鏈，通過P2P通信來執(zhí)行。組播主要用于區(qū)塊鏈網(wǎng)絡中的P2P通信。

首先，當?shù)V工發(fā)現(xiàn)一個臨時值時，立即對所有網(wǎng)絡參與者執(zhí)行基于推送的多播。礦工在收集來自其他驗證器的確認之后，通過盡快通知礦工自己找到的新的區(qū)塊，試圖創(chuàng)建新區(qū)塊而得到報酬。

新加入網(wǎng)絡的節(jié)點和斷開連接并重新加入的節(jié)點執(zhí)行基于拉的多播以同步網(wǎng)絡的最新信息。為了防止表單被欺騙而受到雙重篡改等，客戶端試圖盡可能地獲取最新數(shù)據(jù)，同時試圖盡可能地與多個節(jié)點通信。

此外，對于可靠的完整節(jié)點，存在基于拉協(xié)議的單播客戶端，并捕獲應用程序中的最新數(shù)據(jù)。

6–4. 區(qū)塊鏈與主基協(xié)議

在區(qū)塊鏈中，節(jié)點分散在世界各地，副本分散在所有區(qū)域。在POW一致性的情況下，每個交易都是由第一個找到下一個NoCE的節(jié)點新編寫的。也就是說，每個交易都有與其相關(guān)的主服務器。

由此，我們可以得出結(jié)論，用于維護區(qū)塊鏈一致性的POW協(xié)議被歸類為5–1–2中描述的主基協(xié)議的本地寫協(xié)議。在比特幣區(qū)塊鏈中，作為主服務器的寫權(quán)限是通過查找PoW的nonce值作為獨占控制/領(lǐng)導選擇算法獲得的；查找頭上有N個數(shù)字0的散列的nonce值的算法是每個區(qū)塊的權(quán)利。然而，當一個具有同時成為主服務器的權(quán)限的節(jié)點同時出現(xiàn)時，BooStand會做分叉。

6–5. 區(qū)塊鏈和新的復制寫協(xié)議

另一方面，包括Tendermint在內(nèi)的各種基于PBFT的協(xié)商一致算法沒有首先負責地執(zhí)行更新每個數(shù)據(jù)的主服務器。它們沒有權(quán)利為每個應用程序中的其他副本寫操作，并且保留該權(quán)限僅限于參與協(xié)商算法的節(jié)點，然而，所有參與節(jié)點可以在同一時間段內(nèi)執(zhí)行寫操作。換句話說，PBFT類型一致性協(xié)議接近復制類型的主動復制協(xié)議。

主動復制協(xié)議的主要挑戰(zhàn)之一是難以在所有副本中以相同的順序執(zhí)行操作。雖然這可以通過使用Lamport的邏輯時鐘執(zhí)行全序多播來解決，但是因為很難擴大規(guī)模，所以通常需要中央?yún)f(xié)調(diào)器的支持。Hyperledger中的PBFT算法與此表單完全相同，值得信任的組織成為管理區(qū)塊更新順序的領(lǐng)導者（Order）。

另一方面，Tendermint使用獨特的Tenderimint一致性，該一致性引入了三相提交格式，以保持總訂單的一致性。為了進一步解釋，“在形成區(qū)塊鏈的分布式系統(tǒng)中的容錯性”是一種全新的革命性的主動復制協(xié)議，并且實現(xiàn)了完整性。