[TOC] # 簡介 為了解決兩階段提交協議,提出一個改進版本,三階段提交協議(3PC). 將協調者和數據庫都引入超時機制,以解決在協調者失效的時候,數據庫會一直占有資源無法釋懷的問題,同時又將準備階段拆分成了詢問和準備兩個階段增加容錯概率 # 詢問節點 事務協調者給每個數據庫發送CanCommit請求,每個數據庫如果可以提交就返回YES消息,否則就返回NO消息 大致流程如下: 1. 事務協調者節點向所有數據庫發起CanCommit請求,并開始等待各參與者節點的響應 2. 數據庫節點收到CanCommit請求之后如果可以提交,則返回YES消息并進入準備階段.否則返回NO消息 # 準備階段 事務協調者收到反饋后會有兩種情況發生: 1. 數據庫返回消息均為yes消息,則執行事務預執行.大致流程如下: 1. 事務協調者節點向所有數據庫發起PreCommit請求,并開始等待各參與者節點的響應 2. 數據庫節點執行到詢問發起為止的所有事務操作,并將undo信息和redo信息寫入日志.執行成功后返回ACK應答,并進入等待 2. 數據庫返回的消息含有NO消息或者等待超時,則執行事務中斷.大致流程是這樣: 1. 事務協調者節點向所有數據庫發起abort中斷請求 2. 數據庫節點收到abort請求之后執行事務中斷.如果超時之后還沒收到事務協調者的任何消息,也執行事務中斷動作 # 提交階段 事務協調者收到反饋后會有兩種情況發生: 1. 協調者收到所有ACK應答,則執行事務提交.大致流程如下: 1. 事務協調者節點向所有數據庫發起DoCommit請求,并開始等待各參與節點的響應 2. 數據庫節點執行commit動作并釋放事務占用的資源,之后向事務協調者發送ACK消息應答 3. 事務協調者收到所有數據庫的反饋消息后完成事務 2. 協調者沒有收到所有ACK應答,則執行事務中斷.大致流程如下: 1. 事務協調者節點向所有數據庫發起abort中斷請求 2. 數據庫節點收到abort請求之后執行事務回滾,并向事務協調者發送ACK消息應答 3. 事務協調者收到所有數據庫的反饋消息后完成事務中斷 # 問題 從三階段提交的流程來看,已經解決了兩階段的一些問題,但是還是會出現數據不一致問題. 因為當進入第三階段也就是提交階段的時候,如果數據庫在超時前沒有收到DoCommit或abort消息,那么它最終會執行commit操作 試想一下,如果在提交階段事務協調者沒有收到所有ACK應答,那么它會發送abort中斷事務的請求.碰巧這時候網絡發生了抖動導致一部分數據庫沒有收到abort消息,那么收到消息的數據庫會執行事務中斷,而沒有收到abort消息的數據庫最終執行為commit動作,這就導致數據不一致了