一，兩階段提交協議介紹
兩階段提交協議是用來保證分布式系統事務的協議。在分布式系統中，乙個事務需要由多台機器協調完成，機器之間通過網路來通訊，如何保證一組操作在多台機器上要麼都做，要麼都不做呢？（事務的acid特性）
【比如，乙個事務包括三個操作a,b,c，操作a,b,c分別 在機器1，2，3上完成，如果機器1成功提交了操作a，機器2成功提交了操作b，但是機器3執行操作c失敗了，則需要撤消所有的操作……】
再擴充套件一下，把兩階段提交協議用到保證多個資料副本一致性的情景下，可以說：它是一種強一致性的中心化副本控制協議。比如，集群中的每個資料塊都有三個副本，當修改某資料塊時，為了保證一致性，這三個副本都需要修改。
強一致性體現在：當修改操作成功後，讀取該副本時，一定能讀到最新修改的資料。
中心化體現在：兩階段提交協議需要乙個協調者來控制事務的流程。這個協調者可以視為中心控制節點。
副本控制協議：是指兩階段提交協議可用在保證副本一致性 情景中。
二，兩階段提交協議分析
在該協議中，節點分成兩類：協調者和參與者。
兩階段提交協議流程主要分成兩個階段：當client向協調者發起請求後，
階段①：投票階段
協調者詢問所有的參與者是否可以執行提交操作
各個參與者為事務做準備，如分配資源、加鎖……
參與者向協調者傳送響應（可以提交 或者 不能提交）
這裡需要注意的是：當參與者傳送的響應是能提交事務，那它就不能放棄事務。因此，在乙個參與者投票要求提交事務之前，它必須保證最終能夠執行提交協議中它自己的那一部分，即使參與者出現故障，而被中途替換掉。為了保證能夠提交，每個參與者必須將事務中所有發生改變的物件以及它自己的狀態儲存到永續性儲存中。（如果某個參與者可以提交它那部分事務，那麼它將把所有的更新和它的狀態記錄到持久儲存中---也就是準備好提交）
階段②：提交階段
協調者收到所有的參與者返回的「可以提交」響應。向各個參與者傳送「正式提交」命令
參與者各自在本地完成正式提交操作，成功後向協調者返回響應(「提交成功」或者「提交失敗」）
當協調者收到所有的參與都「成功提交」的響應後，本次事務成功提交。否則失敗（可能需要回滾或者重試）
三，兩階段提交協議的特點
①協議是阻塞的
協調者需要等待所有的參與者都返回響應後，才能繼續下一步操作。
②網路容錯能力差
只要有乙個參與者失敗了（網路超時或者宕機），協調者需要一直等待直到超時，本次事務失敗。
③協調者單點故障
在第二階段中，當協調者未發出「正式提交」 就宕機時，參與者將進入「未知」狀態，完全不知道下一步該怎麼辦（重新傳送第一階段中的「可以提交」響應或者超時等待）
四，參考資料
分布式系統的事務處理
如何用訊息系統避免分布式事務？
分布式的兩階段提交
一 二階段提交演算法描述 在分布式系統中，事務往往包含有多個參與者的活動，單個參與者上的活動是能夠保證原子性的，而多個參與者之間原子性的保證則需要通過兩階段提交來實現，兩階段提交是分布式事務實現的關鍵。很明顯，兩階段提交保證了分布式事務的原子性，這些子事務要麼都做，要麼都不做。而資料庫的一致性是由資...
分布式事務 XA事務 兩階段提交
1.分布式事務 在談到 xa 規範之前，必須首先了解分布式事務處理 distributed transaction processing dtp 的概念。transaction 即事務，又稱之為交易，指乙個程式或程式段，在乙個或多個資源如 資料庫 或檔案上為完成某些功能的執行過程的集合。分布式事務處...
分布式事務之XA兩階段提交優缺點
盡量保證類資料的強一致性 無法完全保障 適合對資料強一致要求很高的關鍵領域 執行過程中,所有參與節點都是事務阻塞型的,當參與者找有公共資源時,其他第三方節點訪問公共資源不得不處於阻塞狀態 由於協調者的重要性,一旦協調者發生故障,參與者會一直阻塞下去,尤其在第二階段,協調者發生故障,那麼所有的三語者都...