466      阿裏雲  技術社區[雲棲]

《解讀NoSQL》——2.5　比較ACID和BASE——兩種可靠的數據庫事務方法

本節書摘來自異步社區出版社《解讀NoSQL》一書中的第2章，第2.5節，作者： 【美】Dan McCreary（丹•麥克雷） , Ann Kelly（安•凱利），更多章節內容可以訪問雲棲社區“異步社區”公眾號查看。

2.5　比較ACID和BASE——兩種可靠的數據庫事務方法

兼顧性能和一致性的事務控製在分布式計算環境下是很重要的。通常會在兩種事務控製模型中選擇其一使用：ACID用於RDBMS，BASE用在很多NoSQL係統。即使數據庫事務隻有很少一部分需要事務完整性，但了解RDBMS和NoSQL係統能夠采用這些事務控製策略也是很重要的。這兩種模型的區別在於應用開發人員所付出的努力和事務控製所發生的位置（層級）。

讓我們從一個簡單的銀行業務案例來展現一個可靠的事務。如今，許多人都有兩個銀行賬戶：儲蓄賬戶和支票賬戶。如果你想將一些資金從一個賬戶轉賬到另一個賬戶，銀行在網站上會有轉賬頁麵，進行如圖2-7所示的一個資金轉賬流程。

圖2-7　這一係列原子步驟將資金從一個賬戶轉賬到另一個賬戶。第一步從儲蓄賬戶扣除所要轉賬的金額。第二步將相等的轉賬金額增加到支票賬戶。由於事務應該是可靠的，所以所有步驟要麼都執行要麼都不執行。在事務步驟之間，任何顯示賬戶總額由於交易金額而減少的報表都不應該被允許運行

當點擊了網頁上的轉賬按鈕，兩個獨立的操作必須共同執行。首先從儲蓄賬戶中扣除轉賬金額，然後再加到支票賬戶中。事務管理是確保這兩個操作作為一個整體一起發生或者一起不發生的過程。如果計算機在第一個步驟完成後而第二個步驟還沒開始時崩潰了，你要損失1 000美元，你當然會對銀行產生極大不滿。

傳統的商業數據庫都以在金融事務方麵的穩定和可靠而聞名。這不僅因為它們已經存在了相當長的時間，且一直不斷地進行著優化，還因為它使得程序員通過在事務開始和結束的地方進行聲明就可以很容易地保障關鍵事務的可靠性。這些聲明被稱作啟動事務（OPEN TRANSACTION）和結束事務（END TRANSACTION）。通過添加它們，開發者能夠獲得高可靠的事務支持。如果兩個原子操作中的一個沒有完成，那麼所有操作都會被回滾至它們最初的狀態。

係統同樣確保了不會有任何賬戶報表在操作進行到一半時生成。如果你在事務過程中執行生成賬戶餘額報表，它將不會顯示先有1 000數額的減少然後再增加1 000。如果報表在事務的第一個步驟進行時開始生成，它將會被阻塞，直到整個事務完成。

在傳統的RDBMS中，事務管理的複雜性由數據庫層負責解決。應用開發者隻需要處理在整個事務失敗時，如何通知正確的組件或者不停重試直到事務完成。應用開發者並不需要知道如何撤銷一個事務的各種部分，因為這已經成為了數據庫內建的一部分。

由於可靠的事務對於大多數應用係統是很重要的，接下來的兩小節將深入研究RDBMS的事務控製——ACID和NoSQL係統的事務控製——BASE。

2.5.1　RDBMS的事務控製——ACID

RDBMS的事務控製通過原子性、一致性、隔離性和持久性（ACID）屬性來保證事務是可靠的。接下來將對每一個屬性進行定義。

原子性——在銀行交易的例子中，我們提到過從儲蓄賬戶到支票賬戶的現金轉移的過程要麼一起發生要麼都不發生。如果用技術術語來形容就是原子性，它來自於希臘語的“不可分”。如果係統聲明支持原子性事務，那麼它必須考慮所有失敗的情況：磁盤故障、網絡故障、硬件故障或者單純的程序錯誤。即使是在單個CPU之上測試原子性事務也是很困難的。

一致性——在銀行交易的例子中，我們在兩個相關賬戶之間進行資金轉移，而總賬戶餘額從未改變，這是一致性的原則。那意味著數據庫不能在支票賬戶餘額增加之前顯示儲蓄賬戶餘額減少。數據庫負責在原子操作持續的時間內阻塞所有報表。當數據庫基於同樣的記錄同時運行很多原子性事務和報表時，會影響係統的速度。

隔離性——隔離性指的是其他事務對該事務的每一部分的執行都不知情。例如，增加金額的事務並不知道從賬戶扣除金額的事務。

持久性——持久性指的是這樣一個事實，一旦事務的所有方麵完成，它將是永久性的。一旦轉賬的按鈕被選中，你將可以消費你的支票賬戶中的資金。如果銀行係統在那天晚上崩潰了，他們需要用備份磁帶恢複數據庫，那麼必須用某些方法確保轉賬記錄也被恢複。這通常意味著銀行必須在一個獨立的計算機係統中保留一份事務日誌，當備份恢複完成後，根據事務日誌重新執行一遍所有事務。

如果你認為處理這些規則的軟件一定很複雜，那麼你是正確的。確實非常複雜，這也是關係型數據庫非常昂貴的原因之一。如果你自己正在編寫一個數據庫，那麼有些必需的軟件模塊的數量很容易增至2倍或是3倍。這也是新數據庫產品經常在第一個發布版中不支持數據庫級別的事務管理的原因，而是在產品成熟後才會加入。

許多RDBMS將事務發生的範圍限製在單個CPU之內。如果考慮這種情況：你的儲蓄賬戶的信息存儲在紐約的一台計算機裏，你的支票賬戶信息存儲在舊金山的一台計算機裏，那麼複雜程度將會增加，因為這種情況有更多的失效點並且需要阻塞的基於這兩個係統的報表係統的數量也會增加。

盡管支持ACID的事務很複雜，但還是有一些著名的、公認的策略來實現。它們都是基於鎖定資源，並預留出額外副本的資源，然後執行事務，如果一切都沒問題，再釋放資源。如果事務的任何一部分出錯，有爭議的資源必須回到它的初始狀態。設計上的挑戰在於搭建支持這些事務的係統，使得應用可以個更容易地使用事務並且保證數據庫的運行速度和響應能力。

ACID係統關注數據的一致性和完整性，且高於其他考量。暫時阻塞報表的機製是為了確保係統返回可靠準確的信息的一種合理的妥協。ACID係統可以說是悲觀的，因為它們必須考慮計算環境裏所有可能的失效模式。有時ACID係統似乎服從墨菲定律——會出錯的事總會出錯——並且必須仔細測試保證事務完整性。

ACID係統高度關注數據完整性，NoSQL卻是基於BASE準則考慮一係列稍有不同的約束。如果在等待另一個事務完成前阻塞事務對你來說是不可接受的妥協，會怎麼樣？如果你有一個接受客戶訂單的網站，有時ACID係統不一定是你想要的。

2.5.2　非RDBMS的事務控製——BASE

假如你的網站是運行在遍布世界各地的計算機上，會怎樣？芝加哥的計算機負責管理庫存，而負責保存產品照片的圖像數據庫在弗吉尼亞，計算稅收的程序在西雅圖運行，賬戶係統在亞特蘭大。如果一旦其中一個站點宕機會怎麼樣？你是否應該告訴客戶等你在20分鍾內解決問題後再回來？除非你是想將客戶拱手相讓給競爭對手。使用ACID係統處理到達的每一個訂單現實嗎？讓我們看看另一種選擇。

使用“購物車”和“結賬台”概念的網站對於事務處理有不同的側重。在幾分鍾內報表不一致與無法下訂單相比是不那麼重要的，因為如果阻塞一個訂單，就損失了一個客戶。這種情況下，可以使用BASE來替代ACID。下麵是BASE的一些概念。

基本可用是指允許係統暫時不一致，這樣事務就容易管理。在BASE係統中，信息和服務能力是“基本可用的”。

軟狀態是指為了降低消耗的資源，可以暫時允許一些不準確的地方和數據的變換。

最終一致性意味著在最後，當所有服務邏輯執行完成後，係統最後將回到一個一致的狀態。
與RDBMS關注一致性不同，BASE係統關注可用性。BASE係統顯著的特點是它們的首要目標是要保證在短時間內，即使有不同步的風險，也要允許新數據能夠被存儲。NoSQL係統放寬了規則並允許即使不是所有數據庫都是同步的，也能運行報表。BASE係統不被認為是悲觀的，因為它們並不會關心某個過程背後的細節。它們是樂觀的，因為它們假設最後所有係統都會同步而變得一致。

BASE係統傾向於更加簡單和迅速，因為它們不必編寫處理鎖定和釋放資源的代碼。它們的任務是保證流程運轉並稍後處理出錯的部分。BASE係統非常適合支持網上商店，填滿購物車和下訂單才是它們的主要優先功能。

在NoSQL運動之前，大多數數據庫專家認為ACID係統是唯一能夠商用的事務類型。NoSQL係統是高度去中心化的，並且ACID提供的保障有時不是必須的，所以NoSQL采用了BASE和一些更為寬鬆的方法。圖2-8顯示了一個準確的、有點幽默的ACID和BASE哲學之間的對比。

圖2-8　ACID與BASE——了解其中的利弊。該圖比較了應用於嚴格的金融賬戶規則的傳統RDBMS的ACID事務與NoSQL係統更加寬鬆的BASE方法。當要求所有報表必須始終保持一致性和可信性，RDBMS ACID係統是理想的選擇。當把永遠不阻塞寫事務作為高優先級任務時，NoSQLBASE係統是合適的選擇。業務需求將決定是傳統的RDBMS還是NoSQL係統適合你的應用

最後還要提醒讀者：ACID和BASE並沒有一個嚴格界限，它們取決與組織和係統決定在哪裏和如何架構這個係統的場景。它們可能允許在某些關鍵領域采取嚴格的ACID事務，其他領域標準稍微放鬆一些。一些數據庫係統通過改變配置文件或者使用不同的API提供了雙重選擇。係統管理員和應用開發者可以一起在考慮了業務的需要之後，實現正確的選項。

當你為了處理海量數據而進行擴展並將係統架構從集中式遷移到分布式係統時，事務是重要的。但是有時你管理的數據超過了當前係統能夠管理的規模，那就需要采取數據庫分片來保證新係統運行並減少宕機時間。

最後更新：2017-06-08 12:01:58

  上一篇：  數夢工場完成A輪7.5億融資 三個維度構建“新型互聯網”

  下一篇：  網卡，進程綁定cpu