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

為朝陽縣等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及朝陽縣網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站建設(shè)、成都網(wǎng)站制作、朝陽縣網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

盡管學(xué)術(shù)界幾十年前就開始對分布式數(shù)據(jù)庫系統(tǒng)進(jìn)行研究，但直到最近，某些行業(yè)才開始廣泛使用DDBS。這種趨勢的出現(xiàn)有兩個主要驅(qū)動因素，首先，現(xiàn)代應(yīng)用程序需要增加數(shù)據(jù)和事務(wù)吞吐量，這導(dǎo)致了對彈性可伸縮數(shù)據(jù)庫系統(tǒng)的需求。其次，全球化和業(yè)務(wù)拓展的加快要求將數(shù)據(jù)放在遍布全球的客戶附近。過去10年中試圖實現(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è)計人員理解創(chuàng)建DDBS所涉及的權(quán)衡的工具都是有益的。特別是CAP定理在幫助設(shè)計師推理所提出的系統(tǒng)能力以及揭露許多商業(yè)DDBS的夸大營銷炒作方面非常有用。然而，自從最初的正式證明以來，CAP已經(jīng)變得越來越被誤解和誤用。特別是，許多設(shè)計者錯誤地斷定該定理在正常系統(tǒng)操作期間對DDBS施加了某些限制，因此實現(xiàn)了不必要的系統(tǒng)約束。實際上，CAP僅在面對某些類型的故障時附加了限制，而在正常操作期間不會對系統(tǒng)能力產(chǎn)生任何約束和限制。

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

CAP IS FOR FAILURES 

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

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

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

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

• 分區(qū)容忍

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

該定理簡單地指出網(wǎng)絡(luò)分區(qū)導(dǎo)致系統(tǒng)必須在降低可用性或一致性之間做出決定。網(wǎng)絡(luò)分區(qū)的概率高度依賴于系統(tǒng)實現(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是錯誤的。

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

CONSISTENCY/LATENCY TRADEOFF

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

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

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

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

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

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

DATA REPLICATION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TRADEOFF EXAMPLES

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

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

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

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

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

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

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

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

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

忽略復(fù)制系統(tǒng)的一致性/延遲權(quán)衡是一個大問題，因為它在系統(tǒng)運行期間始終存在。

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

PACELC

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

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

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

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

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

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

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