一致性是高可用的必備條件

在現實世界中，分布式數據庫的節點并不總是處于活動狀態且相互能夠通信的。但是，以上這些故障不應該影響數據庫的可用性。換言之，從用戶的角度來看，整個系統必須像沒有遭到任何故障一樣繼續運行。系統高可用性是分布式數據庫一個極其重要的特性，甚至在軟件工程中，我們始終致力于實現高可用性，并盡量減少停機時間。

為了使系統高度可用，系統需要被設計成允許一個或多個節點的崩潰或不可訪問。為此，我們需要引入如上一講所說的復制技術，其核心就是使用多個冗余的副本來提高系統的可用性。但是，一旦添加了這些副本，我們將面臨使多個數據副本保持同步的問題，并且遭遇故障后如何恢復系統的問題。

這就是 MySQL 復制發展歷程所引入的 RPO 概念，也就是系統不僅僅要可用，而且數據還需要一致。所以高可用必須要盡可能滿足業務連續性和數據一致性這兩個指標。

而我們馬上要介紹的 CAP 理論會告訴我們還有第三個因素——網絡分區會對可用性產生影響。它會告訴我們可用性和一致性在網絡分區下是不能同時滿足的。

CAP 理論與注意事項

首先，可用性是用于衡量系統能成功處理每個請求并作出響應的能力。可用性的定義是用戶可以感知到的系統整體響應情況。但在實踐中，我們希望組成系統的各個組件都可以保持可用性。

其次，我們希望每個操作都保持一致性。一致性在此定義為原子一致性或線性化一致性。線性一致可以理解為：分布式系統內，對所有相同副本上的操作歷史可以被看作一個日志，且它們在日志中操作的順序都是相同的。線性化簡化了系統可能狀態的計算過程，并使分布式系統看起來像在單臺計算機上運行一樣。

最后，我們希望在容忍網絡分區的同時實現一致性和可用性。網絡是十分不穩定的，它經常會分為多個互相獨立的子網絡。在這些子網中，節點間無法相互通信。在這些被分區的節點之間發送的某些消息，將無法到達它的目的地。

那么總結一下，可用性要求任何無故障的節點都可以提供服務，而一致性要求結果需要線性一致。埃里克·布魯爾（Eric Brewer）提出的 CAP 理論討論了一致性、可用性和分區容錯之間的抉擇。

其中提到了，異步系統是無法滿足可用性要求的，并且在存在網絡分區的情況下，我們無法實現同時保證可用性和一致性的系統。不過我們可以構建出，在盡最大努力保證可用性的同時，也保證強一致性的系統；或者在盡最大努力保證一致性的同時，也保證可用性的系統。

這里提到的“最大努力”意味著，如果一切正常，系統可以提供該特性的保證，但是在網絡分區的情況下，允許削弱和違反這個保證。換句話說，CAP 描述了一種組合性選擇，也就是要有取舍。從 CAP 理論的定義，我們可以擁有以下幾種系統。

• CP 系統：一致且容忍分區的系統。更傾向于減少服務時間，而不是將不一致的數據提供出去。一些面向交易場景構建的 NewSQL 數據庫傾向于這種策略，如 TiDB、阿里云 PolarDB、AWS Aurora 等。但是它們會生成自己的 A，也就是可用性很高。
• AP 系統：可用且具有分區容忍性的系統。它放寬了一致性要求，并允許在請求期間提供可能不一致的值。一般是列式存儲，NoSQL 數據庫會傾向于 AP，如 Apache Cassandra。但是它們會通過不同級別的一致性模式調整來提供高一致性方案。

CP 系統的場景實現思路是需要引入共識算法，需要大多數節點參與進來，才能保證一致性。如果要始終保持一致，那么在網絡分區的情況下，部分節點可能不可用。

而 AP 系統只要一個副本就能啟動，數據庫會始終接受寫入和讀取服務。它可能最終會丟失數據或產生不一致的結果。這里可以使用客戶端模式或 Session 模型，來提供一致性的解決方案。

使用 CAP 理論時需要注意一些限制條件。

CAP 討論的是網絡分區，而不是節點崩潰或任何其他類型的故障。這意味著網絡分區后的節點都可能接受請求，從而產生不一致的現象。但是崩潰的節點將完全不受響應，不會產生上述的不一致問題。也就是說，分區后的節點并不是都會面臨不一致的問題。而與之相對的，網絡分區并不能包含真實場景中的所有故障。

CAP 意味著即使所有節點都在運行中，我們也可能會遇到一致性問題，這是因為它們之間存在連接性問題。CAP 理論常常用三角形表示，就好像我們可以任意匹配三個參數一樣。然而，盡管我們可以調整可用性和一致性，但分區容忍性是我們無法實際放棄的。

如果我們選擇了 CA 而放棄了 P，那么當發生分區現象時，為了保證 C，系統需要禁止寫入。也就是，當有寫入請求時，系統不可用。這與 A 沖突了，因為 A 要求系統是可用的。因此，分布式系統理論上不可能選擇 CA 架構，只能選擇 CP 或者 AP 架構。

如下圖所示，其實 CA 類系統是不存在的，這里你需要特別注意。

圖 1 CAP 理論

CAP 中的可用性也不同于上述的高可用性，CAP 定義對請求的延遲沒有任何限制。此外，與 CAP 相反，數據庫的高可用性并不需要每個在線節點都可以提供服務。

CAP 里面的 C 代表線性一致，除了它以外，還有其他的一致模式，我們現在來具體介紹一下。

一致性模型

一致性模型是分布式系統的經典內容，也是入門分布式數據庫的重要知識點。但很少有人知道，其實一致性模型來源于單機理論中的共享內存。

從用戶的角度看，分布式數據庫就像具有共享存儲的單機數據庫一樣，節點間的通信和消息傳遞被隱藏到了數據庫內部，這會使用戶產生“分布式數據庫是一種共享內存”的錯覺。一個支持讀取和寫入操作的單個存儲單元通常稱為寄存器，我們可以把代表分布式數據庫的共享存儲看作是一組這樣的寄存器。

每個讀寫寄存器的操作被抽象為“調用”和“完成”兩個動作。如果“調用”發生后，但在“完成”之前該操作崩潰了，我們將操作定義為失敗。如果一個操作的調用和完成事件都在另一個操作被調用之前發生，我們說這個操作在另一個操作之前，并且這兩個操作是順序的；否則，我們說它們是并發的。

如下圖所示，a）是順序操作，b）和 c）是并發操作。

圖 2 順序操作&并發操作

多個讀取或寫入操作可以同時訪問一個寄存器。對寄存器的讀寫操作不是瞬間完成的，需要一些時間，即調用和完成兩個動作之間的時間。由不同進程執行的并發讀/寫操作不是串行的，根據寄存器在操作重疊時的行為，它們的順序可能不同，并且可能產生不同的結果。

當我們討論數據庫一致性時，可以從兩個維度來區別。

滯后性。它是數據改變的時刻與其副本接收到數據的時刻。這是上一講所介紹的復制延遲場景，一般被歸類為“客戶端一致性”范疇。我們將在“15 | 再談一致性：除了 CAP 之外的一致性模型還有哪些”中進一步討論。

順序性。討論的是各種操作在系統所有副本上執行的順序狀態。這是本講一致性模型所討論的重點。

現在我們對順序性再做進一步的探討。

當面對一系列讀寫操作時，作為人類，我們對它們的執行順序是有一個主觀判斷的。甚至，對于一個單機數據而言，這些操作的順序也是可以確定的。但是，在分布式系統中做出這種判斷就不是那么容易了，因為很難知道什么時候確切地發生了什么，并且很難在整個集群中立刻同步這些操作。

為了推理操作順序并指出真正的結果，我們必須定義一致性模型來保障順序性。

我們怎么來理解模型中“保障”的含義呢？它是將一致性模型視為用戶與數據庫之間的一種約定，每個數據庫副本如何做才能滿足這種順序保障？并且用戶在讀取和寫入數據時期望得到什么？也就是說，即使數據是被并發讀取和寫入的，用戶也可以獲得某種可預測的結果。

需要注意，我們將要討論單一對象和單一操作一致性模型，但現實的數據庫事務是多步操作的，我們將在下面“事務與一致性”部分進一步討論。

下面我按照順序性的保障由強到弱來介紹一致性模型。

嚴格一致性

嚴格的一致性類似于不存在復制過程：任何節點的任何寫入都可立即用于所有節點的后續讀取。它涉及全局時鐘的概念，如果任何節點在時刻 T1 處寫入新數據 A，則所有節點在 T2 時刻（T2 滿足 T2>T1），都應該讀到新寫入的 A。

不幸的是，這只是理論模型，現實中無法實現。因為各種物理限制使分布式數據不可能一瞬間去同步這種變化。

線性一致性

線性一致性是最嚴格的且可實現的單對象單操作一致性模型。在這種模型下，寫入的值在調用和完成之間的某個時間點可以被其他節點讀取出來。且所有節點讀到數據都是原子的，即不會讀到數據轉換的過程和中間未完成的狀態。

線性一致需要滿足的是，新寫入的數據一旦被讀取出來，那么所有后續的讀操作應該能讀取到這個數據。也就是說，一旦一個讀取操作讀到了一個值，那么后續所有讀取操作都會讀到這個數值或至少是“最近”的一個值。

上面的定義來自早期的論文，我將里面的關鍵點提煉一下，如下所示。

• 需要有全局時鐘，來實現所謂的“最近”。因為沒有全局一致的時間，兩個獨立進程沒有相同的“最近”概念。
• 任何一次讀取都能讀到這個“最近”的值。

下面我通過一個例子來說明線性一致性。

現在有三個節點，其中一個共享變量 x 執行寫操作，而第三個節點會讀取到如下數值。

• 第一個讀操作可以返回 1、2 或空（初始值，兩個寫操作之前的狀態），因為兩個寫操作仍在進行中；第一次讀取可以在兩次寫入之前，第一次寫入與第二次寫入之間，以及兩次寫入之后。
• 由于第一次寫操作已完成，但第二次寫操作尚未完成，因此第二次讀操作只能返回 1 和 2。
• 第三次讀只能返回 2，因為第二次寫是在第一次寫之后進行的。

下圖正是現象一致性的直觀展示。

圖 3 線性一致性

線性一致性的代價是很高昂的，甚至 CPU 都不會使用線性一致性。有并發編程經驗的朋友一定知道 CAS 操作，該操作可以實現操作的線性化，是高性能并發編程的關鍵，它就是通過編程手段來模擬線性一致。

一個比較常見的誤區是，使用一致性算法可以實現線性一致，如 Paxos 和 Raft 等。但實際是不行的，以 Raft 為例，算法只是保證了復制 Log 的線性一致，而沒有描述 Log 是如何寫入最終的狀態機的，這就暗含狀態機本身不是線性一致的。

這里推薦你閱讀 TiKV 關于線性一致的實現細節，由于線性一致性價比不高，這里就不進行贅述了，我們接下來說說順序一致性和因果一致性。

順序一致性

由于線性一致的代價高昂，因此人們想到，既然全局時鐘導致嚴格一致性很難實現，那么順序一致性就是放棄了全局時鐘的約束，改為分布式邏輯時鐘實現。順序一致性是指所有的進程以相同的順序看到所有的修改。讀操作未必能及時得到此前其他進程對同一數據的寫更新，但是每個進程讀到的該數據的不同值的順序是一致的。

下圖展示了 P1、P2 寫入兩個值后，P3 和 P4 是如何讀取的。以真實的時間衡量，1 應該是在 2 之前被寫入，但是在順序一致性下，1 是可以被排在 2 之后的。同時，盡管 P3 已經讀取值 1，P4 仍然可以讀取 2。但是需要注意的是這兩種組合：1->2 和 2 ->1，P3 和 P4 從它們中選擇一個，并保持一致。下圖正是展示了它們讀取順序的一種可能：2->1。

圖 4 順序一致性

我們使用下圖來進一步區分線性一致和順序一致。

圖 5 區分線性一致和順序一致

其中，圖 a 滿足了順序一致性，但是不滿足線性一致性。原因在于，從全局時鐘的觀點來看，P2 進程對變量 x 的讀操作在 P1 進程對變量 x 的寫操作之后，然而讀出來的卻是舊的數據。但是這個圖卻是滿足順序一致性，因為兩個進程 P1 和 P2 的一致性并沒有沖突。

圖 b 滿足線性一致性，因為每個讀操作都讀到了該變量的最新寫的結果，同時兩個進程看到的操作順序與全局時鐘的順序一樣。

圖 c 不滿足順序一致性，因為從進程 P1 的角度看，它對變量 y 的讀操作返回了結果 0。那么就是說，P1 進程的對變量 y 的讀操作在 P2 進程對變量 y 的寫操作之前，x 變量也如此。因此這個順序不滿足順序一致性。

在實踐中，你就可以使用上文提到的一致性算法來實現順序一致。這些算法可以保證操作在每個節點都是按照一樣的順序被執行的，所以它們能保證順序一致。

如 Google Megastore 這類系統都是使用 Paxos 算法實現了順序一致性。也就是說在 Megastore 內部，如果有一個數據更新，所有節點都會同步更新，且操作在各個節點上執行順序是一致的。

因果一致性

相比于順序一致性，因果一致性的要求會低一些：它僅要求有因果關系的操作順序是一致的，沒有因果關系的操作順序是隨機的。

因果相關的要求有如下幾點。

• 本地順序：本進程中，事件執行的順序即為本地因果順序。
• 異地順序：如果讀操作返回的是寫操作的值，那么該寫操作在順序上一定在讀操作之前。
• 閉包傳遞：和時鐘向量里面定義的一樣，如果 a->b、b->c，那么肯定也有 a->c。

那么，為什么需要因果關系，以及沒有因果關系的寫法如何傳播？下圖中，進程 P1 和 P2 進行的寫操作沒有因果關系，也就是最終一致性。這些操作的結果可能會在不同時間，以亂序方式傳播到讀取端。進程 P3 在看到 2 之前將看到值 1，而 P4 將先看到 2，然后看到 1。

圖 6 因果一致性

而下圖顯示進程 P1 和 P2 進行因果相關的寫操作并按其邏輯順序傳播到 P3 和 P4。因果寫入除了寫入數據外，還需要附加一個邏輯時鐘，用這個時鐘保證兩個寫入是有因果關系的。這可以防止我們遇到上面那張圖所示的情況。你可以在兩個圖中比較一下 P3 和 P4 的歷史記錄。

圖 7 邏輯時鐘

而實現這個邏輯時鐘的一種主要方式就是向量時鐘。向量時鐘算法利用了向量這種數據結構，將全局各個進程的邏輯時間戳廣播給所有進程，每個進程發送事件時都會將當前進程已知的所有進程時間寫入到一個向量中，而后進行傳播。

因果一致性典型案例就是 COPS 系統，它是基于 causal+一致性模型的 KV 數據庫。它定義了 dependencies，操作了實現因果一致性。這對業務實現分布式數據因果關系很有幫助。另外在亞馬遜 Dynamo 基于向量時鐘，也實現了因果一致性。

事務隔離級別與一致性模型

現在我們談論了一致性模型，但是它與數據庫領域之中的事務有什么區別呢？我先說結論：有關系但又沒有關系。

怎么理解呢？我先來論證它們之間的無關性。

ACID 和 CAP 中的“C”是都是一致性，但是它們的內涵完全不同。其中 ADI 都是數據庫提供的能力保障，但是 C（一致性）卻不是，它是業務層面的一種邏輯約束。

以轉賬這個最為經典的例子而言，甲有 100 元 RMB，乙有 0 元 RMB，現在甲要轉給乙 30 元。那么轉賬前后，甲有 70，乙有 30，合起來還是 100。顯然，這只是業務層規定的邏輯約束而已。

而對于 CAP 這里的 C 上文已經有了明確說明，即線性一致性。它表示副本讀取數據的即時性，也就是對“何時”能讀到“正確”的數據的保證。越是即時，說明系統整體上讀取數據是一致的。

那么它們之間的聯系如何呢？其實就是事務的隔離性與一致模型有關聯。

如果把上面線性一致的例子看作多個并行事務，你會發現它們是沒有隔離性的。因為在開始和完成之間任意一點都會讀取到這份數據，原因是一致性模型關心的是單一操作，而事務是由一組操作組成的。

現在我們看另外一個例子，這是展示事務缺乏一致性后所導致的問題。

圖 8 事務與一致性

其中三個事務滿足隔離性。可以看到 T2 讀取到了 T1 入的值。但是這個系統缺乏一致性保障，造成 T3 可以讀取到早于 T2 讀取值之前的值，這就會造成應用的潛在 Bug。

那現在給出結論：事務隔離是描述并行事務之間的行為，而一致性是描述非并行事務之間的行為。其實廣義的事務隔離應該是經典隔離理論與一致性模型的一種混合。

比如，我們會在一些文獻中看到如“one-copy serializability”“strong snapshot isolation”，等等。前者其實是 serializability 隔離級別加上順序一致，后者是 snapshot 隔離級別加上線性一致。

所以對分布式數據庫來說，原始的隔離級別并沒有舍棄，而是引入了一致性模型后，擴寬數據庫隔離級別的內涵。

總結

今天的內容較長，不過已經精煉很多了。我們從高可用性入手，介紹了 CAP 理論對于分布式模型評估的影響；而后重點介紹了一致性模型，這是核心，用來幫助你評估分布式數據庫的特性。

最后我介紹了事務隔離級別與一致性模型之間的區別與聯系，幫助你認清分布式數據庫下的事務隔離級別的概念。?