“一致性”這個詞經(jīng)常出現(xiàn)在分布式系統(tǒng)相關(guān)的描述中，究竟指的是什么呢？

寫在前面

在分布式存儲系統(tǒng)（包括OceanBase這樣的分布式數(shù)據(jù)庫）的使用中，我們經(jīng)常會提到“一致性”這個詞，但是這個術(shù)語1在不同的系統(tǒng)、不同人的心目中有不同的內(nèi)涵，很容易造成混淆。

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

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

[[222885]]

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

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

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

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

數(shù)據(jù)分為多個分片存儲在多臺服務(wù)節(jié)點上

每個分片有多個副本，存儲在不同的服務(wù)節(jié)點上

許多客戶端并發(fā)訪問系統(tǒng)，執(zhí)行讀寫操作，每個讀寫操作在系統(tǒng)中需要花費不等的時間

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

與數(shù)據(jù)庫事務(wù)一致性的差異

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

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

客戶端視角一致性模型

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

1. 同一份數(shù)據(jù)的所有副本，都能夠接收到全部寫操作（無論需要花費多久時間）
2. 所有副本要以某種確定順序執(zhí)行這些寫操作

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

1. 單調(diào)讀。如果一個客戶端讀到了數(shù)據(jù)的某個版本n，那么之后它讀到的版本必須大于等于n。
2. 讀自己所寫。如果一個客戶端寫了某個數(shù)據(jù)的版本n，那么它之后的讀操作必須讀到大于等于版本n的數(shù)據(jù)。
3. 單調(diào)寫。單調(diào)寫保證同一個客戶端的兩個不同寫操作，在所有副本上都以他們到達存儲系統(tǒng)的相同的順序執(zhí)行。單調(diào)寫可以避免寫操作被丟失。
4. 讀后寫。讀后寫一致性，保證一個客戶端讀到版本n數(shù)據(jù)后（可能是其他客戶端寫入的），隨后的寫操作必須要在版本號大于等于n的副本上執(zhí)行。

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

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

CosmosDB 的一致性級別

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

1.強一致性

• 保證讀操作總是可以讀到最新版本的數(shù)據(jù)（即可線性化）
• 寫操作需要同步到多數(shù)派副本后才能成功提交。讀操作需要多數(shù)派副本應(yīng)答后才返回給客戶端。讀操作不會看到未提交的或者部分寫操作的結(jié)果，并且總是可以讀到最近的寫操作的結(jié)果。
• 保證了全局的（會話間）單調(diào)讀，讀自己所寫，單調(diào)寫，讀后寫
• 讀操作的代價比其他一致性級別都要高，讀延遲最高

2.有界舊一致性(bounded staleness)

• 保證讀到的數(shù)據(jù)最多和最新版本差K個版本
• 通過維護一個滑動窗口，在窗口之外，有界舊一致性保證了操作的全局序。此外，在一個地域內(nèi)，保證了單調(diào)讀。

3.會話一致性

1. 在一個會話內(nèi)保證單調(diào)讀，單調(diào)寫，和讀自己所寫，會話之間不保證
2. 會話一致性能夠提供把讀寫操作的版本信息維護在客戶端會話中，在多個副本之間傳遞

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

4.前綴一致性

• 前綴一致保證，在沒有更多寫操作的情況下，所有的副本最終會一致
• 前綴一致保證，讀操作不會看到亂序的寫操作。例如，寫操作執(zhí)行的順序是`A, B, C`，那么一個客戶端只能看到`A`, `A, B`, 或者`A, B, C`，不會讀到`A, C`，或者`B, A, C`等。
• 在每個會話內(nèi)保證了單調(diào)讀

5.最終一致性.

• 最終一致性保證，在沒有更多寫操作的情況下，所有的副本最終會一致
• 最終一致性是很弱的一致性保證，客戶端可以讀到比之前發(fā)生的讀更舊的數(shù)據(jù)
• 最終一致性可以提供最低的讀寫延遲和最高的可用性，因為它可以選擇讀取任意一個副本

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

Cassandra的一致性級別

Cassandra 是一個使用多數(shù)派協(xié)議的NoSQL存儲系統(tǒng)，通過控制讀寫操作訪問的副本數(shù)和副本的位置，可以實現(xiàn)不同的一致性級別。注意，作為NoSQL系統(tǒng)，Cassandra只提供單行操作的原子性，多行操作不是原子的。下面的讀寫操作，都是指單行操作。

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

寫操作配置

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

• ALL: 寫操作需要同步到所有副本并應(yīng)用到內(nèi)存中。提供了最強的一致性保證，但是單點故障會引起寫入失敗，造成系統(tǒng)不可用。
• EACH_QUORUM: 在每個機房（數(shù)據(jù)中心）中，寫操作同步到多數(shù)派副本節(jié)點中。在多數(shù)據(jù)中心部署的集群中，可以在每個數(shù)據(jù)中心提供QUORUM一致性保證。
• QUORUM: 寫操作同步到多數(shù)派副本節(jié)點中。當(dāng)少數(shù)副本宕機的時候，寫操作可以持續(xù)服務(wù)。
• LOCAL_QUORUM: 寫操作必須同步到協(xié)調(diào)者節(jié)點所在數(shù)據(jù)中心的多數(shù)派副本中。這種模式可以避免多數(shù)據(jù)中心部署時，跨機房同步引起的高延遲。在單機房內(nèi)，可以容忍少數(shù)派宕機。
• ONE: 寫操作必須寫入最少一個副本中。
• TWO: 寫操作必須寫入至少兩個副本中。
• THREE: 寫操作必須寫入至少三個副本中。
• LOCAL_ONE: 寫操作必須寫入本地數(shù)據(jù)中心至少一個副本中。在多機房部署的集群中，可以達到和ONE相同的容災(zāi)效果，并且把寫操作限制在本地機房。

讀操作配置

• 每個讀操作可以設(shè)定如下不同的一致性配置。
• ALL: 讀操作在全部副本節(jié)點應(yīng)答后才返回給客戶端。單點單機會引起寫操作失敗，造成系統(tǒng)不可用。
• QUORUM: 讀操作在多數(shù)派副本返回應(yīng)答后返回給客戶端。
• LOCAL_QUORUM: 讀操作在本機房多數(shù)派副本返回應(yīng)答后返回給客戶端。可以避免跨機房訪問的高延遲。
• ONE: 最近的一個副本節(jié)點應(yīng)答后即返回給客戶端。可能返回舊數(shù)據(jù)。
• TWO: 兩個副本節(jié)點應(yīng)答后即返回給客戶端。
• THREE: 三個副本節(jié)點應(yīng)答后返回給客戶端。
• LOCAL_ONE: 本機房最近的一個副本節(jié)點應(yīng)答后返回客戶端。

系統(tǒng)一致性級別

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

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

OceanBase的一致性級別

一般來說，NoSQL類數(shù)據(jù)庫，比如HBase, Cassandra4等，僅提供單行操作的原子性保證。而關(guān)系數(shù)據(jù)庫的基本操作是一條SQL語句，SQL語句天生是多行操作，而且支持多語句事務(wù)和事務(wù)的回滾等，在SQL語句級和事務(wù)級還都需要提供原子性保證。可以理解，實現(xiàn)相同的一致性級別，分布式關(guān)系數(shù)據(jù)庫比NoSQL類系統(tǒng)的復(fù)雜度和代價都要高。

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

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

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

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

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

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

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

最后，特別感謝 @楊蘇立 閱讀本文，并提出寶貴的修改意見。

參考資料

1 Consistency model in Wikipedia. https://en.wikipedia.org/wiki/Consistency_model

2 Tunable data consistency levels in Azure Cosmos DB. https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels

3 Configuring data consistency in Apache Cassandra. https://docs.datastax.com/en/archived/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html

4 Cassandra 2.0提供了一種輕量級事務(wù)，詳見其文檔。