分散式系列七: 分散式事務理論

罪惡斯巴克發表於2019-04-03

分散式系列七: 分散式事務理論

事務是將一組操作作為一個整體執行, 這組操作要麼成功,要麼失敗, 不存在部分成功的情況, 分散式事務是為了解決在分散式環境下各節點之間的資料一致性問題.

資料庫本地事務

事務四大特性:

  • 原子性(Atomicity): 事務的一組操作要麼全部執行成功, 要麼其中有失敗後回退到初始狀態. 不存在部分執行部分失敗的狀態. 回退是通過事務的回滾機制(Rollback)完成.

  • 一致性(Consistency): 事務執行前後的資料必須一致. 舉例來說就是, 下單過程中庫存和扣款二者必須對應.

  • 隔離性(Isolation): 事務之間的執行是隔離的, 不能相互影響. 操作相同的資料時, 每個事務都有各自的完整資料空間. 不能讀取到事務執行中間狀態的資料.

  • 永續性(Durability): 事務執行結束後, 它對資料庫的更新將是永久的. 不管系統崩潰斷電,資料的狀態不會發生變化.

MySql的InnDB引擎支援事務, MySql的事務是通過Redo,Undo日誌以及鎖機制來完成. 分開來說, 事務的隔離性通過鎖來實現, 永續性通過Redo來實現, 原子性和一致性通過Undo來實現.

分散式事務產生原因

在分散式環境下, 資料庫(Resource)和應用(Service)均可能被拆分為多個節點, 而操作可能需要在多個節點間一致地完成.

分散式事務相關的理論

  • CAP理論: Consistency, Availability, Partition tolerance; 當錯誤發生時, 三者不能同時滿足, 而分割槽容錯是必須滿足的條件, 於是只能在CP和AP之間選擇. 這也是現在分散式框架的特性, 比如Eureka滿足AP, zookeeper滿足CP.

  • BASE理論: Basically Available: 出現故障時, 允許損失部分功能, 保證核心功能可用; Soft States: 允許出現中間狀態, 這個狀態不影響系統可用性; Eventually consistent: 最終經過一小段時間後, 所有節點的資料達到一致. BASE放棄了事務執行中間的強一致性, 允許中間一小段時間出現中間狀態, 但最終需要達成一致.

柔性事務(遵循BASE): 最終一致性, TCC事務, 補償機制.

X/Open DTP 模型

三個角色:

  • AP: application
  • RM: Resource Manager 一般是資料庫, 需要始興縣XA定義的介面.
  • TM: Transaction Manager

2pc & 3pc

  • 2pc: two phase commit precommit -> docommit

缺點: (1)單點故障, 事務管理器當機可能導致阻塞, 二階段事務無法提交; 資源管理器當機,導致沒有接收到commit,導致阻塞(2)同步阻塞;(3)資料不一致

  • 3pc: three phase commit cancommit -> precommit -> docommit

解決了2pc中的阻塞問題, 因為引入了超時機制.

XA 和 JTA

XA是X/Open定義的規範, JTA是java事務規範的實現.

網際網路分散式事務解決方案

網際網路對資料的絕對一致性要求沒有傳統行業高

  1. 避免分散式事務;
  2. 最終一致性解決方案;(基於BASE),
    使用MQ解決:
    訊息丟失使用持久化解決;
    重複消費問題(冪等性)問題使用狀態鎖或者冪等校驗解決).
    模式:
    1. 查詢模式, 提供一個介面返回是否成功的狀態; 衰減查詢
    2. 補償模式: (1)自動恢復,就是自動重試或回滾; (2)通知運營, 人工干預;(3)通知技術,監控預警(資料恢復)
    3. TCC事務(DTS事務架構--淘寶) 框架: tcc-transaction;butetcc
    trying: 凍結賬戶餘額, 商戶不動
    commit: 扣減賬戶餘額, 商戶賬戶增加
    cancel: 解除凍結
  3. 最大努力通知: 重複通知, 直到處理

相關文章