事務 - BASE模式

事務 - BASE模式

github

ACID的侷限

在本地事務這篇文章裏咱們講到了數據庫事務必須保證ACID，在2PC這篇文章裏，咱們探討了跨數據庫事務是如何保證ACID的。

當數據量愈來愈大的時候，咱們會對將大數據庫拆分紅若干小庫，隨着數據庫數量愈來愈多，2PC（及XA）就顯得有些捉襟見肘了：

1. 性能低下，2PC協議是阻塞式的。當協調的數據庫愈來愈多時，性能沒法接受。
2. 沒法水平擴展以提高性能，只能靠垂直擴展（提高硬件）——更快的CPU、更快更大的硬盤、更大更快的內存——可是這樣很貴，而且很容易遇到極限。

CAP理論

CAP理論是Eric Brewer教授針對分佈式數據庫所提出的一套理論，他認爲在實現分佈式數據庫，須要考慮3個需求：

• Consistency：當寫發生時，每一個節點的數據必須都被更新到。當查詢發生時，若是還未所有更新到則返回error或timeout；若是所有更新到了，則直接返回結果。
• Availability：當查詢發生時，不用考慮上一次寫是否更新到了每一個節點，直接提供當下的數據做爲結果。
• Partition-tolerance：除非全部節點都掛，它都應該能繼續提供服務。

CAP理論指出，當每一個節點都工做正常的時候，C、A、P是能夠都知足的，當出現節點故障時，咱們只能3選2。

若是咱們不想由於數據庫的某個節點出現故障就讓數據庫中止服務，那麼咱們一定選擇P，那麼咱們就只能在C和A之間作選擇。若是選擇C：後續的讀都將失敗。若是選擇A：會讀到不一致的結果。

BASE模式

Basically Available, Soft state, Eventually consistent，簡稱BASE。

BASE和ACID相反，ACID是悲觀的，它要求全部操做都必須保證一致性，而BASE是樂觀的，它接受數據庫的一致性在不斷變化當中。同時，BASE對於CAP中的C作出了必定的妥協——接受臨時的不一致，採用最終一致性。最終一致性，聽上去怪怪的，一些開發人員以爲這是個壞東西。不過咱們真的要時時刻刻保證一致性嗎？BASE認爲咱們能夠作一些妥協，所以若是咱們按照BASE設計系統的話就可以保證：

1. ACID - A，不保證，一旦開始「寫」則不可能回滾。
2. ACID - C，保證最終一致性。
3. ACID - I，不保證，是由於一個大事務是由多個小事務組成，每一個小事務都會獨立提交。
4. ACID - D，保證，由於數據庫保證D。
5. CAP - C，保證最終一致性。
6. CAP - A，保證基本可用。
7. CAP - P，保證。

舉個例子，如今咱們有3條insert要執行（至因而否是3個不一樣的表、數據庫不重要），那麼只要保證下面幾點就可以知足BASE：

1. 最終都可以執行成功
2. 任何一條語句執行失敗都會重試
3. 任意一條語句重複執行結果都同樣——冪等

正確地使用BASE模式也不是那麼容易，好比消費業務，咱們要保證「檢查餘額」和「扣款、記錄消費日誌」這兩組動做不會產生交叉，不然就會由於高併發場景而發生透支，在這個例子裏咱們能夠對「扣款、記錄消費日誌」作最終一致性，可是如何保證下達「扣款、記錄消費日誌」這兩個指令確定不會產生透支的狀況則不是BASE解決的問題了。

因此總結一下BASE的特色就是：

1. 解決的是提交的問題
2. 2PC將提交動做放在數據庫，而BASE將提交動做放在應用程序

關於BASE能夠詳見這篇文章BASE: An Acid Alternative。

參考資料

• Wiki - CAP Theorem
• Wiki - Eventual Consistency
• Article - BASE: An Acid Alternative
• Article - Better Explaining CAP Theorem