2pc存在的問題
3pc(three phase commit)
3pc相對於2pc改進點
3pc的問題
2pc與3pc的區別
小結分布式事務的實現有許多種，其中較經典是由 tuxedo 提出的 xa 分布式事務協議，xa 協議包含二階段提交（2pc）和三階段提交（3pc）兩種實現。
xa是x/open dtp定義的中介軟體與資料庫之間的介面規範。 xa介面函式由資料庫廠商提供
x/opendtp 角色
rm resouces manager 資源管理器。 資料庫
tm transaction manager 事務管理器，事務協調者
1. tm向所有的ap傳送事務內容，詢問是否可以執行事務的提交操作，並等待各個ap的響應
2. 執行事務
各個ap節點執行事務操作，將undo和redo資訊記錄到事務日誌中，盡量把提交過程中所消耗時間的操作和準備都提前完成後確保後續
事務提交的成功率
3. 各個ap向tm反饋事務詢問的響應
各個ap成功執行了事務操作，那麼反饋給tm yes的response；如果ap沒有成功執行事務，就反饋tm no的response
提交事務提交
假設乙個事務的提交過程總共需要30s， 其中prepare操作需要28（事務日誌落地磁碟及各種io操作），而真正commit只需要2s
那麼，commit階段發生錯誤的概率和prepare相比， 2/28 (<10%) .只要第乙個階段成功，那麼commit階段出現失敗的概率就非常小,大大增加了分布式事務的成功概率
中斷事務提交
1. 資料一致性問題
在二階段提交的階段二中，當協調者向參與者傳送commit請求之後，發生了區域性網路異常或者在傳送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之後就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。於是整個分布式系統便出現了資料部一致性的現象。
2. 同步阻塞
執行過程中，所有參與節點都是事務阻塞型的。當參與者占有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態
3.二階段無法解決的問題：協調者在發出commit訊息之後宕機，而唯一接收到這條訊息的參與者同時也宕機了。那麼即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交
4.單點故障。由於協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去
docommit：協調者告訴參與者提交它的那部分事務
該階段進行真正的事務提交，也可以分為以下兩種情況。
在docommit階段，如果參與者無法及時接收到來自協調者的docommit或者rebort請求時，會在等待超時之後，會繼續進行事務的提交。（其實這個應該是基於概率來決定的，當進入第三階段時，說明參與者在第二階段已經收到了precommit請求，那麼協調者產生precommit請求的前提條件是他在第二階段開始之前，收到所有參與者的cancommit響應都是yes。（一旦參與者收到了precommit，意味他知道大家其實都同意修改了）所以，一句話概括就是，當進入第三階段時，由於網路超時等原因，雖然參與者沒有收到commit或者abort響應，但是他有理由相信：成功提交的機率很大。 ）
a) 增加了超時機制
b) 第二階段，如果協調者超時沒有接受到參與者的反饋，則自動認為失敗，傳送abort命令
c) 第三階段，如果參與者超時沒有接受到協調者的反饋，則自動認為成功開始提交事務（基於概率）
事務 分布式事務解決方案
事務acid特性 事務隔離級別 指的是讀和寫同時出現時出現的資料不一致問題。事務的一致性問題 存在問題問題描述 髒讀 dirty read 針對的是單條資料。即乙個更新操作a修改了某一條資料，但尚未提交該事務，此時另乙個讀操作b來查詢該條資料，讀到的是修改後的但尚未提交的資料。不可重複讀 unrep...
分布式事務解決方案
一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性，分為三個階段tryi...
分布式事務解決方案
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...