原文鏈接: BASE: An Acid Alternative

數(shù)據(jù)庫 ACID，都不陌生：原子性、一致性、隔離性和持久性，這在單臺服務(wù)器就能搞定的時代，很容易實現(xiàn)，但是到了現(xiàn)在，面對如此龐大的訪問量和數(shù)據(jù)量，單臺服務(wù)器已經(jīng)不可能適應(yīng)了，而 ACID 在集群環(huán)境，幾乎不可能達(dá)到我們的預(yù)期，保證了 ACID，效率就會大幅度下降，更要命的是，這么高的要求，不好擴展~于是又了 CAP 原則（Consistency（一致性）、Availability（可用性）、Partition tolerance（分區(qū)容錯性））和 BASE 原則（Basically Available（基本可用）、Soft state（軟狀態(tài)）、Eventually consistent（最終一致）），看看它們的英文，Availability/Basically Available，Consistency/Eventually consistent，基本上，BASE 原則對 CAP 原則的進(jìn)一步詮釋。

本文是Ebay的架構(gòu)師在2008年發(fā)表給ACM的文章,是一篇解釋BASE原則,或者說最終一致性的經(jīng)典文章. 文中Dan討論了BASE與ACID原則的基本差異, 以及如何設(shè)計大型網(wǎng)站以滿足不斷增長的可伸縮性需求,期間如何對業(yè)務(wù)做調(diào)整與折衷. 以及一些具體的折衷技術(shù)的介紹.

　　在對數(shù)據(jù)庫進(jìn)行分區(qū)后,為了可用性(Availability)犧牲部分一致性(Consistency)可以顯著的提升系統(tǒng)的可伸縮性(Scalability).
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——By DAN PRITCHETT, EBAY ,Translated by Jametong

Web應(yīng)用在過去10年變得越來越普及.無論是為最終用戶還是為應(yīng)用開發(fā)者構(gòu)建的應(yīng)用,對這個應(yīng)用的希望很可能都是,此應(yīng)用被最廣泛的用戶使用-廣泛的使用會帶來交易的增長.業(yè)務(wù)如果依賴于持久化,數(shù)據(jù)存儲就很可能成為瓶頸.

擴展任何應(yīng)用都有兩種策略.第一種，也是最簡單的一種，就是 縱向擴展 :將應(yīng)用遷移到更大更強的計算機上. 目前可用的最大的機器也滿足不了它的容量是它最明顯的限制.縱向擴展也很昂貴,增加交易容量通常都需要購買下一個更大的機器.縱向擴展通常還會產(chǎn)生對供應(yīng)商的依賴,從而進(jìn)一步增加成本.

橫向擴展 (Horizontal Scaling)提供了更多的靈活性,但也會顯著的增加復(fù)雜度.橫向數(shù)據(jù)擴展可能沿著兩個方向發(fā)展.按 功能擴展 (Functional Scaling)牽涉到按功能對數(shù)據(jù)進(jìn)行分組,并將不同的功能組分布在多個不同的數(shù)據(jù)庫上.在功能內(nèi)部將數(shù)據(jù)拆分到多個數(shù)據(jù)庫上,也就是進(jìn)行 分片 (Sharding),它為橫向擴展增加一個新的維度.圖-1簡要闡釋了橫向數(shù)據(jù)擴展策略.

圖-1

如圖-1所示,橫向擴展的兩種方法可以同時進(jìn)行運用.用戶信息(Users)、產(chǎn)品信息(Products)與交易信息 (Transactions)可以存儲在不同的數(shù)據(jù)庫中.另外,每個功能區(qū)域根據(jù)其交易容量(transactional capacity)可以再拆分到多個數(shù)據(jù)庫中.如圖所示,功能區(qū)域可以相互獨立地進(jìn)行擴展.

功能分區(qū)(Functional Partitioning)

功能分區(qū)對于實現(xiàn)高可伸縮性相當(dāng)重要.每一種好的數(shù)據(jù)庫架構(gòu)都會根據(jù)功能將概要(Schema)分解到多張表中.用戶(Users)、產(chǎn)品 (Products)、交易(Transactions)以及通訊都是功能分區(qū)的例子. 常用的方法是,利用諸如外鍵(foreign key)一類的數(shù)據(jù)庫概念來維持這些功能區(qū)域之間的數(shù)據(jù)一致性.

依賴數(shù)據(jù)庫的約束保證功能組之間的一致性,會導(dǎo)致數(shù)據(jù)庫的不同概要(schema)在部署策略上高度耦合.要支持約束,表必須存在單一的數(shù)據(jù)庫服務(wù)器上,當(dāng)交易率(transaction rate)增長時也無法對其進(jìn)行橫向擴展.很多情況下, 將數(shù)據(jù)的不同功能組遷移到相互獨立的數(shù)據(jù)庫服務(wù)器上是最容易實現(xiàn)的向外擴展(Scale-out)方案.

可擴展到非常高的交易量的概要會將不同的功能的數(shù)據(jù)放置在不同的數(shù)據(jù)庫服務(wù)器上.這需要將數(shù)據(jù)之間的約束從數(shù)據(jù)庫遷移到應(yīng)用中去. 同時這也將引入一些新的挑戰(zhàn),本文的后續(xù)內(nèi)容會對此進(jìn)行深入探討.

CAP定理(CAP Theorem)

Eric Brewer,一位加州大學(xué)伯克利分校的教授,Inktomi公司的共同創(chuàng)辦人以及首席科學(xué)家,作出了以下推測,Web服務(wù)無法同時滿足以下3個屬性(由其首字母構(gòu)成縮寫CAP):

• 一致性(Consistency).客戶端知道一系列的操作都會同時發(fā)生(生效).
• 可用性(Availability).每個操作都必須以可預(yù)期的響應(yīng)結(jié)束.
• 分區(qū)容錯性(Partition tolerance).即使出現(xiàn)單個組件無法可用,操作依然可以完成.

具體地講,在任何數(shù)據(jù)庫設(shè)計中,一個Web應(yīng)用至多只能同時支持上面的兩個屬性.顯然,任何橫向擴展策略都要依賴于數(shù)據(jù)分區(qū);因此,設(shè)計人員必須在一致性與可用性之間做出選擇.

ACID解決方案

ACID數(shù)據(jù)庫事務(wù)極大地簡化了應(yīng)用開發(fā)人員的工作.正如其縮寫標(biāo)識所示,ACID事務(wù)提供以下幾種保證:

• 原子性(Atomicity).事務(wù)中的所有操作,要么全部成功,要么全部不做.
• 一致性(Consistency).在事務(wù)開始與結(jié)束時,數(shù)據(jù)庫處于一致狀態(tài).
• 隔離性(Isolation). 事務(wù)如同只有這一個操作在被數(shù)據(jù)庫所執(zhí)行一樣.
• 持久性(Durability). 在事務(wù)結(jié)束時,此操作將不可逆轉(zhuǎn).(也就是只要事務(wù)提交,系統(tǒng)將保證數(shù)據(jù)不會丟失,即使出現(xiàn)系統(tǒng)Crash,譯者補充).

數(shù)據(jù)庫廠商在很久以前就認(rèn)識到數(shù)據(jù)庫分區(qū)的必要性,并引入了一種稱為2PC(兩階段提交)的技術(shù)來提供跨越多個數(shù)據(jù)庫實例的ACID保證.這個協(xié)議分為以下兩個階段:

• 第一階段,事務(wù)協(xié)調(diào)器要求每個涉及到事務(wù)的數(shù)據(jù)庫預(yù)提交(precommit)此操作,并反映是否可以提交.
• 第二階段,事務(wù)協(xié)調(diào)器要求每個數(shù)據(jù)庫提交數(shù)據(jù).

如果有任何一個數(shù)據(jù)庫否決此次提交,那么所有數(shù)據(jù)庫都會被要求回滾它們在此事務(wù)中的那部分信息.這樣做的缺陷是什么呢? 我們可以在分區(qū)之間獲得一致性.如果Brewer的猜測是對的,那么我們一定會影響到可用性,但,怎么可以這樣呢?

任何系統(tǒng)的可用性都是執(zhí)行操作的相關(guān)組件的可用性的產(chǎn)物.此陳述的后半段尤其重要.系統(tǒng)中可能會使用但又不是必需的組件,不會降低系統(tǒng)的可用性.在兩階段提交中涉及到兩個數(shù)據(jù)庫的事務(wù),它的可用性是這兩個數(shù)據(jù)庫中每一個的可用性的產(chǎn)物.例如,如果我們假設(shè)每個數(shù)據(jù)庫都有為99.9%的可用性,那么這個事務(wù)的可用性就是99.8%,或者說每月43分鐘的額外停機時間.

關(guān)于兩階段提交，你可以看看"改變未來的九大算法"，里邊有精辟的講解~

一種ACID的替代方案

如果ACID為分區(qū)的數(shù)據(jù)庫提供一致性的選擇,那么你如何實現(xiàn)可用性呢?答案是BASE(基本上可用、軟(弱)狀態(tài)、最終一致性).
BASE與ACID截然相反.ACID比較悲觀,在每個操作結(jié)束時都強制保持一致性,而BASE比較樂觀,接受數(shù)據(jù)庫的一致性處于一種動蕩不定的狀態(tài).雖然,聽起來很難應(yīng)付,實際上這相當(dāng)好管理,并且可帶來ACID無法企及的更高級別的可伸縮性.

BASE的可用性是通過支持局部故障而不是系統(tǒng)全局故障來實現(xiàn)的.下面是一個簡單的例子:如果用戶分區(qū)在5個數(shù)據(jù)庫服務(wù)器上,BASE設(shè)計鼓勵類似的處理方式,這樣一個用戶數(shù)據(jù)庫的故障只會影響這臺特定主機上的那20%的用戶.這里不涉及任何魔法,不過,它確實可以帶來更高的可感知的系統(tǒng)可用性.

因此,到目前為止,你已經(jīng)將數(shù)據(jù)分解到了多個功能組中,并將最繁忙的功能組分區(qū)到了多個數(shù)據(jù)庫中,如何在你的應(yīng)用中應(yīng)用BASE原則呢?與ACID 的典型應(yīng)用場景相比,BASE需要對邏輯事務(wù)中的操作進(jìn)行更加深入的分析.到底該如何進(jìn)行分析呢?后續(xù)的內(nèi)容將提供部分指導(dǎo)原則.

一致性模式(Consistency Patterns)

沿著Brewer的猜測,如果BASE在分區(qū)數(shù)據(jù)庫中選擇保留可用性(Availability), 那么,弱化一定程度的一致性就成為必然的選擇.這通常難以決策,因為商業(yè)投資方與開發(fā)人員都傾向于認(rèn)為一致性(Consistency)對應(yīng)用的成功至關(guān)重要.哪怕是臨時的不一致也瞞不過最終用戶,因此,技術(shù)部門與產(chǎn)品部門都需要參與進(jìn)來,以決定將一致性弱化到什么程度.

圖-2是一個簡單的概要,它闡釋了BASE中一致性要考慮的事情.用戶表存儲用戶信息,同時還包含總銷售額與總購買額.這些都是運行時的統(tǒng)計.交易表存儲每一筆交易,將買家、賣家以及交易金額關(guān)聯(lián)在一起.這些是對實際使用的表進(jìn)行過度簡化后的結(jié)果,不過,它已經(jīng)包含闡釋一致性的多個方面的必要元素.

圖 2

一般來說,功能組之間的一致性要比功能組內(nèi)部的一致性要更加容易弱化.這個示例概要包含兩個功能組:用戶與交易.每當(dāng)售出一個條目(的商品),交易表中就會增加一條記錄,買家與賣家的計數(shù)器都會被更新.使用ACID風(fēng)格的事務(wù),SQL語句可能如圖-3所示.

圖 3

用戶表中的總銷售額的列與總購買額的列可以被認(rèn)為是交易表的一份緩存(Cache).它的存在是為了提高系統(tǒng)的效率.有鑒于此,一致性的約束可以被弱化. 可以調(diào)整一下買家與賣家的期望設(shè)置,從而他們的運行結(jié)余(running balance)不能立即反映交易的結(jié)果.這種情況很常見,實際上,人們經(jīng)常會遇到交易與運行結(jié)余之間的這種延遲(例如,ATM取款或者手機通話).

如何修改SQL語句來弱化一致性要取決于如何定義運行結(jié)余,如果它們只是簡單的估計,也就是部分交易可以被錯過不統(tǒng)計,SQL的修改非常簡單,如圖-4所示.

圖 4

現(xiàn)在,我們已經(jīng)將對用戶表與交易表的更新做了解耦.兩個表之間的一致性將再也無法保證.實際上,在第一個事務(wù)與第二個事務(wù)處理間隔發(fā)生故障,將導(dǎo)致用戶表持久處于不一致的狀態(tài),不過,如果合同約定運行時匯總(running total)是估計值的話,這樣做也足夠了.

如果無法接受估計值,該怎么辦呢?如何繼續(xù)對用戶表與交易表的更新進(jìn)行解耦呢?引入一個持久消息隊列來解決此問題. 有多種選擇可以實現(xiàn)持久消息.然而,實現(xiàn)此消息隊列的最關(guān)鍵的因素是,確保隊列的持久化支持與數(shù)據(jù)庫使用同樣的資源.要實現(xiàn)隊列在不涉及2PC的情況下按事務(wù)提交,這樣做很有必要 .現(xiàn)在的SQL操作看上看去有點不同了,如圖-5所示.

圖 5

這個例子中的語法有點隨意,為了闡釋概念對其邏輯也做了大量的簡化.通過在插入語句的同一個事務(wù)中對持久消息進(jìn)行排隊,可以抓取更新用戶運行結(jié)余所需的信息.這個事務(wù)包含在同一個數(shù)據(jù)庫實例中,因此,它不會影響系統(tǒng)的可用性.

一個獨立的消息處理組件，會從隊列中取出每條消息，并將此信息應(yīng)用到用戶表.這個例子看似解決了所有的問題,但是，還有一個問題沒有解決.為了避免排隊時發(fā)生2PC,消息是持久化在交易的主機上的.如果在涉及到用戶主機的事務(wù)中從隊列中取出消息,我們?nèi)詫⒂龅?PC的情景.

消息處理組件中的2PC的一種解決方案是什么都不做.通過將更新操作解耦到一個獨立的后端(back-end)組件,可以保持面向客戶的組件的可用性.業(yè)務(wù)需要或許可以接受較低的消息處理器的可用性.

不過,假定你的系統(tǒng)完全無法接受2PC.這個問題該如何解決呢?首先,你需要理解等冪概念.如果一個操作被應(yīng)用一次或多次都能取得同樣的結(jié)果,就被認(rèn)為是等冪的.等冪操作非常有用,因為它們允許局部故障,重復(fù)執(zhí)行它們不會改變系統(tǒng)的最終狀態(tài).

從等冪的角度看,所選的這個例子是有問題的.更新操作通常不等冪.這個例子中有累加賬戶列的操作.重復(fù)應(yīng)用此操作顯然會導(dǎo)致錯誤的賬戶余額.然而, 即使是僅僅設(shè)定一個值的更新操作也不是等冪的,因為它還涉及到操作執(zhí)行的順序.如果系統(tǒng)無法保證更新操作按照接收到的順序被應(yīng)用,系統(tǒng)的最終狀態(tài)也將是不正確的.后面的內(nèi)容會進(jìn)一步討論此問題.

在賬戶更新的例子中,你需要一種方式來跟蹤哪些更新已經(jīng)應(yīng)用成功,哪些更新仍然未解決.一種技術(shù)是,使用一個表來記錄已經(jīng)應(yīng)用的那些交易的唯一識別號.

圖-6中展示的表會記錄交易ID、更新了哪個帳號以及應(yīng)用此帳號的用戶ID.現(xiàn)在,我們的樣本偽代碼如圖-7所示.

圖 6

圖 7

這個例子取決于可以窺視隊列中的一條消息,并在成功處理后立即刪除此消息.如有必要,可以通過兩個獨立的事務(wù)來處理它:消息隊列上一個事務(wù),用戶數(shù)據(jù)庫上一個事務(wù).數(shù)據(jù)庫操作成功提交,才提交隊列操作.目前的算法可以支持局部故障,而且又能提供不依賴于2PC的事務(wù)保證.

如果只是關(guān)注更新的順序的話,還有一個更加簡單的技術(shù)可以確保等冪更新.我們來稍微調(diào)整一下我們的示例概要,來闡釋面臨的挑戰(zhàn)以及相應(yīng)的解決方案(見圖-8).

圖 8

假設(shè)兩筆購買交易在一個很短的時間窗口內(nèi)發(fā)生,我們的消息系統(tǒng)無法確保順序操作.您現(xiàn)在面臨的情況是,取決于消息被處理的順序,last_purchase可能出現(xiàn)一個不正確的值.幸運的是,可以通過對SQL語句做點簡單調(diào)整來解決此類更新問題, 如圖-9所描述.

圖 9

僅僅通過不允許last_purchase時間做逆向調(diào)整,就可以做到更新操作順序不相關(guān).也可以通過這種方法來保護任何更新免遭無序更新(out-of-order update).你還可以嘗試使用單調(diào)遞增的事務(wù)ID來取代時間.

消息隊列的順序

關(guān)于順序消息投遞,下面這個簡短地附屬說明可能有用.消息系統(tǒng)可以提供確保消息發(fā)送的順序與接收的順序一致的能力.不過,支持此功能可能非常昂貴,通常也沒有必要,實際上,有時它也只是給出了一種虛假的安全感.

這里提供的例子闡釋了如何弱化消息的順序,并在最終仍然能夠提供一個數(shù)據(jù)庫的一致性視圖.弱化消息排序所需的開銷是名義上的,在大部分情況下,此開銷要顯著的少于在消息系統(tǒng)中確保消息順序的開銷.

進(jìn)一步講,無論互動風(fēng)格如何,Web應(yīng)用在語義上都是一個事件驅(qū)動的系統(tǒng).客戶端請求以任意順序達(dá)到系統(tǒng).每個請求所需的處理時間要求也各不相同. 整個系統(tǒng)的不同組件的請求調(diào)度也是不確定的,導(dǎo)致了消息排隊的不確定.要求保持消息的順序給出的是一種虛假的安全感.簡單的事實是,不確定的輸入會導(dǎo)致不確定的輸出.

弱狀態(tài)/最終一致性(Soft State/Eventually Consistent)

到此為止,重點一直是為了可用性而權(quán)衡犧牲部分一致性.硬幣的另外一面是,理解軟狀態(tài)與最終一致性對應(yīng)用設(shè)計有何影響.
由于軟件工程師傾向于認(rèn)為系統(tǒng)是閉環(huán)(closed loop)的.從預(yù)見投入產(chǎn)生預(yù)見的產(chǎn)出方面講,我們可以這樣考慮他們行為的可預(yù)測性.這對于創(chuàng)建正確的軟件系統(tǒng)非常必要.好的消息是,在大部分情況下使用BASE不會改變一個閉環(huán)系統(tǒng)的可預(yù)測性,不過,它確實需要從整體上來進(jìn)行審視.

一個簡單的例子就可以幫助解釋這一點.考慮這樣一個系統(tǒng),用戶可以在此將資產(chǎn)轉(zhuǎn)移給另一個用戶.哪種類型的資產(chǎn)都沒有關(guān)系,它可以是錢或者游戲中的裝備.對于這個例子,我們假設(shè),已經(jīng)通過使用一個用于解耦的消息隊列,對如下兩個操作進(jìn)行了解耦:從一個用戶取出資產(chǎn),將資產(chǎn)給另一個用戶.

很快,系統(tǒng)就會感覺到有問題與不確定性.在資產(chǎn)離開一個用戶到達(dá)另一個用戶中間,有一段時間的延時. 這個時間窗口的大小由消息系統(tǒng)的設(shè)計所決定.無論如何,在開始狀態(tài)與結(jié)束狀態(tài)之間,始終會有一個時間間隔,在這段時間內(nèi), 看似任何用戶都不享有這筆資產(chǎn).

不過,如果我們從用戶的視角來考慮這個問題,這個時間間隔可能就是無所謂的或者根本就不存在.無論是接收的用戶還是發(fā)出的用戶可能都不知道資產(chǎn)將在何時到達(dá).如果在發(fā)送與接收之間的時間間隔是幾秒鐘,對于具體溝通資產(chǎn)轉(zhuǎn)移的用戶來講,它將是隱蔽的或確實可以忍受的.在這種狀況下,這種系統(tǒng)行為對用戶來講,就是一致并可接受的,即使,我們在實現(xiàn)中依賴了軟狀態(tài)以及最終一致性.

事件驅(qū)動架構(gòu)(Event-Driven Architecture)

如果你確實需要知道,系統(tǒng)將在何時達(dá)到一致的狀態(tài)?你可能需要一種算法,來應(yīng)用到這個狀態(tài)上,不過,僅僅在它達(dá)到一個與后續(xù)請求相關(guān)的一致狀態(tài)時才會被應(yīng)用.

繼續(xù)討論前面的例子,如果在資產(chǎn)到達(dá)時,需要通知用戶,怎么辦? 在將資產(chǎn)交付給接收用戶的那個事務(wù)內(nèi)創(chuàng)建一個事件,就可以提供一種機制,當(dāng)達(dá)到一個事先確定的狀態(tài)時,可以做進(jìn)一步的處理.EDA(事件驅(qū)動架構(gòu),Event-Driven Architecture)可以顯著改善可伸縮性以及架構(gòu)的解耦.對于EDA應(yīng)用的進(jìn)一步討論超出了本文的范疇.

結(jié)論

顯著的擴展系統(tǒng)的交易率,需要以一種全新的方式來考慮如何對資源進(jìn)行管理.當(dāng)負(fù)載需要分布到大量的組件上時,傳統(tǒng)的事務(wù)模型會漏洞百出.對操作進(jìn)行解耦,并依次對它們進(jìn)行處理,可能提供更好的可用性與伸縮性,不過是以犧牲一致性為代價.BASE提供了一種模型來考慮這種解耦.

參考

• http://highscalability.com/unorthodox-approach-database-design-coming-shard.
• http://citeseer.ist.psu.edu/544596.html.

Dan Pritchett是Ebay的一位技術(shù)人員,他過去4年一直是Ebay架構(gòu)團隊的成員.在此崗位上,他與Ebay市場部、Paypal以及Skype的戰(zhàn)略、商業(yè)、產(chǎn)品與技術(shù)團隊進(jìn)行合作.他已經(jīng)有20年技術(shù)公司的工作經(jīng)歷,他服務(wù)過的公司包含Sun,HP以及硅谷圖形公司(Silicon Graphics),Pritchett具有豐富的技術(shù)經(jīng)歷,從網(wǎng)絡(luò)層協(xié)議與操作系統(tǒng)到系統(tǒng)設(shè)計與軟件模式.他擁有密蘇里州Rolla大學(xué)的計算機科學(xué)學(xué)士學(xué)位.

轉(zhuǎn)載于:https://www.cnblogs.com/savorboard/p/base-an-acid-alternative.html

總結(jié)

以上是生活随笔為你收集整理的Base：一种 Acid 的替代方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。