阿里妹導讀：分布式存儲系統是一個非常古老的話題，也是分布式系統里最難、最復雜、涉及面最廣的問題之一。本文深入淺出，為大家詳細解釋相關的重要概念。對于分布式系統新人來說，這是一份不可多得的學習資料。

分布式存儲系統模型

在分布式存儲系統（包括OceanBase這樣的分布式數據庫）的使用中，我們經常會提到“一致性”這個詞，但是這個術語【注釋1】在不同的系統、不同人的心目中有不同的內涵，很容易造成混淆。

想象一個最簡單的存儲系統，只有一個客戶端（單進程）和一個服務端（單進程服務）。客戶端順序發起讀寫操作，服務端也順序處理每個請求，那么無論從服務器視角還是從客戶端視角，后一個操作都可以看到前一個操作的結果。

然后，系統變的復雜一些，系統還是單個服務進程（單副本），但是有多個客戶端并發進行操作。這個模型下，多個客戶端的操作會互相影響，比如一個客戶端會讀到不是自己寫的數據（另一個客戶端寫入的）。一般單機并發程序就是這樣的模型，比如多個線程共享內存的程序中。

然后，系統向另外一個方向變的復雜一些，為了讓后端存儲系統更健壯（目的不僅如此），我們可以讓兩個不同的服務進程（位于不同的機器上）同時存儲同一份數據的拷貝，然后，通過某種同步機制讓這兩個拷貝的數據保持一致。這就是我們所說的“多副本”。假設還是一個客戶端進程順序發起讀寫操作，每個操作理論上可以發給兩個副本所在的任意一個服務。那么，如果副本之間是數據同步不及時，就可能發生前面寫入的數據讀不到，或者前面讀到的數據后面讀不到等情況。

結合前兩種模型，在一類真實的系統中，實際存在多個同時執行讀寫操作的客戶端同時讀寫多個副本的后端存儲服務。如果這些不同客戶端的讀寫操作涉及到同一個數據項（比如，文件系統中，同一個文件的同一個位置范圍；或者數據庫系統中同一個表的同一行），那么他們的操作會互相影響。比如，A、B兩個客戶端，操作同一行數據，A修改這行，是不是要求B立即能夠讀到這個最新數據呢？在多副本的系統中，如果不要求上述保證，那么可能可以允許A和B分別操作不同的副本。

更進一步，前面的系統模型中，假設每個服務進程擁有和管理著一份“全量”的數據。而更復雜的系統中，每個服務進程中，只服務整個數據集的一個子集。例如在OceanBase類似的系統中，單機往往是無法容納全部數據的一份副本的，所以，數據庫表和表的分區是分散在多機上提供服務，每個服務進程只負責某些表分區的一個副本。在這樣的系統中，如果一個讀寫操作涉及到的多個分區位于多個服務進程中，可能出現更復雜的讀寫語義的異常情況。比如，一個寫操作W中修改了兩個不同服務進程的兩個不同的分區的副本上的兩個不同的數據項，隨后的一個讀取這兩個數據項的讀操作，是否允許讀到W對一個數據項的修改，而讀不到對另一個數據項的修改？

綜上，我們要討論的通用的分布式存儲系統具有如下特性：

數據分為多個分片存儲在多臺服務節點上

每個分片有多個副本，存儲在不同的服務節點上

許多客戶端并發訪問系統，執行讀寫操作，每個讀寫操作在系統中需要花費不等的時間

除非下文中特別注明和討論，讀寫操作是原子的

與數據庫事務一致性的區別

數據庫事務的ACID的中也有一個一致性（consistency），但彼一致性非此一致性。ACID中的一致性是指，數據庫的事務的執行，或者說事務觀察到的數據，總是要滿足某些全局的 一致性 約束條件，如唯一性約束，外鍵約束等。這個概念和數據庫的數據是否多副本沒關系。而本文的一致性在多副本的語境下才有意義。所以，數據庫事務的一致性，是指數據項之間總是滿足某些約束條件，或者說整個數據庫在滿足約束條件的意義上是 正確 的。

更讓人崩潰的是，事務的隔離性也容易和這里的一致性混淆，因為它和一致性模型類似，限定了某種并發操作的執行順序。事務的隔離性是指并發執行的事務，能以多大的程度看到看到彼此。這個概念也和數據是否多副本沒有關系，單副本的單機數據庫也需要支持不同的隔離級別。比如，如果數據庫設定為可串行化（serializable）隔離級別，那么并發事務的執行結果，必須等價為讓這些事務以某種順序串行執行的結果。事務的隔離性，是為了并發程序（客戶端程序）正確性而生的一種編程抽象，可以類比多線程程序訪問共享數據時候需要解決的競爭。在實際系統中，事務是由一系列讀寫操作組成的，原子的事務的中間狀態是可能被并發的其他事務“觀察”到的。而在一致性模型的討論中，我們假設讀寫操作在服務端是“瞬時”完成的，也就是說，讀寫操作本身是原子的。

客戶端視角一致性模型

在多副本的存儲系統中，無論采用什么樣的多副本同步協議，為了保證多個副本能夠一致，本質上都要求做到：

同一份數據的所有副本，都能夠接收到全部寫操作（無論需要花費多久時間）

所有副本要以某種確定順序執行這些寫操作

客戶視角的一致性模型定義了下面4種不同的保證。

單調讀。如果一個客戶端讀到了數據的某個版本n，那么之后它讀到的版本必須大于等于n。

讀自己所寫。如果一個客戶端寫了某個數據的版本n，那么它之后的讀操作必須讀到大于等于版本n的數據。

單調寫。單調寫保證同一個客戶端的兩個不同寫操作，在所有副本上都以他們到達存儲系統的相同的順序執行。單調寫可以避免寫操作被丟失。

讀后寫。讀后寫一致性，保證一個客戶端讀到版本n數據后（可能是其他客戶端寫入的），隨后的寫操作必須要在版本號大于等于n的副本上執行。

系統對外提供的不同的一致性級別，實際上提供了這其中某幾個保證。不同的一致性級別，限定了系統允許的操作執行順序，以及允許讀到多舊的數據。

為什么要定義不同的一致性級別呢？對用戶來說，當然越嚴格的一致性越好，在異常和復雜場景下，嚴格的一致性級別可以極大地簡化應用的復雜度。但是天下沒有免費的午餐，一般來說，越嚴格的一致性模型，意味著性能（延遲）、可用性或者擴展性（能夠提供服務的節點數）等要有所損失。

Cosmos DB的一致性級別

Azure Cosmos DB【注釋2】是一個支持多地部署的分布式NoSQL數據庫服務。它提供了豐富的可配置的一致性級別。以下五種一致性級別，從前向后可以提供更低的讀寫延遲，更高的可用性，更好的讀擴展性。

強一致性

保證讀操作總是可以讀到最新版本的數據（即可線性化）

寫操作需要同步到多數派副本后才能成功提交。讀操作需要多數派副本應答后才返回給客戶端。讀操作不會看到未提交的或者部分寫操作的結果，并且總是可以讀到最近的寫操作的結果。

保證了全局的（會話間）單調讀，讀自己所寫，單調寫，讀后寫

讀操作的代價比其他一致性級別都要高，讀延遲最高

有界舊一致性(bounded staleness)

保證讀到的數據最多和最新版本差K個版本

通過維護一個滑動窗口，在窗口之外，有界舊一致性保證了操作的全局序。此外，在一個地域內，保證了單調讀。

會話一致性

在一個會話內保證單調讀，單調寫，和讀自己所寫，會話之間不保證

會話一致性把讀寫操作的版本信息維護在客戶端會話中，在多個副本之間傳遞

會話一致性的讀寫延遲都很低

前綴一致性

前綴一致保證，在沒有更多寫操作的情況下，所有的副本最終會一致

前綴一致保證，讀操作不會看到亂序的寫操作。例如，寫操作執行的順序是A, B, C，那么一個客戶端只能看到A, A, B, 或者A, B, C，不會讀到A, C，或者B, A, C等。

在每個會話內保證了單調讀

最終一致性.

最終一致性保證，在沒有更多寫操作的情況下，所有的副本最終會一致

最終一致性是很弱的一致性保證，客戶端可以讀到比之前發生的讀更舊的數據

最終一致性可以提供最低的讀寫延遲和最高的可用性，因為它可以選擇讀取任意一個副本

Cosmos DB的文檔中提到了一個有趣的數字。大約有73%的用戶使用會話一致性級別，有20%的用戶使用有界舊一致性級別。

Cassandra的一致性級別

Cassandra【注釋3】是一個使用多數派協議的NoSQL存儲系統，通過控制讀寫操作訪問的副本數和副本的位置，可以實現不同的一致性級別。注意，作為NoSQL系統，Cassandra只提供單行操作的原子性，多行操作不是原子的。下面的讀寫操作，都是指單行操作。

對于NoSQL系統，一般支持的寫操作叫做PUT（有些系統叫做UPSERT）。這個操作的含義是，如果這行存在（通過唯一主鍵查找），則修改它；如果這行不存在，則插入。這個語義，可以近似（在不考慮二級索引的時候）等價于關系數據庫的INSERT ON DUPLICATE KEY UPDATE語句。本文前面所講的“寫操作”也是泛指這種語義。這個語義有什么特殊之處呢？ 第一， 它是冪等的 。所以PUT操作可以重復執行，不怕消息重傳。第二， 它是覆蓋（overwrite）語義 。所以，NoSQL系統的最終一致性，允許對于同一行數據的寫操作可以亂序，只要寫操作不斷，最終各個副本會一致。而關系數據庫的insert和update等修改語句，內部實現都是即需要讀也需要寫。所以，關系數據庫的多副本一致性，假設簡單地把SQL修改語句同步到多個副本的方式來實現，必須要以相同的順序執行才能保證結果一致（當然，實際系統不能這么實現）。

寫操作配置

寫操作一致性配置定義了對于寫操作在哪些副本上成功之后，才能返回給客戶端。

ALL: 寫操作需要同步到所有副本并應用到內存中。提供了最強的一致性保證，但是單點故障會引起寫入失敗，造成系統不可用。

EACH_QUORUM: 在每個機房（數據中心）中，寫操作同步到多數派副本節點中。在多數據中心部署的集群中，可以在每個數據中心提供QUORUM一致性保證。

QUORUM: 寫操作同步到多數派副本節點中。當少數副本宕機的時候，寫操作可以持續服務。

LOCAL_QUORUM: 寫操作必須同步到協調者節點所在數據中心的多數派副本中。這種模式可以避免多數據中心部署時，跨機房同步引起的高延遲。在單機房內，可以容忍少數派宕機。

ONE: 寫操作必須寫入最少一個副本中。

TWO: 寫操作必須寫入至少兩個副本中。

THREE: 寫操作必須寫入至少三個副本中。

LOCAL_ONE: 寫操作必須寫入本地數據中心至少一個副本中。在多機房部署的集群中，可以達到和ONE相同的容災效果，并且把寫操作限制在本地機房。

讀操作配置

每個讀操作可以設定如下不同的一致性配置。

ALL: 讀操作在全部副本節點應答后才返回給客戶端。單點單機會引起寫操作失敗，造成系統不可用。

QUORUM: 讀操作在多數派副本返回應答后返回給客戶端。

LOCAL_QUORUM: 讀操作在本機房多數派副本返回應答后返回給客戶端。可以避免跨機房訪問的高延遲。

ONE: 最近的一個副本節點應答后即返回給客戶端。可能返回舊數據。

TWO: 兩個副本節點應答后即返回給客戶端。

THREE: 三個副本節點應答后返回給客戶端。

LOCAL_ONE: 本機房最近的一個副本節點應答后返回客戶端。

系統一致性級別

從系統層面來看，Cassandra提供了強一致性和最終一致性兩種一致性級別。不考慮多機房因素，通過設置上述讀寫操作的一致性配置，當寫入副本數與讀取副本數之和大于總副本數的時候，可以保證讀操作總是可以讀取最新被寫入的數據，即強一致性保證。如果寫入副本數與讀取副本數之和小于總副本數的時候，讀操作可能無法讀到最新的數據，而且讀操作可能讀到比之前發生的讀操作更舊的數據，所以這種情況下是最終一致性。

而副本位置是選擇整個集群、每個機房還是本地機房等因素，是為了在不同的容災場景下，對跨機房通訊引入的高延遲進行優化，固有的一致性級別并不受影響。例如，寫操作用EACH_QUORUM，讀操作用LOCAL_QUORUM，還是提供了強一致性保證，但是不同機房的讀操作都變成本地的了，讀延遲較低。但是，和寫操作用QUORUM模式相比，某個機房發生了多數派宕機（總副本數還是少數派），就會導致寫操作失敗。再如，讀寫操作都用LOCAL_QUORUM，那么協調者節點所在機房內是強一致性的，與協調者節點不在一個機房的讀操作則可能讀到舊數據。

OceanBase的一致性級別

一般來說，NoSQL類數據庫，比如HBase, Cassandra【注釋4】等，僅提供單行操作的原子性保證。而關系數據庫的基本操作是一條SQL語句，SQL語句天生是多行操作，而且支持多語句事務和事務的回滾等，在SQL語句級和事務級還都需要提供原子性保證。可以理解，實現相同的一致性級別，分布式關系數據庫比NoSQL類系統的復雜度和代價都要高。

OceanBase使用Multi-Paxos分布式共識算法在多個數據副本之間同步事務提交日志，每個修改事務，要在多數派副本應答以后才認為提交成功。多個副本之間，通過自主投票的機制，選出其中一個副本為主副本（leader），它負責所有修改語句的執行，特別的，達成多數派的事務提交日志要求包含主副本自己。在通常情況下，數據庫需要保證強一致性語義（和單機數據庫類比），我們的做法是，讀寫語句都在主副本上執行。當主副本宕機的時候，其余的多數派副本會選出新的主副本。此時，已經完成的每一個事務一定有至少一個副本記錄了提交日志的。新的主副本通過和其他副本的通信可以獲得所有已提交事務的日志，進而完成恢復，恢復以后繼續提供服務。通過這種機制，OceanBase可以保證在少數派宕機的情況下不會丟失任何數據，而強一致性讀寫服務的宕機恢復時間小于一分鐘。

如果一個語句的執行涉及到多個表的分區，在OceanBase中這些分區的主副本可能位于不同的服務節點上。嚴格的數據庫隔離級別要求涉及多個分區的讀請求看到的是一個“快照”，也就是說，不允許看到部分事務。這要求維護某種形式的全局讀版本號，開銷較大。如果應用允許，可以調整讀一致性級別，系統保證讀到最新寫入的數據，但是不同分區上的數據不是一個快照。從一致性級別來看，這也是強一致性級別，但是打破了數據庫事務的ACID屬性。

在使用數據庫的互聯網業務中，有很多情況下業務組件還允許讀到稍舊的數據，OceanBase提供兩種更弱的一致性級別。在最弱的級別下，我們可以利用所有副本提供讀服務。在OceanBase的實現中，多副本同步協議只保證日志落盤，并不要求日志在多數派副本上完成回放（寫入存儲引擎的memtable中）。所以，利用任意副本提供讀服務時，即使對于同一個分區的多個副本，每個副本完成回放的數據版本也是不同的，這樣可能會導致讀操作讀到比之前發生的讀更舊的數據。也就是說，這種情況下提供的是最終一致性。當任意副本宕機的時候，客戶端可以迅速重試其他副本，甚至當多數派副本宕機的時候還可以提供這種讀服務。

但是，實際上，使用關系數據庫的應用，大多數還是不能容忍亂序讀的。通過在數據庫連接內記錄讀版本號，我們還提供了比最終一致性更嚴格的前綴一致性。它可以在每個數據庫連接內，保證單調讀。這種模式，一般用于OceanBase集群內讀庫的訪問，業務本身是讀寫分離的架構。

此外，對于這兩種弱一致性級別，用戶可以通過配置，控制允許讀到多舊的數據。在多地部署OceanBase的時候，跨地域副本數據之間的延遲是固有的。比如，用戶配置允許讀到30秒內的數據，那么只要本地副本的延遲小于30秒，則讀操作可以讀取本地副本。如果不能滿足要求，則讀取主副本所在地的其他副本。如果還不能滿足，則會讀取主副本。這樣的方式可以獲得最小的讀延遲，以及比強一致性讀更好的可用性。這樣，在同時保證會話級單調讀的條件下，我們提供了有界舊一致性級別。

注意，這些弱一致性級別都是放松了讀操作的語義，而所有的寫操作都需要寫入主副本節點。所以，單調寫和讀后寫總是保證的，但是讀自己所寫是不保證的。理論上，對于后幾種弱一致性級別中的每一種，我們也可以提供讀到的數據是不是保證“快照”的兩種不同語義，但是這違反了ACID語義，所以并沒有提供。

綜上所述，OceanBase在保證關系數據庫完備的ACID事務語義前提下，提供了強一致性、有界舊一致性、前綴一致性和最終一致性這幾種一致性級別。

我們等你加入！

OceanBase團隊是一個追求極致的產品技術團隊，倡導工程師文化，是一個可以讓你專心做事的地方。我們迫切需要來自于數據庫產品生態中各類精英的加入。有興趣的童鞋，點擊文末“閱讀原文”，了解崗位需求、投遞簡歷哦。

感謝 @楊蘇立 對本文的指導意見。本文內容僅代表作者個人觀點，不代表OceanBase官方。

參考

總結

以上是生活随笔為你收集整理的万万没想到，分布式存储系统的一致性是......的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。