ACID 原則與多階段提交

ACID 原則

ACID,即 Atomicity(原子性)、Consistency(一致性)、Isolation(隔離性)、Durability(持久性)四種特性的縮寫。

ACID 也是一種比較出名的描述一致性的原則,通常出現在分佈式數據庫等基於事務過程的系統中。

具體來說,ACID 原則描述了分佈式數據庫需要滿足的一致性需求,同時允許付出可用性的代價。

  • Atomicity:每次事務是原子的,事務包含的所有操作要麼全部成功,要麼全部不執行。一旦有操作失敗,則需要回退狀態到執行事務之前;

  • Consistency:數據庫的狀態在事務執行前後的狀態是一致的和完整的,無中間狀態。即只能處於成功事務提交後的狀態;

  • Isolation:各種事務可以併發執行,但彼此之間互相不影響。按照標準 SQL 規範,從弱到強可以分為未授權讀取、授權讀取、可重複讀取和串行化四種隔離等級;

  • Durability:狀態的改變是持久的,不會失效。一旦某個事務提交,則它造成的狀態變更就是永久性的。

與 ACID 相對的一個原則是 eBay 技術專家 Dan Pritchett 提出的 BASE(Basic Availability,Soft-state,Eventual Consistency)原則。BASE 原則面向大型高可用分佈式系統,主張犧牲掉對強一致性的追求,而實現最終一致性,來換取一定的可用性。

注:ACID 和 BASE 在英文中分別是“酸”和“鹼”,看似對立,實則是對 CAP 三特性的不同取捨。

兩階段提交

對於分佈式事務一致性的研究成果包括著名的兩階段提交算法(Two-phase Commit,2PC)和三階段提交算法(Three-phase Commit,3PC)。

兩階段提交算法最早由 Jim Gray 於 1979 年在論文《Notes on Database Operating Systems》中提出。其基本思想十分簡單,既然在分佈式場景下,直接提交事務可能出現各種故障和衝突,那麼可將其分解為預提交和正式提交兩個階段,規避衝突的風險。

  • 預提交:協調者(Coordinator)發起提交某個事務的申請,各參與執行者(Participant)需要嘗試進行提交併反饋是否能完成;

  • 正式提交:協調者如果得到所有執行者的成功答覆,則發出正式提交請求。如果成功完成,則算法執行成功。

在此過程中任何步驟出現問題(例如預提交階段有執行者回復預計無法完成提交),則需要回退。

兩階段提交算法因為其簡單容易實現的優點,在關係型數據庫等系統中被廣泛應用。當然,其缺點也很明顯。整個過程需要同步阻塞導致性能一般較差;同時存在單點問題,較壞情況下可能一直無法完成提交;另外可能產生數據不一致的情況(例如協調者和執行者在第二個階段出現故障)。

三階段提交

三階段提交針對兩階段提交算法第一階段中可能阻塞部分執行者的情況進行了優化。具體來說,將預提交階段進一步拆成兩個步驟:嘗試預提交和預提交。

完整過程如下:

  • 嘗試預提交:協調者詢問執行者是否能進行某個事務的提交。執行者需要返回答覆,但無需執行提交。這就避免出現部分執行者被無效阻塞住的情況。

  • 預提交:協調者檢查收集到的答覆,如果全部為真,則發起提交事務請求。各參與執行者(Participant)需要嘗試進行提交併反饋是否能完成;

  • 正式提交:協調者如果得到所有執行者的成功答覆,則發出正式提交請求。如果成功完成,則算法執行成功。

其實,無論兩階段還是三階段提交,都只是一定程度上緩解了提交衝突的問題,並無法一定保證系統的一致性。首個有效的算法是後來提出的 Paxos 算法。

Last updated