【正文】 假定提交協(xié)議中，可以不將 Prepare寫入 Log，減少了 Log寫入的次數(shù) 兩階段提交協(xié)議的演變 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 ? 事務阻斷：某個 Site上本來可以終結（提交或撤銷）的子事務，由于 DDBS故障，必須 等待到故障恢復（ 其占有的資源不釋放） ? 阻斷協(xié)議：提交協(xié)議稱為阻斷協(xié)議是指發(fā)生某類故障時， 使分布式事務可能處于阻斷狀態(tài) ? 終結協(xié)議： 允許事務在有故障情況下仍能正確結束 事務阻斷與終結協(xié)議 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 ? 判斷 2PC協(xié)議是終結協(xié)議的條件 – 至少有一個 Site已收到結果命令（該 Site可以告知其它參與者關于該事務的結果，并由它們來終結該事務） – 沒有一個參與者收到命令，并且只有協(xié)調者Site故障（此時，所有參與者站點都是可工作的，參與者可以選舉一個 新的協(xié)調者， 然后繼續(xù)） 事務阻斷與終結協(xié)議 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 ? 終結協(xié)議在協(xié)調者和參與者的定時器超時時發(fā)揮作用 ? 超時處理技術 – 協(xié)調者超時 ? 在等待狀態(tài)超時，可以決定“全局撤銷” ? 在撤銷狀態(tài)超時，重發(fā)“ Gabort” ? 在提交狀態(tài)超時，重發(fā)“ Gmit” – 參與者超時（被阻斷時出現(xiàn)） ? 在初始狀態(tài)超時，單方面 Abort ? 在 Ready狀態(tài)超時，被阻斷，等待事務最終處理結果 2PC協(xié)議的終結協(xié)議 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 協(xié)調者超時 I W C A F mit申請 申請 prepare* ack* ack* _t_ abort any abort any mit _t_ mit _t_ abort* no abort* prepared* mit* t=timeout 參與者超時 I R C A 申請 prepare prepared 等價于結束狀態(tài) _t_ ping 申請 prepare no mit ack abort ack mit ack abort ack ? 設計終結協(xié)議 –假定 Pi是超時的參與者（詢問 Pj），其它Pj按如下響應 ? Pj處于初始狀態(tài)，于是單方面 Abort，并回送“建議 abort”給 Pi ? Pj處于 Ready狀態(tài)，此時不能幫助 Pi終結 ? Pj處于 Commit或 Abort狀態(tài)，此時向 Pi發(fā)送“建議提交”或“建議 Abort” 2PC協(xié)議的終結協(xié)議 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 – Pi超時，可能有的解釋 ? Pi收到 Pj的“建議撤銷”回答，此時 Pi夭折 ? Pi收到 Pj“建議撤銷”回答，但是其它 Pj處于 Ready狀態(tài)，此時 Pi仍然 Abort ? Pi收到 Pj處于 Ready狀態(tài)，此時沒有一個參與者有足夠的信息恰當?shù)亟K結事務 ? Pi收到其他所有的 Pj”全局提交”或”全局夭折”消息， Pi可以根據(jù)消息終結 ? Pi收到某些 Pj的“全局提交”，而另一些Pj處于 Ready狀態(tài)， Pi可以提交 2PC協(xié)議的終結協(xié)議 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 ? 協(xié)調者站點失效 – 協(xié)調者在初始狀態(tài)失效 ? 發(fā)生在協(xié)調者初始化提交過程之前 ? 因此，它將在恢復時啟動提交過程 – 協(xié)調者在等待狀態(tài)失效 ? 這時協(xié)調者已經(jīng)發(fā)送了“準備”命令 ? 恢復時，協(xié)調者將從頭開始啟動提交過程，再次發(fā)送“準備”消息 – 協(xié)調者在提交狀態(tài)或撤銷狀態(tài)失效 ? 這時，協(xié)調者已經(jīng)把它的決定通知了參與者，并終結了事務 ? 在恢復時，如果它已經(jīng)收到了所有的確認消息，就不需要做任何事情 ? 否則，就要啟動終結協(xié)議 2PC協(xié)議的恢復協(xié)議 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 ? 參與者站點失效 – 一個參與者在初始狀態(tài)失效 ? 在恢復時，該參與者應該單方面撤銷事務 – 一個參與者在就緒狀態(tài)失效 ? 這時協(xié)調者已經(jīng)收到失效站點在失效前發(fā)送的肯定決定 ? 恢復時，失效站點的參與者認為是在就緒狀態(tài)發(fā)生了超時，于是啟動終結協(xié)議來處理該事務 – 一個參與者在提交狀態(tài)或撤銷狀態(tài)失效 ? 這些狀態(tài)表示了終結條件，所以在恢復時，參與者不需要采取任何專門的措施 ? 附加情形（略） 2PC協(xié)議的恢復協(xié)議 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 ? 提交協(xié)議 是非阻斷的充要條件 是 , 在其狀態(tài)轉換圖中不存在 : – 沒有狀態(tài)是即與提交又與撤銷狀態(tài)“相鄰” – 不存在不可提交狀態(tài)是與提交狀態(tài)“相鄰” ? 相鄰 – 從一個狀態(tài)直接轉換到另一個狀態(tài) 三階段提交協(xié)議 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 ? 2PC中的狀態(tài) – C(提交 )狀態(tài)是可提交狀態(tài) , 其它為不可提交狀態(tài) ? Ready 狀態(tài)是不可提交狀態(tài) ? Wait狀態(tài)是不可提交狀態(tài) – 它們都侵犯了非阻斷協(xié)議的充要條件 , 從而考慮改變 2PC, 使其滿足非阻斷協(xié)議條件 ? 在 Wait 和 Commit 之間 , 或者在 Ready和Commit之間加入另一種狀態(tài)作為緩沖狀態(tài) , 從而有了 3PC協(xié)議 三階段提交協(xié)議 3 分布式數(shù)據(jù)庫的可靠性協(xié)議 I W A C mit prepare voteabort globalabort votemit preparetomit I R A C prepare votemit globalabort ACK preparetomit readytomit prepare voteabort 3PC中事務的狀態(tài)轉換圖 PC PC readytomit globalmit globalmit ACK (a) 協(xié)調者 (b) 參與者 協(xié)調者 參與者 PREPARE PREPARED COMMIT DONE PRECOMMIT ACK 協(xié)調者 參與者 PREPARE NO ABORT DONE 協(xié)調者 參與者 開始 3PC 記錄寫 Log (參與者列表 ) mit記錄寫 Log (狀態(tài) C) prepared記錄寫 Log (狀態(tài) W) mitted 記錄寫 Log (狀態(tài) C) PREPARE PREPARED COMMIT PRECOMMIT ACK 協(xié)調者 參與者 初始 寫 begin_mit到日志 等待 有要求撤消的？ 寫 Prepareto mit到日志 準備 提交 寫 初始 準備提交？ 寫 ready到日志 就緒 消息類型？ 寫 abort到日志 寫 prepareto mit到日志 準備 提交 撤消 撤消 寫 abort到日志 寫 abort到日志 準備 撤消 提交 全局撤消 準備提交 ACK ACK no no abort Prepare to mit 寫 mit到日志 提交 提交 在 中事務執(zhí)行的過程 寫 mit到日志 撤消 提交 準備提交 3PC ? 協(xié)調者 – 在 Wait狀態(tài)超時：與 2PC中協(xié)調者在 Wait超時相同 , 協(xié)調者單方面 Abort – 在 PC狀態(tài)超時：此時協(xié)調者不知道未響應的參與者是否到達 PC. 但是知道每個參與者至少在Ready狀態(tài) , 因此協(xié)調者可以將所有參與者移入PC狀態(tài) – 在 Commit/Abort狀態(tài)超時 協(xié)調者不知參與者是否已執(zhí)行命令 ,但是對 Commit而言 , 知道參與者至少在 PC狀態(tài)。每個站點獨立于其它站點記錄其本地檢查點 , 所以建立一致全局狀態(tài)由冷啟動過程實現(xiàn) – 改進 2PC, 使屬于兩個分布事務 T和 T’的所有子事務的檢查點