導(dǎo)讀：本文從高可用視角來(lái)重新審視數(shù)據(jù)一致性問(wèn)題，討論如何在可用性和一致性上取得相對(duì)的平衡。

作者：李玥

來(lái)源：大數(shù)據(jù)DT（ID：hzdashuju）

在分布式存儲(chǔ)系統(tǒng)中，讓系統(tǒng)中多個(gè)實(shí)例的狀態(tài)保持一致，是一個(gè)比較難處理的問(wèn)題。尤其是當(dāng)系統(tǒng)出現(xiàn)故障時(shí)，系統(tǒng)能否始終保持一致性，很大程度上影響了系統(tǒng)的可用性和數(shù)據(jù)的可靠性。

典型的由不一致導(dǎo)致的重大事故是這樣的：正常情況下，系統(tǒng)通過(guò)某種數(shù)據(jù)同步機(jī)制保持各實(shí)例上狀態(tài)的一致性，當(dāng)發(fā)生實(shí)例宕機(jī)、網(wǎng)絡(luò)分區(qū)等故障時(shí)，這種同步機(jī)制無(wú)法正常工作，一致性被打破。

這種情況下，出現(xiàn)了多份不一致的狀態(tài)數(shù)據(jù)，系統(tǒng)很難自動(dòng)去判斷到底哪份狀態(tài)數(shù)據(jù)才是“正確的”，也就沒(méi)有辦法自動(dòng)恢復(fù)。更糟糕的是，一旦這種不一致的狀態(tài)被其它系統(tǒng)讀取，錯(cuò)誤的狀態(tài)將被傳遞到其它系統(tǒng)中，造成不可預(yù)期的結(jié)果。

這種復(fù)雜的數(shù)據(jù)錯(cuò)誤，即使人工處理也是非常難恢復(fù)，往往恢復(fù)時(shí)間需要幾小時(shí)或幾天，嚴(yán)重情況下甚至于無(wú)法恢復(fù)。

可以看出，在故障情況下仍然保持一致性，是系統(tǒng)能快速?gòu)墓收现谢謴?fù)的前提條件，有助于提升系統(tǒng)的可用性。但為了保證一致性，在數(shù)據(jù)更新時(shí)，往往需要協(xié)調(diào)參與的各個(gè)模塊，確保它們同步更新。比如，使用各種分布式事務(wù)。

但這會(huì)導(dǎo)致這些模塊在可用性上緊密耦合在一起，反而降低了系統(tǒng)的可用性。這種場(chǎng)景下，可用性和一致性又存在矛盾。

本文從高可用視角來(lái)重新審視數(shù)據(jù)一致性問(wèn)題，討論如何在可用性和一致性上取得相對(duì)的平衡。

01 如無(wú)必要，勿增副本

在考慮如何平衡一致性與可用性之前，最重要的是要意識(shí)到，在分布式系統(tǒng)中解決一致性問(wèn)題需要付出非常大的代價(jià)，這些代價(jià)可能包括：可用性降低、性能下降、用戶體驗(yàn)變差或者是極大的增加了系統(tǒng)的復(fù)雜度。

因此，不要人為制造一致性難題。但是，很多情況下，因?yàn)槿鄙龠@方面的意識(shí)，我們無(wú)意間為系統(tǒng)制造了本無(wú)必要的一致性難題，然后又付出了巨大的代價(jià)去解決這個(gè)難題，得不償失。

為系統(tǒng)中的狀態(tài)數(shù)據(jù)設(shè)計(jì)多個(gè)副本的情況并不罕見(jiàn)，常見(jiàn)的多副本設(shè)計(jì)包括：

• 以不同格式或數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)多個(gè)副本。

• 在不同類型的外部存儲(chǔ)中存儲(chǔ)多個(gè)副本。

• 在本地磁盤或內(nèi)存中緩存數(shù)據(jù)的副本。

以上這些都是我們時(shí)常會(huì)用到的設(shè)計(jì)模式，難道說(shuō)它們都是“不好的設(shè)計(jì)”么？

當(dāng)然不是這樣的。

架構(gòu)設(shè)計(jì)是平衡的藝術(shù)，當(dāng)架構(gòu)師選擇某種設(shè)計(jì)或架構(gòu)時(shí)，一定要充分了解當(dāng)前選擇的優(yōu)勢(shì)和代價(jià)，確保優(yōu)點(diǎn)是我們所需要的，代價(jià)是我們能接受的。這樣的設(shè)計(jì)才是在當(dāng)前場(chǎng)景下最優(yōu)的選擇。

為數(shù)據(jù)增加副本會(huì)帶來(lái)一致性難題，開(kāi)發(fā)者需要為此付出巨大的代價(jià)去維護(hù)數(shù)據(jù)一致性。所以，在設(shè)計(jì)過(guò)程中需要慎重考慮，為系統(tǒng)增加副本所帶來(lái)的收益和付出的代價(jià)，二者相比是不是值得做出這樣的選擇。

我們需要避免的是，在設(shè)計(jì)過(guò)程中未經(jīng)仔細(xì)思考隨意增加副本的行為。

以下是幾個(gè)常見(jiàn)的錯(cuò)誤示例：

• 僅僅是為了寫代碼的時(shí)候更方便地讀取數(shù)據(jù)，就隨意增加副本。比如，為了便于查詢，將數(shù)據(jù)庫(kù)中A表中的部分字段，在B表中也保存一份。

• 系統(tǒng)中存在多個(gè)外部存儲(chǔ)，為了讀寫方便，在每個(gè)外部存儲(chǔ)都保存一份數(shù)據(jù)副本。比如，集群的元數(shù)據(jù)保存在ZooKeeper中，為了方便管理控制臺(tái)操作，也在MySQL中保存一份同樣的數(shù)據(jù)。

• 不考慮系統(tǒng)的性能實(shí)際要求，為了讓系統(tǒng)速度更快一些，在Redis和內(nèi)存中緩存數(shù)據(jù)。

02 一致性與可用性的矛盾

在現(xiàn)有硬件技術(shù)條件下，對(duì)分布式系統(tǒng)中每個(gè)節(jié)點(diǎn)更新操作，總會(huì)有先后，不可能做到絕對(duì)的“同時(shí)”，也就無(wú)法保證系統(tǒng)的多個(gè)副本在“任何時(shí)刻”狀態(tài)都相同。

因此，這里我們討論的一致性是，系統(tǒng)作為一個(gè)整體對(duì)外部所表現(xiàn)出的一致性。換句話說(shuō)就是，分布式系統(tǒng)內(nèi)部可以存在不一致的狀態(tài)，但只要這種不一致的狀態(tài)對(duì)外部是不可見(jiàn)的，那就可以認(rèn)為這個(gè)系統(tǒng)具備一致性。

在分布式系統(tǒng)中，既要保證高可用又要保證一致性是幾乎不可能實(shí)現(xiàn)的。我們把分布式系統(tǒng)抽象成最簡(jiǎn)單的模型：一個(gè)只有兩個(gè)有狀態(tài)節(jié)點(diǎn)系統(tǒng)。然后在這個(gè)最簡(jiǎn)模型下來(lái)分析一致性問(wèn)題：如何保證這兩個(gè)節(jié)點(diǎn)上的狀態(tài)，在任何時(shí)刻都是相同的？

即使在這樣一個(gè)最簡(jiǎn)模型下，保持一致性仍然面臨下面的3個(gè)難題。

第一個(gè)難題是，如何處理更新操作失敗的情況。

要保持兩個(gè)節(jié)點(diǎn)上狀態(tài)的一致性，理論上需要每次更新?tīng)顟B(tài)時(shí)同步更新兩個(gè)節(jié)點(diǎn)上的狀態(tài)。如果某一個(gè)節(jié)點(diǎn)上的更新操作失敗了，系統(tǒng)將變成如下不一致的狀態(tài)：一個(gè)節(jié)點(diǎn)更新成功，而另外一個(gè)節(jié)點(diǎn)更新失敗。

在這種情況下，還要保持系統(tǒng)的一致性，就需要將這種不一致?tīng)顟B(tài)隔離在系統(tǒng)內(nèi)部，不能讓外部系統(tǒng)感知，并且盡快修復(fù)不一致的狀態(tài)。

要修復(fù)這種不一致?tīng)顟B(tài)，一般有兩種方法，分別是重試和回滾。

• 重試指的是，讓失敗的節(jié)點(diǎn)重新執(zhí)行更新操作。如果重試成功，系統(tǒng)將重新回到一致的狀態(tài)。

• 回滾指的是，讓之前更新成功的節(jié)點(diǎn)執(zhí)行回滾操作，回到更新前的狀態(tài)，也可以讓系統(tǒng)重新回到一致?tīng)顟B(tài)。

但重試和回滾的實(shí)現(xiàn)代價(jià)都很大。

通過(guò)重試來(lái)解決一致性的前提是，被重試的更新操作必須具備冪等性和原子性。

• 冪等性，可以保證多次重試同一個(gè)更新操作不會(huì)改變狀態(tài)的正確性；

• 原子性，則可以避免在更新具有復(fù)雜數(shù)據(jù)結(jié)構(gòu)的狀態(tài)失敗時(shí)，只更新了部分狀態(tài)的尷尬局面。

如果系統(tǒng)的狀態(tài)不是保存在關(guān)系型數(shù)據(jù)庫(kù)中，要實(shí)現(xiàn)冪等性和原子性其實(shí)很不容易。

實(shí)現(xiàn)回滾同樣要保證原子性，此外為了能將狀態(tài)恢復(fù)到更新之前，需要在執(zhí)行更新操作之前記錄原始狀態(tài)，系統(tǒng)還要考慮如何處理回滾失敗的問(wèn)題。

第二個(gè)難題是，如何在其中一個(gè)節(jié)點(diǎn)不可用的情況下保證系統(tǒng)一致性。

當(dāng)系統(tǒng)其中的一個(gè)節(jié)點(diǎn)不可用時(shí)，另外一個(gè)節(jié)點(diǎn)仍然可以提供讀寫服務(wù)。當(dāng)故障節(jié)點(diǎn)恢復(fù)后，理論上只要把狀態(tài)數(shù)據(jù)從可用節(jié)點(diǎn)同步到之前故障的節(jié)點(diǎn)上，系統(tǒng)就可以重新回到一致性狀態(tài)了。而在現(xiàn)實(shí)中實(shí)現(xiàn)好數(shù)據(jù)同步，既要做到快速同步，又要保證不重不漏，難度和代價(jià)都比較大。

最簡(jiǎn)單的方法是全量數(shù)據(jù)同步，清空故障節(jié)點(diǎn)上的狀態(tài)數(shù)據(jù)，然后將可用節(jié)點(diǎn)上的狀態(tài)數(shù)據(jù)全部復(fù)制到故障節(jié)點(diǎn)上。全量同步相對(duì)比較耗時(shí)，如果數(shù)據(jù)量比較大，就必須采用增量同步的方法。

而增量同步，則需要精準(zhǔn)地界定出哪些數(shù)據(jù)屬于“增量數(shù)據(jù)”。這對(duì)于大多數(shù)采用多線程并行處理請(qǐng)求的服務(wù)來(lái)說(shuō)，幾乎不可能實(shí)現(xiàn)。同時(shí)，另一個(gè)不得不考慮的極端情況是，如果在一段時(shí)間內(nèi)兩個(gè)節(jié)點(diǎn)交替多次出現(xiàn)不可用的情況，系統(tǒng)將很難判定哪個(gè)節(jié)點(diǎn)上的狀態(tài)才是“正確可信的狀態(tài)”，也就無(wú)法恢復(fù)系統(tǒng)的一致性狀態(tài)。

第三個(gè)難題是，如何在網(wǎng)絡(luò)分區(qū)情況下保證系統(tǒng)的一致性。

網(wǎng)絡(luò)分區(qū)，指的是由于網(wǎng)絡(luò)設(shè)備故障，造成網(wǎng)絡(luò)分裂為多個(gè)獨(dú)立的區(qū)域。典型場(chǎng)景是兩個(gè)機(jī)房間的網(wǎng)絡(luò)中斷，這兩個(gè)機(jī)房就形成了兩個(gè)互不聯(lián)通的分區(qū)。

假設(shè)發(fā)生了網(wǎng)絡(luò)分區(qū)，系統(tǒng)的兩個(gè)節(jié)點(diǎn)恰巧分別位于不同分區(qū)，這種情況下，雖然沒(méi)有節(jié)點(diǎn)不可用，但節(jié)點(diǎn)間無(wú)法通信，也就無(wú)法保證系統(tǒng)一致性。如果系統(tǒng)不能容忍“不一致”，唯一的辦法就是在網(wǎng)絡(luò)分區(qū)期間停止對(duì)外提供服務(wù)，也就是說(shuō)需要犧牲“可用性”。

上面我們討論的情況，就是著名的CAP理論的一種典型場(chǎng)景：在網(wǎng)絡(luò)分區(qū)的情況下，一致性和可用性只能二選其一。

鑒于一致性與可用性存在沖突，以及實(shí)現(xiàn)一致性的代價(jià)過(guò)高這兩個(gè)原因，在設(shè)計(jì)分布式系統(tǒng)時(shí)，放棄對(duì)嚴(yán)格一致性的約束，讓系統(tǒng)去適應(yīng)相對(duì)寬松一致性，從而在一致性、可用性和性能上取得相對(duì)可接受的平衡，是更加理性的選擇。

所謂“寬松一致”，是在隔離性和性能等方面適當(dāng)放寬要求后的一系列降級(jí)版一致性。相對(duì)的，我們之前討論的一致性，也被稱為“強(qiáng)一致”。最終一致是普遍采用的一種寬松一致。

比如上面的例子，在網(wǎng)絡(luò)分區(qū)的情況下，如果可以接受最終一致，則系統(tǒng)仍然可以在其中的一個(gè)分區(qū)提供讀寫服務(wù)，另一個(gè)分區(qū)提供只讀服務(wù)，極大增強(qiáng)系統(tǒng)的可用性。只要待網(wǎng)絡(luò)故障結(jié)束后，再通過(guò)單向數(shù)據(jù)同步即可恢復(fù)系統(tǒng)一致性。

03 在一致性與可用性之間保持平衡

犧牲強(qiáng)一致后，當(dāng)系統(tǒng)故障時(shí)，由于系統(tǒng)存在多個(gè)副本，就比較容易繼續(xù)維持可用性。無(wú)論是發(fā)生網(wǎng)絡(luò)故障還是服務(wù)器宕機(jī)，只要調(diào)用端還能訪問(wèn)某個(gè)存活的副本，系統(tǒng)仍然可以提供服務(wù)。

BASE給出了一種平衡一致性和可用性的策略，這種策略適用范圍廣泛，實(shí)現(xiàn)難度不大，在一致性和可用性上都有不錯(cuò)的表現(xiàn)。BASE是“基本可用（Basically Available）”“軟狀態(tài)（Soft State）”和“最終一致（Eventually Consistent）”這三個(gè)詞的縮寫。

其中：

• 基本可用是對(duì)可用性的妥協(xié)，指的是在故障時(shí)，系統(tǒng)以響應(yīng)時(shí)間變長(zhǎng)、部分功能不可用或者部分請(qǐng)求失敗為代價(jià)，換取整個(gè)系統(tǒng)仍然可以提供基本的服務(wù)能力。

• 軟狀態(tài)和最終一致則是對(duì)一致性的妥協(xié)。具體地說(shuō)，就是犧牲了原子性和隔離性，允許系統(tǒng)內(nèi)出現(xiàn)外部可見(jiàn)的“中間狀態(tài)”，但需要在短時(shí)間內(nèi)恢復(fù)為一致?tīng)顟B(tài)，達(dá)成最終一致。

在多個(gè)組件構(gòu)成的分布式系統(tǒng)中，如果某個(gè)組件在設(shè)計(jì)上降低了可用性和一致性的等級(jí)，依賴這個(gè)組件的其它組件或外部服務(wù)為了能夠兼容這種降級(jí)設(shè)計(jì)，往往需要付出額外的代價(jià)。因此，設(shè)計(jì)者需要針對(duì)系統(tǒng)的實(shí)際情況來(lái)權(quán)衡決策，謹(jǐn)慎降級(jí)可用性和一致性。基本可用不等于不可用，最終一致也不等于不一致。

接下來(lái)介紹實(shí)踐BASE理論的常用方法和常見(jiàn)誤區(qū)。

“最終一致”允許不一致的中間狀態(tài)被外部可見(jiàn)，但需要在短時(shí)間內(nèi)恢復(fù)為一致?tīng)顟B(tài)。這里面的“短時(shí)間”能否量化呢？

要回答這個(gè)問(wèn)題，我們需要分系統(tǒng)正常和故障二種情況來(lái)分別討論。

在系統(tǒng)正常時(shí)，達(dá)成最終一致的時(shí)間要求是“在系統(tǒng)外部幾乎不可感知”，具體來(lái)說(shuō)應(yīng)該與需要同步狀態(tài)的節(jié)點(diǎn)之間的網(wǎng)絡(luò)時(shí)延差不多。比如，如果系統(tǒng)的節(jié)點(diǎn)都部署在同一個(gè)數(shù)據(jù)中心內(nèi)，達(dá)成最終一致的時(shí)延不應(yīng)超過(guò)幾個(gè)毫秒；對(duì)于一個(gè)全球部署的系統(tǒng)，達(dá)成最終一致的時(shí)延可能需要幾十至幾百毫秒。

在系統(tǒng)發(fā)生網(wǎng)絡(luò)分區(qū)故障時(shí)，為了盡可能保證系統(tǒng)的可用性，需要進(jìn)一步犧牲達(dá)成最終一致的時(shí)延，最長(zhǎng)可能需要等到故障恢復(fù)后系統(tǒng)才能達(dá)成最終一致。

▲圖1 系統(tǒng)故障時(shí)需要更長(zhǎng)的時(shí)間達(dá)成最終一致

犧牲一致性需要守住兩個(gè)底線：防止腦裂和要保證單調(diào)讀寫。

我們首先來(lái)討論底線一：防止腦裂。

例如，傳統(tǒng)MySQL主從結(jié)構(gòu)中，如果主庫(kù)宕機(jī)，或者網(wǎng)絡(luò)分區(qū)導(dǎo)致無(wú)法訪問(wèn)主庫(kù)，也不應(yīng)該去更新從庫(kù)中的數(shù)據(jù)，否則在故障結(jié)束后，系統(tǒng)面對(duì)主庫(kù)和從庫(kù)二份不一樣的數(shù)據(jù)，是無(wú)法自動(dòng)恢復(fù)的。這種情況被稱為“腦裂（Split-brain）”，出現(xiàn)腦裂后，理論上系統(tǒng)的一致性不可恢復(fù)。

工程實(shí)踐中，一般都需要人工介入，借助數(shù)據(jù)的業(yè)務(wù)屬性（比如，同一訂單支付操作一定早于發(fā)貨操作，則可以判斷“已發(fā)貨”狀態(tài)是比“已支付”更新的狀態(tài)），才有可能完成數(shù)據(jù)的一致性修復(fù)。

特別注意的是，不應(yīng)該以狀態(tài)更新的時(shí)間戳來(lái)判斷狀態(tài)數(shù)據(jù)的新舊并用于恢復(fù)一致性。狀態(tài)數(shù)據(jù)中記錄的時(shí)間戳來(lái)自客戶端或服務(wù)端應(yīng)用所在的多個(gè)節(jié)點(diǎn)，而現(xiàn)有的時(shí)間同步技術(shù)所能保證的誤差（10~500ms）過(guò)大，所以用時(shí)間戳來(lái)判斷狀態(tài)新舊極其不可靠。人工恢復(fù)腦裂的代價(jià)往往是“部分?jǐn)?shù)據(jù)丟失”和“更長(zhǎng)的故障恢復(fù)時(shí)長(zhǎng)”。

那么，如何防止腦裂呢？

在我看來(lái)，關(guān)鍵是確保故障后能夠恢復(fù)最終一致。其前提則是，系統(tǒng)需要具備足夠的信息，以判斷出最新的狀態(tài)。然后才能將所有副本的狀態(tài)都恢復(fù)至這一狀態(tài)。在系統(tǒng)故障時(shí)，即使為了保證可用性，也不應(yīng)該違反更新操作的一致性約束。

這里，“更新操作的一致性約束”指的是，系統(tǒng)為了保證一致性，而對(duì)狀態(tài)更新操作施加的約束條件。比如，最簡(jiǎn)單的主從模式下，只能通過(guò)主副本更新?tīng)顟B(tài)，無(wú)論任何原因無(wú)法更新主副本，那就要讓本次更新失敗，犧牲更新操作的可用性。

Paxos等一致性協(xié)議，采用了多數(shù)派（Quorum）機(jī)制保證更新操作的一致性。簡(jiǎn)單地說(shuō)，就是每次更新操作必須在超過(guò)半數(shù)的副本上達(dá)成一致才算更新成功，如果在系統(tǒng)故障時(shí)，更新請(qǐng)求不能達(dá)成多數(shù)派一致，也必須讓本次更新失敗。

接下來(lái)，我們討論單調(diào)讀寫。

最終一致系統(tǒng)在故障時(shí)，為了保證系統(tǒng)持續(xù)可用，應(yīng)允許客戶端從任意一個(gè)尚可訪問(wèn)的節(jié)點(diǎn)上讀取狀態(tài)數(shù)據(jù)。盡管這個(gè)時(shí)候，客戶端讀到的可能并非最新?tīng)顟B(tài)。對(duì)于絕大多數(shù)系統(tǒng)來(lái)說(shuō)，短時(shí)間內(nèi)讀到一個(gè)并非最新?tīng)顟B(tài)都是可接受的。

先來(lái)看第一個(gè)例子。小明用手機(jī)銀行給小華轉(zhuǎn)了100元，當(dāng)小明完成了轉(zhuǎn)賬操作后，實(shí)際上這筆錢已經(jīng)轉(zhuǎn)入到小華的賬戶。如果這個(gè)時(shí)候因?yàn)橄到y(tǒng)故障，小華的手機(jī)銀行上顯示尚未到賬，然后過(guò)了一段時(shí)間之后才顯示到賬，也并非是完全不可接受。

然后我們?cè)賮?lái)看第二個(gè)例子，同樣還是以小明給小華轉(zhuǎn)賬來(lái)說(shuō)明。如圖二所示，在一個(gè)只有主從二副本的最終一致性系統(tǒng)中，轉(zhuǎn)賬成功后主副本的狀態(tài)已更新，小明轉(zhuǎn)給小華的錢已到賬，小華的賬戶余額是100元。但由于同步延遲，從副本中轉(zhuǎn)賬還未到賬，小華的賬戶余額還是0元。

假設(shè)小華第一次查詢賬戶的請(qǐng)求被分配到主副本上，App顯示余額100元。小華再次查詢，這次查詢請(qǐng)求被分配到了從副本上，App顯示余額0元！剛到賬的錢沒(méi)了！

對(duì)小明來(lái)說(shuō)也可能出現(xiàn)類似的問(wèn)題，轉(zhuǎn)賬成功后再查詢賬戶，如果這個(gè)查詢請(qǐng)求被分配到了從副本上（這在配置了讀寫分離的數(shù)據(jù)庫(kù)集群上是默認(rèn)的行為），發(fā)現(xiàn)賬戶余額并沒(méi)有減少，小明以為轉(zhuǎn)賬沒(méi)成功，再次發(fā)起了轉(zhuǎn)賬，結(jié)果多轉(zhuǎn)了100元。

以上這兩種情況，對(duì)外部系統(tǒng)來(lái)說(shuō)無(wú)法判斷讀到的狀態(tài)是否準(zhǔn)確，顯然是不可接受的。

▲圖2 狀態(tài)時(shí)序錯(cuò)亂問(wèn)題

要避免這兩個(gè)問(wèn)題，就需要保證在客戶端視角的一致性。所謂單調(diào)讀寫，要求對(duì)每一個(gè)客戶端來(lái)說(shuō)，每次讀到的狀態(tài)不能比上次一讀寫到的狀態(tài)更舊。簡(jiǎn)單的說(shuō)就是“不能時(shí)序錯(cuò)亂”。實(shí)現(xiàn)單調(diào)讀寫有兩種常用的方法。

第一種方法是通過(guò)保持會(huì)話（Sticky Session）的方式，讓同一個(gè)客戶端的請(qǐng)求總是由與之建立會(huì)話的那個(gè)特定的服務(wù)端節(jié)點(diǎn)（副本）處理。客戶端只與服務(wù)端一個(gè)節(jié)點(diǎn)交互，自然就不會(huì)出現(xiàn)“時(shí)序錯(cuò)亂”的問(wèn)題。

保持會(huì)話的方式實(shí)現(xiàn)比較簡(jiǎn)單，很多網(wǎng)關(guān)都內(nèi)置了保持會(huì)話的功能。如果系統(tǒng)是通過(guò)網(wǎng)關(guān)對(duì)外提供服務(wù)，則可以直接使用。即使系統(tǒng)沒(méi)有使用網(wǎng)關(guān)，只要在客戶端首次連接成功時(shí)，返回服務(wù)端節(jié)點(diǎn)的唯一標(biāo)識(shí)（ID）或URL給客戶端，后續(xù)客戶端就可以用這個(gè)ID或URL繼續(xù)訪問(wèn)同一個(gè)服務(wù)端節(jié)點(diǎn)了。

但保持會(huì)話這種實(shí)現(xiàn)方式的問(wèn)題是，在系統(tǒng)故障時(shí)需要降級(jí)。如果客戶端連不上會(huì)話中的那個(gè)服務(wù)端節(jié)點(diǎn)，只能選擇去連接其它服務(wù)端節(jié)點(diǎn)創(chuàng)建新的會(huì)話。這個(gè)會(huì)話切換的過(guò)程中，仍然存在時(shí)序錯(cuò)亂的可能性。

幸運(yùn)的是時(shí)序錯(cuò)亂只可能發(fā)生在會(huì)話切換過(guò)程中，而會(huì)話切換只在系統(tǒng)故障時(shí)才發(fā)生，發(fā)生概率很低。而且，客戶端是可以感知到會(huì)話切換，從而主動(dòng)從業(yè)務(wù)邏輯上做一些補(bǔ)償。此外，因?yàn)樾枰S持會(huì)話，無(wú)法使用負(fù)載均衡策略，系統(tǒng)的彈性（Elasticity）將受到很大的限制，容易出現(xiàn)熱點(diǎn)問(wèn)題，并且擴(kuò)縮容也會(huì)受到會(huì)話的限制。

另一種方法是，通過(guò)記錄和比較狀態(tài)的版本號(hào)來(lái)實(shí)現(xiàn)單調(diào)讀寫。

系統(tǒng)需要為狀態(tài)數(shù)據(jù)維護(hù)一個(gè)版本號(hào)系統(tǒng)，狀態(tài)版本號(hào)是狀態(tài)的一部分，并且要確保每次狀態(tài)更新，對(duì)應(yīng)版本號(hào)都單調(diào)遞增。這個(gè)狀態(tài)版本號(hào)的目的是，標(biāo)記狀態(tài)更新的先后順序，在英文中也稱為Ephoc或者Logical timestamps。

客戶端需要記錄上一次讀寫狀態(tài)的版本號(hào)，然后在每一次讀取狀態(tài)之前比對(duì)本次版本號(hào)和上次版本號(hào)，如果本次版本號(hào)不小于上次版本號(hào)，就可以認(rèn)為本次讀取的狀態(tài)是可信的。否則，需要丟棄本次讀取結(jié)果，等待一會(huì)兒或者連接其它服務(wù)端重試，以獲取新版本的狀態(tài)數(shù)據(jù)。通過(guò)狀態(tài)版本號(hào)的方式實(shí)現(xiàn)單調(diào)讀寫，可以完美地保證客戶端視角的一致性，但服務(wù)端的實(shí)現(xiàn)則更加復(fù)雜。

04 小結(jié)

我們來(lái)回顧下核心內(nèi)容。

在分布式系統(tǒng)中，平衡可用性和一致性是一個(gè)難題，因此在設(shè)計(jì)過(guò)程中，需要避免未經(jīng)仔細(xì)思考而隨意增加副本的行為。

我們推薦設(shè)計(jì)者在設(shè)計(jì)系統(tǒng)一致性時(shí)能夠兼容最終一致，這樣可以極大提升系統(tǒng)在面臨故障時(shí)保持高可用的難度，在一致性和可用性上取得相對(duì)較好的平衡。但系統(tǒng)最終一致也不等于不一致，需要防止系統(tǒng)出現(xiàn)腦裂，并通過(guò)單調(diào)讀寫保證客戶端視角的一致性。

關(guān)于作者：李玥，美團(tuán)基礎(chǔ)技術(shù)部高級(jí)技術(shù)專家，極客時(shí)間《后端存儲(chǔ)實(shí)戰(zhàn)課》《消息隊(duì)列高手課》等專欄作者。曾在浪潮集團(tuán)、當(dāng)當(dāng)網(wǎng)、京東零售等公司任職。從事互聯(lián)網(wǎng)電商行業(yè)基礎(chǔ)架構(gòu)領(lǐng)域的架構(gòu)設(shè)計(jì)和研發(fā)工作多年，曾多次參與雙十一和618電商大促。專注于分布式存儲(chǔ)、云原生架構(gòu)下的服務(wù)治理、分布式消息和實(shí)時(shí)計(jì)算等技術(shù)領(lǐng)域，致力于推進(jìn)基礎(chǔ)架構(gòu)技術(shù)的創(chuàng)新與開(kāi)源。?

延伸閱讀👇

延伸閱讀《電商存儲(chǔ)系統(tǒng)實(shí)戰(zhàn)》

點(diǎn)擊上圖了解及購(gòu)買

轉(zhuǎn)載請(qǐng)聯(lián)系微信：DoctorData

推薦語(yǔ)：基于實(shí)戰(zhàn)案例系統(tǒng)講解電商系統(tǒng)的存儲(chǔ)設(shè)計(jì)，詳細(xì)分析不同規(guī)模存儲(chǔ)系統(tǒng)的構(gòu)建方法。

干貨直達(dá)👇

• 人工智能時(shí)代，決定未來(lái)的3個(gè)問(wèn)題
  

• 終于有人把正態(tài)分布和二八法則講明白了
  

• vivo真實(shí)案例：中臺(tái)到底解決了什么問(wèn)題？
  

• 這10個(gè)功能模塊，手把手教你從零設(shè)計(jì)電商系統(tǒng)
  

更多精彩👇

在公眾號(hào)對(duì)話框輸入以下關(guān)鍵詞

查看更多優(yōu)質(zhì)內(nèi)容！

讀書?|?書單?|?干貨?|?講明白?|?神操作?|?手把手

大數(shù)據(jù)?|?云計(jì)算?|?數(shù)據(jù)庫(kù)?|?Python?|?爬蟲?|?可視化

AI?|?人工智能?|?機(jī)器學(xué)習(xí)?|?深度學(xué)習(xí)?|?NLP

5G?|?中臺(tái)?|?用戶畫像?|?數(shù)學(xué)?|?算法?|?數(shù)字孿生

據(jù)統(tǒng)計(jì)，99%的大咖都關(guān)注了這個(gè)公眾號(hào)

👇

總結(jié)

以上是生活随笔為你收集整理的如何平衡存储系统的一致性和可用性？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。