分散式專題（六）分散式事物
資料庫事務要滿足幾個要求：ACID
Atomic(原子性) 事務必須是原子的工作單元
Consistent(一致性) 事務完成時，必須使所有資料都保持一致狀態
Isolation(隔離性) 併發事務所做的修改必須和其他事務所做的修改是隔離的
Duration（永續性） 事務完成之後，對系統的影響是永久性的
Mysql裡的事務處理過程
- 記錄redo和undo log檔案，確保日誌在磁碟上的持久化
- 更新資料記錄
- 提交事務 ，redo 寫入commit記錄
分散式事務
資料庫分庫分表
SOA化
X/OpenDTP事務模型
X/Open Distributed Transaction Processing Reference Model
X/Open是一個組織機構，定義出的一套分散式事務標準， 定義了規範的API介面
2PC（two -phase-commit）, 用來保證分散式事務的完整性
J2EE 遵循了X/open DTP規範，設計並實現了java裡面的分散式事務程式設計介面規範-JTA
XA是X/Open DTP定義的中介軟體與資料庫之間的介面規範。 XA介面函式由資料庫廠商提供
X/OpenDTP 角色
AP application
RM resouces manager 資源管理器。 資料庫
TM transaction manager 事務管理器，事務協調者
2PC（two -phase-commit）
(CAP)
階段一：提交事務請求（投票）
- TM向所有的AP傳送事務內容，詢問是否可以執行事務的提交操作，並等待各個AP的響應
- 執行事務
各個AP節點執行事務操作，將undo和redo資訊記錄到事務日誌中，儘量把提交過程中所消耗時間的操作和準備都提前完成後確保後續
事務提交的成功率
- 各個AP向TM反饋事務詢問的響應
各個AP成功執行了事務操作，那麼反饋給TM yes的response；如果AP沒有成功執行事務，就反饋TM no的response
階段二：執行事務提交
執行提交事務
假設一個事務的提交過程總共需要30s， 其中prepare操作需要28（事務日誌落地磁碟及各種io操作），而真正commit只需要2s
那麼，commit階段發生錯誤的概率和prepare相比， 2/28 (<10%) .只要第一個階段成功，那麼commit階段出現失敗的概率就非常小
大大增加了分散式事務的成功概率
中斷事務提交
2pc存在的問題
- 資料一致性問題
- 同步阻塞
還有3PC，略
分散式事務的實現
Atomikos