現(xiàn)代分布式存儲(chǔ)系統(tǒng)設(shè)計(jì)中“一致性”的取舍

CAP定理對現(xiàn)代分布式數(shù)據(jù)庫系統(tǒng)設(shè)計(jì)的影響比我們預(yù)想的要小。相反，一致性和延遲之間取舍 - 對幾個(gè)主流DDBS產(chǎn)生了更為直接的影響。本文提出的新理論PACELC，將這種權(quán)衡與CAP結(jié)合起來, 以便對分布式數(shù)據(jù)系統(tǒng)的設(shè)計(jì)權(quán)衡更加系統(tǒng)全面。

盡管學(xué)術(shù)界幾十年前就開始對分布式數(shù)據(jù)庫系統(tǒng)進(jìn)行研究，但直到最近，某些行業(yè)才開始廣泛使用DDBS。這種趨勢的出現(xiàn)有兩個(gè)主要驅(qū)動(dòng)因素，首先，現(xiàn)代應(yīng)用程序需要增加數(shù)據(jù)和事務(wù)吞吐量，這導(dǎo)致了對彈性可伸縮數(shù)據(jù)庫系統(tǒng)的需求。其次，全球化和業(yè)務(wù)拓展的加快要求將數(shù)據(jù)放在遍布全球的客戶附近。過去10年中試圖實(shí)現(xiàn)高可擴(kuò)展性或全球可訪問性(或兩者兼有)的DDBS示例包括SimpleDB/Dynamo/DynamoDB，Cassandra，Voldemort(http://projectvoldemort.com)，Sherpa/PNUTS，Riak (http://wiki.basho.com)，HBase/BigTable，MongoDB(www.mongodb.org)，VoltDB/H-Store和Megastore.

DDBS很復(fù)雜，構(gòu)建它們很困難。因此，任何幫助設(shè)計(jì)人員理解創(chuàng)建DDBS所涉及的權(quán)衡的工具都是有益的。特別是CAP定理在幫助設(shè)計(jì)師推理所提出的系統(tǒng)能力以及揭露許多商業(yè)DDBS的夸大營銷炒作方面非常有用。然而，自從最初的正式證明以來，CAP已經(jīng)變得越來越被誤解和誤用。特別是，許多設(shè)計(jì)者錯(cuò)誤地?cái)喽ㄔ摱ɡ碓谡Ｏ到y(tǒng)操作期間對DDBS施加了某些限制，因此實(shí)現(xiàn)了不必要的系統(tǒng)約束。實(shí)際上，CAP僅在面對某些類型的故障時(shí)附加了限制，而在正常操作期間不會(huì)對系統(tǒng)能力產(chǎn)生任何約束和限制。

盡管如此，在正常操作期間抑制DDBS能力的基本權(quán)衡影響了主流系統(tǒng)的不同設(shè)計(jì)選擇。實(shí)際上，在一致性和延遲之間的一個(gè)特定權(quán)衡 - 可以說對DDBS設(shè)計(jì)的影響比CAP理論更大。兩組權(quán)衡都很重要; 將CAP和一致性/延遲權(quán)衡統(tǒng)一到一個(gè)理論中 - PACELC中可以相應(yīng)地使得對現(xiàn)代DDBS的設(shè)計(jì)進(jìn)行更深入的理解。

CAP IS FOR FAILURES 

CAP表明，在構(gòu)建DDBS時(shí)，設(shè)計(jì)人員可以選擇三個(gè)理想屬性中的兩個(gè)：一致性(C)，可用性(A)和分區(qū)容忍性(P)。因此，只有CA系統(tǒng)(一致且高可用，但不能容忍分區(qū))，CP系統(tǒng)(一致和分區(qū)容錯(cuò)，但不高可用)和AP系統(tǒng)(高可用性和分區(qū)容忍但不一致)是可能的。

許多現(xiàn)代DDBS(包括SimpleDB/Dynamo，Cassandra，Voldemort，Sherpa/PNUTS和Riak)默認(rèn)不保證CAP定義的一致性。 (雖然這些系統(tǒng)中的一些系統(tǒng)的一致性在初始版本發(fā)布后變得可調(diào)，但重點(diǎn)在于它們的原始設(shè)計(jì)。)在他們的CAP證明中，Seth Gilbert和Nancy Lynch使用了原子/線性化一致性的定義：“必須在所有操作中存在一個(gè)全局順序，使得每個(gè)操作看起來好像是在一個(gè)瞬間完成的。這相當(dāng)于要求分布式共享內(nèi)存的請求就像它們在單個(gè)節(jié)點(diǎn)上執(zhí)行一樣，一次響應(yīng)一個(gè)操作。”

鑒于早期的DDBS研究側(cè)重于一致系統(tǒng)，因此很自然地認(rèn)為CAP是對現(xiàn)代系統(tǒng)架構(gòu)師的主要影響，他們在定理證明之后的時(shí)期內(nèi)構(gòu)建了越來越多的系統(tǒng)來實(shí)現(xiàn)簡化的一致性模型。這種假設(shè)背后的原因是，因?yàn)槿魏?/span>DDBS都必須容忍網(wǎng)絡(luò)分區(qū)，所以根據(jù)CAP，系統(tǒng)必須在高可用性和一致性之間進(jìn)行選擇。對于高可用性非常重要的任務(wù)關(guān)鍵型應(yīng)用程序，它別無選擇，只能犧牲一致性。

但是，這種邏輯存在缺陷，與CAP實(shí)際所說的不一致。不僅僅是分區(qū)容忍需要在一致性和可用性之間進(jìn)行權(quán)衡; 相反，它們是以下兩點(diǎn)的組合：

• 分區(qū)容忍

• 網(wǎng)絡(luò)分區(qū)本身的存在

該定理簡單地指出網(wǎng)絡(luò)分區(qū)導(dǎo)致系統(tǒng)必須在降低可用性或一致性之間做出決定。網(wǎng)絡(luò)分區(qū)的概率高度依賴于系統(tǒng)實(shí)現(xiàn)的各種細(xì)節(jié)：它是通過廣域網(wǎng)(WAN)還是僅通過本地集群分布的？什么樣的硬件質(zhì)量？有哪些流程可以確保仔細(xì)執(zhí)行對網(wǎng)絡(luò)配置參數(shù)的更改？冗余程度如何？盡管如此，一般而言，網(wǎng)絡(luò)分區(qū)比較罕見，并且通常不如DDBS中其他嚴(yán)重類型的故障事件一樣頻繁發(fā)生。

基于CAP的決策而在沒有任何分區(qū)發(fā)生的情況下降低一致性的DDBS是錯(cuò)誤的。

由于CAP在基線情況下沒有規(guī)定系統(tǒng)限制，因此假設(shè)在沒有任何分區(qū)的情況下降低一致性的DDBS是錯(cuò)誤的。事實(shí)上，CAP允許系統(tǒng)在沒有分區(qū)時(shí)提供完整的ACID(原子性，一致性，隔離和持久性)保證以及高可用性。因此，該定理并不能完全證明降低一致性的DDBS的默認(rèn)配置(通常還有其他一些ACID保證)

CONSISTENCY/LATENCY TRADEOFF

要了解現(xiàn)代DDBS設(shè)計(jì)，重要的是要實(shí)現(xiàn)這些系統(tǒng)的構(gòu)建背景。亞馬遜最初設(shè)計(jì)的Dynamo用于向其電子商務(wù)平臺(tái)(例如購物車)中的核心服務(wù)提供數(shù)據(jù)。 Facebook構(gòu)建了Cassandra以支持其收件箱搜索功能。 LinkedIn創(chuàng)建了Voldemort，通過其網(wǎng)站上的各種寫密集功能處理在線更新。雅虎構(gòu)建了PNUTS，用于存儲(chǔ)可在每個(gè)網(wǎng)頁視圖中讀取或?qū)懭氲挠脩魯?shù)據(jù)，存儲(chǔ)Yahoo購物頁面的列表數(shù)據(jù)，以及存儲(chǔ)數(shù)據(jù)以服務(wù)其社交網(wǎng)絡(luò)應(yīng)用程序。

在每種情況下，系統(tǒng)通常為即時(shí)構(gòu)建并發(fā)送給活動(dòng)網(wǎng)站用戶的網(wǎng)頁提供數(shù)據(jù)，并接收在線更新。研究表明，延遲是在線互動(dòng)的一個(gè)關(guān)鍵因素：小到100毫秒的增加，就可能大大降低客戶未來繼續(xù)互動(dòng)或返回的可能性

不幸的是，在一致性，可用性和延遲之間存在著根本的權(quán)衡。 (請注意，可用性和延遲可以說是相同的：不可用的系統(tǒng)本質(zhì)上提供了極高的延遲。為了討論的目的，我認(rèn)為延遲大于典型請求超時(shí)的系統(tǒng)，例如幾秒鐘就意味著不可用；延遲小于請求超時(shí)，但仍然接近幾百毫秒的情況為“高延遲”。但是，我最終會(huì)放棄這種區(qū)別，并允許低延遲要求包含兩種情況。因此，權(quán)衡實(shí)際上只是在一致性和延遲之間，正如本文的標(biāo)題所示。)

即使沒有網(wǎng)絡(luò)分區(qū)，這種權(quán)衡也存在，因此與CAP描述的權(quán)衡完全分開。盡管如此，它是設(shè)計(jì)上述系統(tǒng)的關(guān)鍵因素。 (與此討論無關(guān)，是否將單個(gè)機(jī)器故障視為特殊類型的網(wǎng)絡(luò)分區(qū)。)

權(quán)衡的原因是高可用性要求意味著系統(tǒng)必須復(fù)制數(shù)據(jù)。如果系統(tǒng)運(yùn)行的時(shí)間足夠長，系統(tǒng)中至少有一個(gè)組件最終會(huì)失敗。發(fā)生此故障時(shí)，除非系統(tǒng)在故障之前復(fù)制了另一版本的數(shù)據(jù)，否則組件控制的所有數(shù)據(jù)都將變?yōu)椴豢捎谩?/span>因此，即使在沒有故障本身的情況下，故障的可能性也意味著可用性要求在正常系統(tǒng)操作期間需要一定程度的數(shù)據(jù)復(fù)制。 (注意這種權(quán)衡和CAP權(quán)衡之間的重要區(qū)別：雖然失敗的發(fā)生導(dǎo)致CAP權(quán)衡，但失敗的可能性本身會(huì)導(dǎo)致這種權(quán)衡。)

為了實(shí)現(xiàn)盡可能高的可用性，DDBS必須通過WAN復(fù)制數(shù)據(jù)，以防止整個(gè)數(shù)據(jù)中心因例如颶風(fēng)，恐怖襲擊而發(fā)生故障，或者像2011年4月著名的Amazon EC2云中斷一樣，單個(gè)網(wǎng)絡(luò)配置錯(cuò)誤。上面提到的五個(gè)降低一致性系統(tǒng)的設(shè)計(jì)具有極高的可用性，通常用于通過WAN進(jìn)行復(fù)制。

DATA REPLICATION

一旦DDBS復(fù)制數(shù)據(jù)，就會(huì)出現(xiàn)一致性和延遲之間的權(quán)衡。發(fā)生這種情況是因?yàn)閷?shí)現(xiàn)數(shù)據(jù)復(fù)制只有三種選擇：系統(tǒng)同時(shí)向所有副本發(fā)送數(shù)據(jù)更新，首先向某個(gè)一致的主節(jié)點(diǎn)發(fā)送數(shù)據(jù)更新，或者首先向單個(gè)(任意)節(jié)點(diǎn)發(fā)送數(shù)據(jù)更新。系統(tǒng)可以以各種方式實(shí)現(xiàn)這些情況中的每一種; 但是，每個(gè)實(shí)現(xiàn)都帶有一致性/延遲權(quán)衡。

• (1) Data updates sent to all replicas at the same time

如果更新沒有首先通過預(yù)處理層或其他協(xié)議協(xié)議，則可能會(huì)出現(xiàn)副本分歧 - 明顯缺乏一致性(假設(shè)系統(tǒng)的多個(gè)更新同時(shí)提交，例如，來自不同的客戶端)，因?yàn)槊總€(gè)副本可能選擇應(yīng)用更新的不同順序。 (即使所有更新都是可交換的 - 這樣每個(gè)副本最終都會(huì)變得一致，盡管副本可能會(huì)以不同的順序應(yīng)用更新 — 但以Gilbert和Lynch對一致性的嚴(yán)格定義來衡量，這任然不是一個(gè)一致性的系統(tǒng)。但是，廣義的Paxos可以通過一次RTT的代價(jià)提供一致的復(fù)制。)

另一方面，如果更新首先通過預(yù)處理層或者寫入過程中協(xié)調(diào)所有節(jié)點(diǎn)來決定操作的順序，那么可以確保所有副本就更新的順序達(dá)成一致。但是，這會(huì)導(dǎo)致延遲增加。比如使用協(xié)議的情況下，協(xié)議本身是延遲的來源之一。

在預(yù)處理的情況下，有兩個(gè)延遲源。首先，通過附加系統(tǒng)組件(預(yù)處理模塊)路由更新會(huì)增加延遲。其次，預(yù)處理模塊由多臺(tái)機(jī)器或一臺(tái)機(jī)器組成。在前一種情況下，需要一個(gè)協(xié)議來決定整個(gè)機(jī)器的操作順序。在后一種情況下，即使另一個(gè)數(shù)據(jù)副本更接近更新發(fā)起位置，系統(tǒng)也會(huì)強(qiáng)制所有更新，無論它們在何處發(fā)起 - 可能在世界的任何地方 - 首先一直路由到單個(gè)預(yù)處理模塊。

• (2) Data updates sent to an agreed-upon location first

我將這個(gè)商定的位置稱為“主節(jié)點(diǎn)”(不同的數(shù)據(jù)項(xiàng)可以有不同的主節(jié)點(diǎn))。此主節(jié)點(diǎn)解析所有更新數(shù)據(jù)項(xiàng)的請求，并且它選擇執(zhí)行這些更新的順序決定了所有副本執(zhí)行更新的順序。主節(jié)點(diǎn)解析更新后，會(huì)將它們復(fù)制到所有副本位置。

一旦DDBS復(fù)制數(shù)據(jù)，就會(huì)出現(xiàn)一致性和延遲之間的權(quán)衡。

有三種復(fù)制選項(xiàng): 

1. 復(fù)制是同步的：主節(jié)點(diǎn)等待，直到所有更新都進(jìn)入副本。這確保了副本保持一致，但是由于需要在這些實(shí)體之間傳遞消息以及延遲受最慢實(shí)體限制的事實(shí)，跨獨(dú)立實(shí)體(尤其是WAN)的同步操作會(huì)增加延遲。

2. 復(fù)制是異步的：系統(tǒng)將更新視為在復(fù)制之前完成更新。通常，在更新的發(fā)起者獲知它已完成復(fù)制之前(如果主節(jié)點(diǎn)發(fā)生故障)，更新至少已經(jīng)在某處持久化存儲(chǔ)，但不保證系統(tǒng)已傳播更新。在這種情況下，一致性/延遲權(quán)衡取決于系統(tǒng)如何處理讀取:
   i. 如果系統(tǒng)將所有讀取路由到主節(jié)點(diǎn)并從那里提供服務(wù)，則不會(huì)降低一致性。但是，這種方法存在兩個(gè)延遲問題:
   1. 即使有一個(gè)靠近讀取請求發(fā)起者的副本，系統(tǒng)仍然必須將請求路由到主節(jié)點(diǎn)，這可能在物理上更遠(yuǎn)
   2. 如果主節(jié)點(diǎn)因其他請求過載或發(fā)生故障，則無法從其他節(jié)點(diǎn)提供讀取服務(wù)。相反，請求必須等待主節(jié)點(diǎn)變?yōu)榭臻e或恢復(fù)。換句話說，缺乏負(fù)載平衡選項(xiàng)會(huì)增加潛在延遲

3. ii. 如果系統(tǒng)可以從任何節(jié)點(diǎn)提供讀取，則讀取延遲要好得多，但這也會(huì)導(dǎo)致 同一數(shù)據(jù)項(xiàng)的讀取不一致，因?yàn)椴煌恢迷谙到y(tǒng)仍在傳播更新時(shí)具有不同版本的數(shù)據(jù)項(xiàng)，并且可以向任何這些位置發(fā)送讀取。盡管可以通過跟蹤更新序列號并使用它們來實(shí)現(xiàn)順序/時(shí)序一致性或讀寫一致性來限制一致性降低的程度，但這些仍然是一種殘次的一致性模型。此外，如果寫操作的主節(jié)點(diǎn)在地理上遠(yuǎn)離寫請求者，則寫延遲可能很高

4.  (a)和(b)的組合是可能的：系統(tǒng)同步地向副本的某個(gè)子集發(fā)送更新，而其余的異步發(fā)送。在這種情況下，一致性/延遲權(quán)衡再次取決于系統(tǒng)如何處理讀?。?/span>

     i. 如果它將讀取路由到至少一個(gè)已同步更新的節(jié)點(diǎn) - 例如，當(dāng)Quorum協(xié)議中的R + W> N時(shí)，其中R是同步讀取中涉及的節(jié)點(diǎn)數(shù)，W是節(jié)點(diǎn)數(shù)參與同步寫入，N是副本的數(shù)量 - 然后可以保持一致性。然而，(a)，(b)(i)(1)和(b)(i)(2)的等待時(shí)間問題都存在，盡管程度稍低，因?yàn)橥街猩婕暗墓?jié)點(diǎn)數(shù)量更小，并且多個(gè)節(jié)點(diǎn)可以提供讀取請求。
ii. 如果系統(tǒng)有可能從尚未同步更新的節(jié)點(diǎn)提供讀取，例如，當(dāng)R +W≤N時(shí)，則可能存在不一致的讀取，如(b)(ii)中所示。從技術(shù)上講，簡單地使用Quorum協(xié)議并不足以保證Gilbert和Lynch定義標(biāo)準(zhǔn)的一致性。但是，確保完全一致性所需的附加協(xié)議在此處不相關(guān)，因?yàn)榧词箾]有這些附加條件，延遲也是Quorum協(xié)議中固有的。

• (3) Data updates sent to an arbitrary location first

這種情況與(2)之間的區(qū)別在于系統(tǒng)為特定數(shù)據(jù)項(xiàng)發(fā)送更新的位置并不總是相同的。例如，可以同時(shí)在兩個(gè)不同位置發(fā)起針對特定數(shù)據(jù)項(xiàng)的兩個(gè)不同更新。一致性/延遲權(quán)衡再次取決于兩個(gè)選項(xiàng)

a. 如果復(fù)制是同步的，則存在(2)(a)的延遲問題。另外，該系統(tǒng)可能產(chǎn)生額外的延遲，以檢測和解決在兩個(gè)不同位置發(fā)起的同一數(shù)據(jù)項(xiàng)的同時(shí)更新的情況
b. 如果復(fù)制是異步的，則存在類似于(1)和(2)(b)的一致性問題

TRADEOFF EXAMPLES

無論DDBS如何復(fù)制數(shù)據(jù)，顯然它必須權(quán)衡一致性和延遲。對于短距離精心控制的復(fù)制，存在合理的選項(xiàng)，如(2)(a)，因?yàn)楸镜財(cái)?shù)據(jù)中心的網(wǎng)絡(luò)通信延遲很小;但是，對于通過WAN進(jìn)行復(fù)制，無法繞過一致性/延遲權(quán)衡。

為了更全面地理解這種權(quán)衡，考慮四個(gè)DDBS為達(dá)到極高的可用性，是如何設(shè)計(jì)的 — Dynamo，Cassandra，PNUTS和Riak。由于這些系統(tǒng)是為與活動(dòng)Web客戶端的低延遲交互而設(shè)計(jì)的，因此每個(gè)系統(tǒng)都犧牲了一致性以降低延遲。 

Dynamo，Cassandra和Riak使用(2)(c)和(3)的組合。特別是，系統(tǒng)將更新發(fā)送到同一節(jié)點(diǎn)，然后將這些更新同步傳播到其他W節(jié)點(diǎn) - 即情況(2)(c)。系統(tǒng)同步向R節(jié)點(diǎn)發(fā)送讀取，R + W通常設(shè)置為小于或等于N的數(shù)字，導(dǎo)致讀取不一致的可能性。但是，系統(tǒng)并不總是將更新發(fā)送到特定數(shù)據(jù)項(xiàng)的同一節(jié)點(diǎn) - 例如，這可能發(fā)生在各種故障情況下，或者由于負(fù)載均衡器的重新路由。這導(dǎo)致了(3)中描述的情況以及可能更大的一致性缺陷。 PNUTS使用選項(xiàng)(2)(b)(ii)，在降低一致性的情況下實(shí)現(xiàn)更好的延遲。 

Jun Rao，Eugene Shekita和Sandeep Tata最近的一項(xiàng)研究進(jìn)一步證明了這些系統(tǒng)基線實(shí)施的一致性/延時(shí)權(quán)衡。研究人員通過實(shí)驗(yàn)評估了Cassandra一致性/延遲權(quán)衡中的兩個(gè)選項(xiàng)。第一個(gè)選項(xiàng)“弱讀取”允許系統(tǒng)為任何副本的讀取提供服務(wù)，即使該副本尚未收到數(shù)據(jù)項(xiàng)的所有未完成更新。第二個(gè)選項(xiàng)“Quorum讀取”要求系統(tǒng)在讀取數(shù)據(jù)之前明確檢查多個(gè)副本之間的不一致性。相對于第一種選擇，第二種選擇顯然是以延遲為代價(jià)而增加了一致性。這兩個(gè)選項(xiàng)之間的延遲差異可達(dá)四倍或更多。

Hiroshi Wada及其同事的另一項(xiàng)研究似乎與此結(jié)果相矛盾。這些研究人員發(fā)現(xiàn)，相對于默認(rèn)(可能不一致)的讀取選項(xiàng)，在SimpleDB中請求一致讀取不會(huì)顯著增加延遲。然而，研究人員在Amazon某個(gè)Zone(美國西部)內(nèi)部進(jìn)行了實(shí)驗(yàn)，他們推測SimpleDB使用主從復(fù)制，如果復(fù)制發(fā)生在短距離內(nèi)，則可以以適度的延遲成本實(shí)現(xiàn)。特別是，Wada及其同事得出結(jié)論，SimpleDB強(qiáng)制所有一致讀取都要由master執(zhí)行。只要讀取請求來自物理上靠近master的位置，并且只要主設(shè)備沒有過載，那么一致讀取的額外延遲是不可見的(這些條件在他們的實(shí)驗(yàn)中都是正確的)

如果SimpleDB跨Amazon區(qū)域復(fù)制數(shù)據(jù)，并且讀取請求來自與master位置不同的區(qū)域，則一致性讀取的延遲成本將更加明顯。即使沒有跨區(qū)域復(fù)制(SimpleDB目前不支持跨區(qū)域復(fù)制)，官方的亞馬遜文檔也會(huì)警告用戶延遲增加并降低吞吐量以實(shí)現(xiàn)一致性讀取。

所有四個(gè)DDBS都允許用戶更改默認(rèn)參數(shù)以換取更好的一致性和更大的延時(shí) - 例如，通過在Quorum類型系統(tǒng)中使R + W大于N.盡管如此，即使在沒有網(wǎng)絡(luò)分區(qū)的情況下，在正常系統(tǒng)操作期間也會(huì)發(fā)生一致性/等待時(shí)間權(quán)衡。如果通過WAN進(jìn)行數(shù)據(jù)復(fù)制，則權(quán)衡會(huì)被放大。顯而易見的結(jié)論是，一致性降低可歸因于運(yùn)行時(shí)延遲，而不是CAP。 PNUTS提供了最有力的證據(jù)表明：CAP不是這些系統(tǒng)中降低一致性水平的主要原因。在PNUTS中，主節(jié)點(diǎn)擁有每個(gè)數(shù)據(jù)項(xiàng)。系統(tǒng)將對該數(shù)據(jù)項(xiàng)的更新路由到主節(jié)點(diǎn)，然后通過WAN將這些更新異步傳播到副本。 PNUTS可以從任何副本提供讀取，這將系統(tǒng)置于類別(2)(b)(ii)中：它降低了一致性以實(shí)現(xiàn)更好的延遲。但是，在網(wǎng)絡(luò)分區(qū)的情況下，主節(jié)點(diǎn)在少數(shù)分區(qū)內(nèi)變得不可用，系統(tǒng)默認(rèn)使數(shù)據(jù)項(xiàng)不可用于更新。換句話說，PNUTS默認(rèn)配置實(shí)際上是CP：在分區(qū)的情況下，系統(tǒng)選擇一致性以避免解決在不同主節(jié)點(diǎn)處發(fā)起的沖突更新的問題。

因此，降低基線情況一致性的選擇更明顯地歸因于持續(xù)的一致性/等待時(shí)間權(quán)衡，而不是CAP中的一致性/可用性權(quán)衡，這僅在網(wǎng)絡(luò)分區(qū)上發(fā)生。 當(dāng)然，PNUTS在基線情況下一致性不友好的缺陷，在網(wǎng)絡(luò)分區(qū)情況下也許很有用，因?yàn)樵诓豢捎梅謪^(qū)中的數(shù)據(jù)仍然可以讀取。

CAP對其他三個(gè)系統(tǒng)產(chǎn)生更大的影響可能更大一些。如果發(fā)生網(wǎng)絡(luò)分區(qū)，Dynamo，Cassandra和Riak會(huì)更充分地切換到數(shù)據(jù)復(fù)制選項(xiàng)(3)，并使用在檢測到副本差異時(shí)運(yùn)行的特殊協(xié)調(diào)代碼來處理產(chǎn)生的一致性問題。因此，可以合理地假設(shè)這些系統(tǒng)的設(shè)計(jì)考慮了網(wǎng)絡(luò)分區(qū)的可能性。因?yàn)檫@些是AP系統(tǒng)，所以從一開始就將協(xié)調(diào)代碼和切換到(3)的能力內(nèi)置到代碼中。但是，一旦該代碼存在，就可以方便地重用一些靈活的一致性模型來選擇基線一致性/延遲權(quán)衡中的一個(gè)點(diǎn)。這個(gè)論點(diǎn)比聲稱這些系統(tǒng)的設(shè)計(jì)者選擇完全降低CAP的一致性(忽略延遲因子)更合乎邏輯。

忽略復(fù)制系統(tǒng)的一致性/延遲權(quán)衡是一個(gè)大問題，因?yàn)樗谙到y(tǒng)運(yùn)行期間始終存在。

總之，CAP只是現(xiàn)代DDBS降低一致性的兩個(gè)主要原因之一。忽略復(fù)制系統(tǒng)的一致性/等待時(shí)間折衷是一個(gè)大問題，因?yàn)樗谙到y(tǒng)操作期間始終存在，而CAP僅與可能極少的網(wǎng)絡(luò)分區(qū)情況相關(guān)。實(shí)際上，前者的權(quán)衡可能更有影響力，因?yàn)樗鼘ο到y(tǒng)的基線操作有更直接的影響。

PACELC

通過將CAP重寫為PACELC(發(fā)音為“pass-elk”)可以實(shí)現(xiàn)對DDBS潛在一致性權(quán)衡空間的更完整描述：如果存在分區(qū)(P)，系統(tǒng)如何權(quán)衡可用性和一致性(A 和C); 否則(E)，當(dāng)系統(tǒng)在沒有分區(qū)的情況下正常運(yùn)行時(shí)，系統(tǒng)如何權(quán)衡延遲(L)和一致性(C)？

請注意，延遲/一致性權(quán)衡(ELC)僅適用于復(fù)制數(shù)據(jù)的系統(tǒng)。否則，系統(tǒng)會(huì)遇到任何類型的故障或節(jié)點(diǎn)過載時(shí)的可用性問題。由于此類問題只是極端延遲的實(shí)例，因此ELC權(quán)衡的延遲部分可以包含是否復(fù)制數(shù)據(jù)的選擇。

Dynamo，Cassandra和Riak的默認(rèn)版本是PA/EL系統(tǒng)：如果發(fā)生分區(qū)，它們會(huì)選擇可用性而放棄一致性，在正常操作下，它們會(huì)放棄一致性以降低延遲。放棄PACELC中的兩個(gè)C使設(shè)計(jì)更簡單; 一旦系統(tǒng)配置為處理不一致，就有選擇放棄一致性而提供更好的可用性和較低的延遲。然而，這些系統(tǒng)具有用戶可調(diào)整的設(shè)置以改變ELC權(quán)衡 - 例如，通過增加R + W，它們以延遲為代價(jià)獲得更高的一致性(盡管它們無法實(shí)現(xiàn)Gilbert和Lynch定義的完全一致性，即使R + W> N)。

完全ACID系統(tǒng)(如VoltDB/H-Store和Megastore)是PC/EC：它們拒絕放棄一致性，并將支付實(shí)現(xiàn)它的可用性和延遲成本。 BigTable和相關(guān)系統(tǒng)(如HBase)也是PC/EC。

MongoDB可以歸類為PA/EC系統(tǒng)。在基線情況下，系統(tǒng)保證讀取和寫入一致。但是，MongoDB使用數(shù)據(jù)復(fù)制選項(xiàng)(2)，如果主節(jié)點(diǎn)發(fā)生故障或與系統(tǒng)的其余部分分區(qū)，則它會(huì)存儲(chǔ)已發(fā)送到主節(jié)點(diǎn)但尚未復(fù)制到本地回滾目錄中的所有寫入。同時(shí)，系統(tǒng)的其余部分選擇一個(gè)新的主服務(wù)器以保持可讀和寫入狀態(tài)。因此，舊主服務(wù)器的狀態(tài)和新主服務(wù)器的狀態(tài)變得不一致，直到系統(tǒng)修復(fù)故障并使用回滾目錄來協(xié)調(diào)狀態(tài)，這個(gè)過程目前是手動(dòng)的。 (從技術(shù)上講，當(dāng)發(fā)生分區(qū)時(shí)，根據(jù)CAP的可用性定義，MongoDB不可用，因?yàn)樯贁?shù)分區(qū)不可用。但是，在PACELC的上下文中，因?yàn)榉謪^(qū)導(dǎo)致比可用性問題更多的一致性問題，MongoDB可以歸類為PA/EC系統(tǒng)。)

PNUTS是一個(gè)PC/EL系統(tǒng)。在正常操作中，它選擇更好的延時(shí)而放棄了一致性; 但是，如果發(fā)生分區(qū)，它會(huì)放棄可用性以保持一致性。這無疑令人困惑：據(jù)PACELC稱，PNUTS似乎在網(wǎng)絡(luò)分區(qū)上更加一致。但是，不應(yīng)以這種方式解釋PC/EL。 PC并不表示系統(tǒng)完全一致; 相反，它表示當(dāng)發(fā)生網(wǎng)絡(luò)分區(qū)時(shí)，系統(tǒng)不會(huì)降低超出基準(zhǔn)一致性級別的一致性 - 相反，它會(huì)降低可用性

構(gòu)建分布式數(shù)據(jù)庫系統(tǒng)所涉及的權(quán)衡是復(fù)雜的，CAP和PACELC都無法解釋它們。盡管如此，將一致性/延遲權(quán)衡結(jié)合到現(xiàn)代DDBS設(shè)計(jì)考慮中是非常重要的，以保證使權(quán)衡更接近架構(gòu)討論的最前沿。