資料庫 ACID，都不陌生：原子性、一致性、隔離性和永續性，這在單臺伺服器就能搞定的時代，很容易實現，但是到了現在，面對如此龐大的訪問量和資料量，單臺伺服器已經不可能適應了，而 ACID 在叢集環境，幾乎不可能達到我們的預期，保證了 ACID，效率就會大幅度下降，更要命的是，這麼高的要求，不好擴充套件~於是又了 CAP 原則（Consistency（一致性）、Availability（可用性）、Partition tolerance（分割槽容錯性））和 BASE 原則（Basically Available（基本可用）、Soft state（軟狀態）、Eventually consistent（最終一致）），看看它們的英文，Availability/Basically Available，Consistency/Eventually consistent，基本上，BASE 原則對 CAP 原則的進一步詮釋。

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

　　在對資料庫進行分割槽後,為了可用性(Availability)犧牲部分一致性(Consistency)可以顯著的提升系統的可伸縮性(Scalability).
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——By DAN PRITCHETT, EBAY ,Translated by Jametong

Web應用在過去10年變得越來越普及.無論是為終端使用者還是為應用開發者構建的應用,對這個應用的希望很可能都是,此應用被最廣泛的使用者使用-廣泛的使用會帶來交易的增長.業務如果依賴於持久化,資料儲存就很可能成為瓶頸.

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

橫向擴充套件 (Horizontal Scaling)提供了更多的靈活性,但也會顯著的增加複雜度.橫向資料擴充套件可能沿著兩個方向發展.按 功能擴充套件

圖-1

如圖-1所示,橫向擴充套件的兩種方法可以同時進行運用.使用者資訊(Users)、產品資訊(Products)與交易資訊 (Transactions)可以儲存在不同的資料庫中.另外,每個功能區域根據其交易容量(transactional capacity)可以再拆分到多個數據庫中.如圖所示,功能區域可以相互獨立地進行擴充套件.

功能分割槽(Functional Partitioning)

功能分割槽對於實現高可伸縮性相當重要.每一種好的資料庫架構都會根據功能將概要(Schema)分解到多張表中.使用者(Users)、產品 (Products)、交易(Transactions)以及通訊都是功能分割槽的例子. 常用的方法是,利用諸如外來鍵(foreign key)一類的資料庫概念來維持這些功能區域之間的資料一致性.

依賴資料庫的約束保證功能組之間的一致性,會導致資料庫的不同概要(schema)在部署策略上高度耦合.要支援約束,表必須存在單一的資料庫伺服器上,當交易率(transaction rate)增長時也無法對其進行橫向擴充套件.很多情況下, 將資料的不同功能組遷移到相互獨立的資料庫伺服器上是最容易實現的向外擴充套件(Scale-out)方案.

可擴充套件到非常高的交易量的概要會將不同的功能的資料放置在不同的資料庫伺服器上.這需要將資料之間的約束從資料庫遷移到應用中去. 同時這也將引入一些新的挑戰,本文的後續內容會對此進行深入探討.

CAP定理(CAP Theorem)

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

• 一致性(Consistency).客戶端知道一系列的操作都會同時發生(生效).
• 可用性(Availability).每個操作都必須以可預期的響應結束.
• 分割槽容錯性(Partition tolerance).即使出現單個元件無法可用,操作依然可以完成.

具體地講,在任何資料庫設計中,一個Web應用至多隻能同時支援上面的兩個屬性.顯然,任何橫向擴充套件策略都要依賴於資料分割槽;因此,設計人員必須在一致性與可用性之間做出選擇.

ACID解決方案

ACID資料庫事務極大地簡化了應用開發人員的工作.正如其縮寫標識所示,ACID事務提供以下幾種保證:

• 原子性(Atomicity).事務中的所有操作,要麼全部成功,要麼全部不做.
• 一致性(Consistency).在事務開始與結束時,資料庫處於一致狀態.
• 隔離性(Isolation). 事務如同只有這一個操作在被資料庫所執行一樣.
• 永續性(Durability). 在事務結束時,此操作將不可逆轉.(也就是隻要事務提交,系統將保證資料不會丟失,即使出現系統Crash,譯者補充).

資料庫廠商在很久以前就認識到資料庫分割槽的必要性,並引入了一種稱為2PC(兩階段提交)的技術來提供跨越多個數據庫例項的ACID保證.這個協議分為以下兩個階段:

• 第一階段,事務協調器要求每個涉及到事務的資料庫預提交(precommit)此操作,並反映是否可以提交.
• 第二階段,事務協調器要求每個資料庫提交資料.

如果有任何一個數據庫否決此次提交,那麼所有資料庫都會被要求回滾它們在此事務中的那部分資訊.這樣做的缺陷是什麼呢? 我們可以在分割槽之間獲得一致性.如果Brewer的猜測是對的,那麼我們一定會影響到可用性,但,怎麼可以這樣呢?

任何系統的可用性都是執行操作的相關元件的可用性的產物.此陳述的後半段尤其重要.系統中可能會使用但又不是必需的元件,不會降低系統的可用性.在兩階段提交中涉及到兩個資料庫的事務,它的可用性是這兩個資料庫中每一個的可用性的產物.例如,如果我們假設每個資料庫都有為99.9%的可用性,那麼這個事務的可用性就是99.8%,或者說每月43分鐘的額外停機時間.

關於兩階段提交，你可以看看"改變未來的九大演算法"，裡邊有精闢的講解~

一種ACID的替代方案

如果ACID為分割槽的資料庫提供一致性的選擇,那麼你如何實現可用性呢?答案是BASE(基本上可用、軟(弱)狀態、最終一致性).
BASE與ACID截然相反.ACID比較悲觀,在每個操作結束時都強制保持一致性,而BASE比較樂觀,接受資料庫的一致性處於一種動盪不定的狀態.雖然,聽起來很難應付,實際上這相當好管理,並且可帶來ACID無法企及的更高級別的可伸縮性.

BASE的可用性是通過支援區域性故障而不是系統全域性故障來實現的.下面是一個簡單的例子:如果使用者分割槽在5個數據庫伺服器上,BASE設計鼓勵類似的處理方式,這樣一個使用者資料庫的故障只會影響這臺特定主機上的那20%的使用者.這裡不涉及任何魔法,不過,它確實可以帶來更高的可感知的系統可用性.

因此,到目前為止,你已經將資料分解到了多個功能組中,並將最繁忙的功能組分割槽到了多個數據庫中,如何在你的應用中應用BASE原則呢?與ACID 的典型應用場景相比,BASE需要對邏輯事務中的操作進行更加深入的分析.到底該如何進行分析呢?後續的內容將提供部分指導原則.

一致性模式(Consistency Patterns)

沿著Brewer的猜測,如果BASE在分割槽資料庫中選擇保留可用性(Availability), 那麼,弱化一定程度的一致性就成為必然的選擇.這通常難以決策,因為商業投資方與開發人員都傾向於認為一致性(Consistency)對應用的成功至關重要.哪怕是臨時的不一致也瞞不過終端使用者,因此,技術部門與產品部門都需要參與進來,以決定將一致性弱化到什麼程度.

圖-2是一個簡單的概要,它闡釋了BASE中一致性要考慮的事情.使用者表儲存使用者資訊,同時還包含總銷售額與總購買額.這些都是執行時的統計.交易表儲存每一筆交易,將買家、賣家以及交易金額關聯在一起.這些是對實際使用的表進行過度簡化後的結果,不過,它已經包含闡釋一致性的多個方面的必要元素.

圖 2

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

圖 3

使用者表中的總銷售額的列與總購買額的列可以被認為是交易表的一份快取(Cache).它的存在是為了提高系統的效率.有鑑於此,一致性的約束可以被弱化. 可以調整一下買家與賣家的期望設定,從而他們的執行結餘(running balance)不能立即反映交易的結果.這種情況很常見,實際上,人們經常會遇到交易與執行結餘之間的這種延遲(例如,ATM取款或者手機通話).

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

圖 4

現在,我們已經將對使用者表與交易表的更新做了解耦.兩個表之間的一致性將再也無法保證.實際上,在第一個事務與第二個事務處理間隔發生故障,將導致使用者表持久處於不一致的狀態,不過,如果合同約定執行時彙總(running total)是估計值的話,這樣做也足夠了.

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

圖 5

這個例子中的語法有點隨意,為了闡釋概念對其邏輯也做了大量的簡化.通過在插入語句的同一個事務中對持久訊息進行排隊,可以抓取更新使用者執行結餘所需的資訊.這個事務包含在同一個資料庫例項中,因此,它不會影響系統的可用性.

一個獨立的訊息處理元件，會從佇列中取出每條訊息，並將此資訊應用到使用者表.這個例子看似解決了所有的問題,但是，還有一個問題沒有解決.為了避免排隊時發生2PC,訊息是持久化在交易的主機上的.如果在涉及到使用者主機的事務中從佇列中取出訊息,我們仍將遇到2PC的情景.

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

不過,假定你的系統完全無法接受2PC.這個問題該如何解決呢?首先,你需要理解等冪概念.如果一個操作被應用一次或多次都能取得同樣的結果,就被認為是等冪的.等冪操作非常有用,因為它們允許區域性故障,重複執行它們不會改變系統的最終狀態.

從等冪的角度看,所選的這個例子是有問題的.更新操作通常不等冪.這個例子中有累加賬戶列的操作.重複應用此操作顯然會導致錯誤的賬戶餘額.然而, 即使是僅僅設定一個值的更新操作也不是等冪的,因為它還涉及到操作執行的順序.如果系統無法保證更新操作按照接收到的順序被應用,系統的最終狀態也將是不正確的.後面的內容會進一步討論此問題.

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

圖-6中展示的表會記錄交易ID、更新了哪個帳號以及應用此帳號的使用者ID.現在,我們的樣本虛擬碼如圖-7所示.

圖 6

圖 7

這個例子取決於可以窺視佇列中的一條訊息,並在成功處理後立即刪除此訊息.如有必要,可以通過兩個獨立的事務來處理它:訊息佇列上一個事務,使用者資料庫上一個事務.資料庫操作成功提交,才提交佇列操作.目前的演算法可以支援區域性故障,而且又能提供不依賴於2PC的事務保證.

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

圖 8

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

圖 9

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

訊息佇列的順序

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

這裡提供的例子闡釋瞭如何弱化訊息的順序,並在最終仍然能夠提供一個數據庫的一致性檢視.弱化訊息排序所需的開銷是名義上的,在大部分情況下,此開銷要顯著的少於在訊息系統中確保訊息順序的開銷.

進一步講,無論互動風格如何,Web應用在語義上都是一個事件驅動的系統.客戶端請求以任意順序達到系統.每個請求所需的處理時間要求也各不相同. 整個系統的不同元件的請求排程也是不確定的,導致了訊息排隊的不確定.要求保持訊息的順序給出的是一種虛假的安全感.簡單的事實是,不確定的輸入會導致不確定的輸出.

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

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

一個簡單的例子就可以幫助解釋這一點.考慮這樣一個系統,使用者可以在此將資產轉移給另一個使用者.哪種型別的資產都沒有關係,它可以是錢或者遊戲中的裝備.對於這個例子,我們假設,已經通過使用一個用於解耦的訊息佇列,對如下兩個操作進行了解耦:從一個使用者取出資產,將資產給另一個使用者.

很快,系統就會感覺到有問題與不確定性.在資產離開一個使用者到達另一個使用者中間,有一段時間的延時. 這個時間視窗的大小由訊息系統的設計所決定.無論如何,在開始狀態與結束狀態之間,始終會有一個時間間隔,在這段時間內, 看似任何使用者都不享有這筆資產.

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

事件驅動架構(Event-Driven Architecture)

如果你確實需要知道,系統將在何時達到一致的狀態?你可能需要一種演算法,來應用到這個狀態上,不過,僅僅在它達到一個與後續請求相關的一致狀態時才會被應用.

繼續討論前面的例子,如果在資產到達時,需要通知使用者,怎麼辦? 在將資產交付給接收使用者的那個事務內建立一個事件,就可以提供一種機制,當達到一個事先確定的狀態時,可以做進一步的處理.EDA(事件驅動架構,Event-Driven Architecture)可以顯著改善可伸縮性以及架構的解耦.對於EDA應用的進一步討論超出了本文的範疇.

結論

顯著的擴充套件系統的交易率,需要以一種全新的方式來考慮如何對資源進行管理.當負載需要分佈到大量的元件上時,傳統的事務模型會漏洞百出.對操作進行解耦,並依次對它們進行處理,可能提供更好的可用性與伸縮性,不過是以犧牲一致性為代價.BASE提供了一種模型來考慮這種解耦.

參考

Dan Pritchett是Ebay的一位技術人員,他過去4年一直是Ebay架構團隊的成員.在此崗位上,他與Ebay市場部、Paypal以及Skype的戰略、商業、產品與技術團隊進行合作.他已經有20年技術公司的工作經歷,他服務過的公司包含Sun,HP以及矽谷圖形公司(Silicon Graphics),Pritchett具有豐富的技術經歷,從網路層協議與作業系統到系統設計與軟體模式.他擁有密蘇里州Rolla大學的電腦科學學士學位.