1樓：
@旬飛 已經回答很好了，我在這裡補充一下。
Two-phase Commit,第二階段有叫做完成階段，因為無論結果怎樣，協調者都必須在此階段結束
當前事務。根據描述協調者狀態處於（準備好--回滾--完成）回滾--完成這個狀態。
恢復後，參與者根據協調者狀態做調整。如果已經回滾，不需要操作，如果未執行，需要回滾。
如果新協調者啟動後，雖然參與者沒有記錄，可以再次查詢。
三階段提交；我正在看後面回覆。
3PC未徹底解決該問題，通過方式根據前面2階段結果，自行執行。
如果在網路分割槽情況下。有問題
2樓：海綿寶寶
首先我覺得你的問題問的很棒，問的很多複製貼上的中文帖都站不住腳。
我覺得3pc主要解決了2pc的阻塞問題。而且相較2pc在一定程度上減少了資料不一致的可能，在一階段投票通過後，二階段存活節點都是preCommit的情況下，新協調者有理由相信事務可提交的概率比較大。當然這也會造成你說的資料不一致問題。
這也是為什麼需要其他去中心的演算法來解決這個問題。
3樓：Hollis
協調者和參與者在第一階段掛了。
由於這時還沒有執行commit操作，新選出來的協調者可以詢問各個參與者的情況，再決定是進行commit還是roolback。因為還沒有commit，所以不會導致資料一致性問題。
第二階段協調者和參與者掛了，掛了的這個參與者在掛之前並沒有接收到協調者的指令，或者接收到指令之後還沒來的及做commit或者roolback操作。
這種情況下，當新的協調者被選出來之後，他同樣是詢問所有的參與者的情況。只要有機器執行了abort（roolback）操作或者第一階段返回的資訊是No的話，那就直接執行roolback操作。如果沒有人執行abort操作，但是有機器執行了commit操作，那麼就直接執行commit操作。
這樣，當掛掉的參與者恢復之後，只要按照協調者的指示進行事務的commit還是roolback操作就可以了。因為掛掉的機器並沒有做commit或者roolback操作，而沒有掛掉的機器們和新的協調者又執行了同樣的操作，那麼這種情況不會導致資料不一致現象。
第二階段協調者和參與者掛了，掛了的這個參與者在掛之前已經執行了操作。但是由於他掛了，沒有人知道他執行了什麼操作。
這種情況下，新的協調者被選出來之後，如果他想負起協調者的責任的話他就只能按照之前那種情況來執行commit或者roolback操作。這樣新的協調者和所有沒掛掉的參與者就保持了資料的一致性，我們假定他們執行了commit。但是，這個時候，那個掛掉的參與者恢復了怎麼辦，因為他之前已經執行完了之前的事務，如果他執行的是commit那還好，和其他的機器保持一致了，萬一他執行的是roolback操作那？
這不就導致資料的不一致性了麼？雖然這個時候可以再通過手段讓他和協調者通訊，再想辦法把資料搞成一致的，但是，這段時間內他的資料狀態已經是不一致的了！
所以，2PC協議中，如果出現協調者和參與者都掛了的情況，有可能導致資料不一致。
為了解決這個問題，衍生除了3PC。我們接下來看看3PC是如何解決這個問題的。
第二階段協調者和參與者掛了，掛了的這個參與者在掛之前已經執行了操作。但是由於他掛了，沒有人知道他執行了什麼操作。
這種情況下，當新的協調者被選出來之後，他同樣是詢問所有的參與者的情況來覺得是commit還是roolback。這看上去和二階段提交一樣啊？他是怎麼解決一致性問題的呢？
看上去和二階段提交的那種資料不一致的情況的現象是一樣的，但仔細分析所有參與者的狀態的話就會發現其實並不一樣。我們假設掛掉的那台參與者執行的操作是commit。那麼其他沒掛的操作者的狀態應該是什麼？
他們的狀態要麼是prepare-commit要麼是commit。因為3PC的第三階段一旦有機器執行了commit，那必然第一階段大家都是同意commit。所以，這時，新選舉出來的協調者一旦發現未掛掉的參與者中有人處於commit狀態或者是prepare-commit的話，那就執行commit操作。
否則就執行rollback操作。這樣掛掉的參與者恢復之後就能和其他機器保持資料一致性了。（為了簡單的讓大家理解，筆者這裡簡化了新選舉出來的協調者執行操作的具體細節，真實情況比我描述的要複雜）
簡單概括一下就是，如果掛掉的那台機器已經執行了commit，那麼協調者可以從所有未掛掉的參與者的狀態中分析出來，並執行commit。如果掛掉的那個參與者執行了rollback，那麼協調者和其他的參與者執行的肯定也是rollback操作。
所以，再多引入乙個階段之後，3PC解決了2PC中存在的那種由於協調者和參與者同時掛掉有可能導致的資料一致性問題。
在doCommit階段，如果參與者無法及時接收到來自協調者的doCommit或者rebort請求時，會在等待超時之後，會繼續進行事務的提交。
所以，由於網路原因，協調者傳送的abort響應沒有及時被參與者接收到，那麼參與者在等待超時之後執行了commit操作。這樣就和其他接到abort命令並執行回滾的參與者之間存在資料不一致的情況。
4樓：
3PC第二階段參與者應該回覆ACK，表示獲得並記錄表決結果，之後該參與者的故障就可以自我恢復了。
如果第二階段有什麼原因導致不能回覆ACK，這時候就是比較嚴重的問題了，比如磁碟滿了不能記錄表決結果，這時候程式應該主動掛起並報警，解決問題後，從其他節點得到表決結果並恢復
5樓：
針對2pc問題:
這裡面有乙個狀態描述不準確:A收到中止訊息的時候到底是乙個什麼狀態，
有兩種可能
1 A已經把事務回滾成功了，但是沒有來得及回覆給協調者訊息。這種情況，A恢復回來的時候，這個事務的狀態是aborted
2 A只是接受到回滾的命令，但是還沒有來的及執行，就掛掉了。這種情況A恢復回來的狀態還是prepared
遇到這種情況，新的協調者一定得先等A恢復回來，然後去查詢A跟B裡面事務的狀態，
如果兩個事務狀態有乙個是提交的，那麼說明這個兩階段事務已經決定要提交了，新的協調者向所有的節點繼續發commit命令就行。
如果查到節點中有乙個是aborted，就向其他的節點繼續傳送abort命令即可。
如果查到兩個節點都是prepared狀態，新的協調者可以決定是提交還是回滾。
這裡面的問題是，資料庫一般都支援查詢prepared事務，已經提交或者回滾的事務的狀態是查不到的。所以提的問題是好問題，遇到這種情況，單叢資料庫方面已經不能解決了，需要dba從業務的角度決定去這個兩階段事務該怎麼走。
如果資料庫支援查詢查詢已經提交的事務和已經abort的事務的狀態，這種情況就可以按照我說的方法自動恢復回來。
另外，你說的這個問題不是資料不一致，兩階段提交資料不一致的定義是，乙個兩階段事務的參與者同時出現了aborted狀態和comitted狀態。
你這個問題是兩階段提交如何自動恢復到一致性的狀態。
3pc的問題沒有看懂。
分布式一致性協議（如Raft）可以使用UDP實現嗎？我認為是可以的，為什麼一般都是使用TCP實現呢？
owen 我先前被老闆壓迫改成udp組播模式，在我們的業務場景下，效能提公升不大。基於consul的 hashcorp的raft庫改的。 nolan raft paxos本質上是基於邏輯時鐘概念推導出來的協議，包亂序 丟包之類本來就在協議中解決了，用tcp還是udp就看效能了，個人認為內網環境下，r...
請問分布式事務一致性與raft或paxos協議解決的一致性問題是同一回事嗎？
walon 發現這麼多人長篇大論，卻沒有人能幾句說得清楚的。兩者區別在於 分布式事務，本質上是解決所有參與節點對最終事務狀態 status succ or fail 的共識問題。跟事務其實已經關係不大了。raft協議則是通過狀態複製來實現共識問題兩者之間的關係 分布式事務可以利用 raft協議來實現...
分布式一致性演算法是如何解決少數派節點的寫順序一致性問題的
Irons Du 直接看某種業務應用系統原始碼，可能讓概念更清晰，真正的摸的著的那種實在感。 楊東東 研究過paxos類協議時確實會碰到，我之前了解了paxos後寫過總結，不是專門解釋這個，是個人覺得不太好理解的地方記錄 https zhuanlan p 23 811020 正祥 這個問題本身解決起...