《云計算技術(shù)系列叢書 云原生分布式存儲基石： etcd深入解析》—1.2一致性

1.2　一致性

在闡述一致性模型和一致性協(xié)議之前，我們先來了解下什么是一致性。分布式存儲系統(tǒng)通常會通過維護(hù)多個副本來進(jìn)行容錯，以提高系統(tǒng)的可用性。這就引出了分布式存儲系統(tǒng)的核心問題—如何保證多個副本的一致性？

“一致性”這個中文術(shù)語在計算機的不同領(lǐng)域具有不同的含義，不同的含義所對應(yīng)的英文術(shù)語也是不一樣的，例如，Coherence、Consensus和Consistency等。就這三個術(shù)語而言，簡單來說，它們之間存在的區(qū)別具體如下：

Coherence這個單詞只在Cache Coherence場景下出現(xiàn)過，其所關(guān)注的是多核共享內(nèi)存的CPU架構(gòu)下，各個核的Cache上的數(shù)據(jù)應(yīng)如何保持一致。

Consensus是共識，它強調(diào)的是多個提議者就某件事情達(dá)成共識，其所關(guān)注的是達(dá)成共識的過程，例如Paxos協(xié)議、Raft選舉等。Consensus屬于replication protocol的范疇。

Consistency表達(dá)的含義相對復(fù)雜一些，廣義上說，它描述了系統(tǒng)本身的不變量的維護(hù)程度對上層業(yè)務(wù)客戶端的影響，以及該系統(tǒng)的并發(fā)狀態(tài)會向客戶端暴露什么樣的異常行為。CAP、ACID中的C都有這層意思。

本書將要重點討論的分布式系統(tǒng)中的一致性問題，屬于上文中提到的Consensus和Consistency范疇。分布式系統(tǒng)的一致性是一個具備容錯能力的分布式系統(tǒng)需要解決的基本問題。通俗地講，一致性就是不同的副本服務(wù)器認(rèn)可同一份數(shù)據(jù)。一旦這些服務(wù)器對某份數(shù)據(jù)達(dá)成了一致，那么該決定便是最終的決定，且未來也無法推翻。

一致性與結(jié)果的正確性沒有關(guān)系，而是系統(tǒng)對外呈現(xiàn)的狀態(tài)是否一致（統(tǒng)一）。例如，所有節(jié)點都達(dá)成一個錯誤的共識也是一致性的一種表現(xiàn)。

一致性協(xié)議就是用來解決一致性問題的，它能使得一組機器像一個整體一樣工作，即使其中的一些機器發(fā)生了錯誤也能正常工作。正因為如此，一致性協(xié)議在大規(guī)模分布式系統(tǒng)中扮演著關(guān)鍵角色。

同時，一致性協(xié)議也是分布式計算領(lǐng)域的一個重要的研究課題，對它的研究可以追溯到20世紀(jì)80年代，一致性協(xié)議衍生出了很多算法。衡量一致性算法的標(biāo)準(zhǔn)具體如下。

可終止性：非失敗進(jìn)程在有限的時間內(nèi)能夠做出決定，等價于liveness。

一致性：所有的進(jìn)程必須對最終的決定達(dá)成一致，等價于safety。

合法性：算法做出的決定值必須在其他進(jìn)程（客戶端）的期望值范圍之內(nèi)。即客戶端請求回答“是”或“否”時，不能返回“不確定”。

一致性協(xié)議是在復(fù)制狀態(tài)機（Replicated State Machines，RSM）的背景下提出來的，通常也應(yīng)用于具有復(fù)制狀態(tài)機語義的場景。在了解復(fù)制狀態(tài)機之前，讓我們先簡單了解下一致性模型。

1.2.1　一致性模型

一致性問題一直以來都是分布式系統(tǒng)的痛點，因為很多場景都要求一致性，但并不是所有的系統(tǒng)都要求是強一致的。強一致需要極高的成本，我們需要根據(jù)系統(tǒng)的容忍度適當(dāng)放寬一致性的要求。

在很多人看來，銀行間的轉(zhuǎn)賬應(yīng)該是強一致的，但是如果仔細(xì)分析一下就會發(fā)現(xiàn)，小王向小張轉(zhuǎn)賬1000元，小王的賬戶扣除了1000元，此時小張并不一定會同步收到1000元，可能會存在一個不一致的時間窗口。也就是小王的賬戶中扣除了1000元，小張還沒收到1000元。另外一個常見的例子，12306網(wǎng)站上買票的功能也未必是強一致的，如果你在12306上發(fā)現(xiàn)某車次的票還剩余10張，發(fā)起請求訂了一張票，系統(tǒng)返回的信息可能是“正在排隊，剩余10張票，現(xiàn)在有15人在購買”，而不是購買成功或失敗的結(jié)果，很可能你在收到上述信息之后，不得不去查詢未完成訂單，以進(jìn)一步確認(rèn)訂票情況。如果有人退了一張票，通常這張票也不會立即返回到票池中。很明顯這里也存在不一致的時間窗口。

本節(jié)將要重點討論分布式系統(tǒng)的一致性模型。我們知道，分布式系統(tǒng)中網(wǎng)絡(luò)分區(qū)在任何時刻、任何地點都有可能正在或即將發(fā)生。交換機、網(wǎng)卡、主機硬件、操作系統(tǒng)、磁盤、虛擬化層和語言運行時間（更不用說程序語義本身）都會延誤、丟棄、復(fù)制或重新排序我們的消息。在一個不確定的世界里，我們肯定都是希望自己的軟件能夠按照確定的規(guī)則運行。

那么，很顯然我們需要直觀的正確性。做正確的事情！那么究竟什么是正確的呢？我們又該如何描述它呢？

正確性

我們有很多種方式來表達(dá)一個算法的抽象行為，比如前文中介紹的狀態(tài)機模型—“一個系統(tǒng)是由狀態(tài)以及改變這些狀態(tài)的操作組成的”，隨著系統(tǒng)的運行，它會通過一些操作歷史從一個狀態(tài)轉(zhuǎn)移到另一個狀態(tài)。

如果我們的狀態(tài)是一個變量，狀態(tài)上的操作可能是寫入和讀取該變量，那么，如下這個簡單的Ruby程序?qū)啻螌懭牒妥x取一個變量，并將其打印到屏幕上，以說明讀取的內(nèi)容。示例代碼如下：

x = "a"; puts x; puts x

x = "b"; puts x

x = "c"

x = "d"; puts x

在上述示例代碼里，我們已經(jīng)有了這個程序正確性的直觀模型：它應(yīng)該打印“aabd”。為什么？因為每個陳述都是按順序發(fā)生的。首先寫入一個值a，然后是讀取兩次值a，再寫入值b，然后讀取值b等。上述寄存器系統(tǒng)讀寫輸出具體如圖1-1所示。

圖1-1　寄存器系統(tǒng)讀寫輸出示例

我們將這種一個變量攜帶一個值的系統(tǒng)稱為寄存器。一旦我們將一個變量（寄存器）設(shè)置為某個值，該值就會立刻生效，直到我們再次更改該值，即讀取變量應(yīng)該返回最近寫入的值。

從開始編寫程序的第一天起，這種模式就已經(jīng)深深地印刻在了我們的頭腦之中，然而這并非變量唯一的工作方式。事實上，一個變量可以返回任何一個讀取的值：a、d或the moon。如果發(fā)生這種情況，則認(rèn)為系統(tǒng)是不正確的，因為這些操作與我們的變量應(yīng)該如何工作的模型不一致。這也暗示了系統(tǒng)正確性的定義：在給定了與操作和狀態(tài)相關(guān)的一些規(guī)則的情況下，系統(tǒng)中的操作歷史應(yīng)該總是遵循這些規(guī)則。我們稱這些規(guī)則為一致性模型。

更正式的說法是，一致性模型是所有允許的操作歷史的集合。如果運行一個程序，它經(jīng)歷了“允許操作集”中的一系列操作，那么任意一次執(zhí)行都是一致的。如果程序偶爾發(fā)生故障并且出現(xiàn)了不是一致性模型中的歷史操作，那么我們就說歷史記錄是不一致的。如果每個可能的執(zhí)行都落入允許的集合中，則系統(tǒng)滿足該一致性模型。我們希望真正的系統(tǒng)能夠滿足“直觀正確”的一致性模型，以便編寫可預(yù)測的程序。

分布式 專屬分布式存儲服務(wù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。