資訊專欄INFORMATION COLUMN
摘要：以兩階段提交來說，主持人收到一個提案請求，打電話跟每個組員詢問是否通過并統(tǒng)計回復(fù)，然后將最后決定打電話通知各組員。三階段提交即是引入了另一個步驟，主持人打電話跟組員通知請準備通過提案，以避免沒人知道真實決定而造成決定不一致的失業(yè)危機。
3PC
以兩階段提交來說，主持人收到一個提案請求，打電話跟每個組員詢問是否通過并統(tǒng)計回復(fù)，然后將最后決定打電話通知各組員。要是主持人在跟第一位組員通完電話后失憶，而第一位組員在得知結(jié)果并執(zhí)行后老人癡呆，那么即使重新選出主持人，也沒人知道最后的提案決定是什么，也許是通過，也許是駁回，不管大家選擇哪一種決定，都有可能與第一位組員已執(zhí)行過的真實決定不一致，老板就會不開心認為決策小組溝通有問題而解雇。三階段提交即是引入了另一個步驟，主持人打電話跟組員通知請準備通過提案，以避免沒人知道真實決定而造成決定不一致的失業(yè)危機。為什么能夠解決二階段提交的問題呢？回到剛剛提到的狀況，在主持人通知完第一位組員請準備通過后兩人意外失憶，即使沒人知道全體在第一階段的決定為何，全體決策組員仍可以重新協(xié)調(diào)過程或直接否決，不會有不一致決定而失業(yè)。那么當(dāng)主持人通知完全體組員請準備通過并得到大家的再次確定后進入第三階段，當(dāng)主持人通知第一位組員請通過提案后兩人意外失憶，這時候其他組員再重新選出主持人后，仍可以知道目前至少是處于準備通過提案階段，表示第一階段大家都已經(jīng)決定要通過了，此時便可以直接通過 --------
以上資料來自wiki百科,說明在2PC過程中,在第二個階段當(dāng)協(xié)調(diào)者通知第一個客戶端A,并且第一個客戶端剛好執(zhí)行完畢以后,這兩臺機器都Down掉了,而恰好這N-1臺機器投的都是Yes票(都處于不確定的狀態(tài)),這個時候整個事務(wù)就會被Block,暫時稱之為聾啞事件
客戶端A投的是Abort票,那么由于協(xié)調(diào)者和客戶端A都Down掉,那么整個事務(wù)應(yīng)該是abort
客戶端A投的是commit票,并且協(xié)調(diào)者決定commit,那么整個事務(wù)應(yīng)該是commit
客戶端A投的是commit票,并且協(xié)調(diào)者由于自身的原因決定abort,那么整個事務(wù)應(yīng)該是abort
在3PC中引入了一個預(yù)提交的狀態(tài)
當(dāng)在第二階段出現(xiàn)聾啞事件,那么這N-1臺機器可以根據(jù)超時機制直接abort掉,因為客戶端A如果提交了事務(wù),只是預(yù)提交,當(dāng)該機器重啟以后只要詢問周邊機器事務(wù)狀態(tài),簡單的將事務(wù)回滾或者提交事務(wù),就能保持事務(wù)的最終一致性
當(dāng)進行到第三階段的時候,如果發(fā)生聾啞事件,那么其它處于「不確定狀態(tài)」的客戶端會直接執(zhí)行commit,而不會像2PC一樣導(dǎo)致事務(wù)block,但是這樣會有一個風(fēng)險(進入到第三個階段說明客戶端在第一階段投的都是Yes),因為在聾啞事件中,那臺Down掉的機器在第二階段中給協(xié)調(diào)者發(fā)送的不是prepared,這個時候協(xié)調(diào)者收到消息給客戶端發(fā)送的是abort命令.所以3PC只是樂觀的認為只要你第一階段大家投的都是Yes,那么最后成功提交的幾率很大
關(guān)于分布式事務(wù)、兩階段提交協(xié)議、三階提交協(xié)議
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/65576.html
摘要：以兩階段提交來說，主持人收到一個提案請求，打電話跟每個組員詢問是否通過并統(tǒng)計回復(fù)，然后將最后決定打電話通知各組員。三階段提交即是引入了另一個步驟，主持人打電話跟組員通知請準備通過提案，以避免沒人知道真實決定而造成決定不一致的失業(yè)危機。 3PC 以兩階段提交來說，主持人收到一個提案請求，打電話跟每個組員詢問是否通過并統(tǒng)計回復(fù)，然后將最后決定打電話通知各組員。要是主持人在跟第一位組員通完電...
摘要：最終一致性二基于的分布式事務(wù)補償機制序列圖異常場景處理預(yù)創(chuàng)建訂單失敗如果實際預(yù)創(chuàng)建訂單成功訂單定時補償機制定時刪除這部分訂單不影響數(shù)據(jù)一致性下單失敗預(yù)扣減庫存失敗如果預(yù)扣減庫存真實失敗則下單失敗訂單由定時補償機制定時刪除其它應(yīng)用參照場景的處 最終一致性(二) 基于MQ的分布式事務(wù)補償機制 序列圖 showImg(https://segmentfault.com/img/bVzeHX);...
摘要：最終一致性二基于的分布式事務(wù)補償機制序列圖異常場景處理預(yù)創(chuàng)建訂單失敗如果實際預(yù)創(chuàng)建訂單成功訂單定時補償機制定時刪除這部分訂單不影響數(shù)據(jù)一致性下單失敗預(yù)扣減庫存失敗如果預(yù)扣減庫存真實失敗則下單失敗訂單由定時補償機制定時刪除其它應(yīng)用參照場景的處 最終一致性(二) 基于MQ的分布式事務(wù)補償機制 序列圖 showImg(/img/bVzeHX); 異常場景處理 預(yù)創(chuàng)建訂單失敗:如果實際預(yù)創(chuàng)建...
摘要：如上圖所示，的實際上是已中間件的形式放在應(yīng)用層，不用依賴數(shù)據(jù)庫對協(xié)議的支持，完全剝離了分布式事務(wù)方案對數(shù)據(jù)庫在協(xié)議支持上的要求。 微信公眾號「后端進階」，專注后端技術(shù)分享：Java、Golang、WEB框架、分布式中間件、服務(wù)治理等等。 在微服務(wù)架構(gòu)體系下，我們可以按照業(yè)務(wù)模塊分層設(shè)計，單獨部署，減輕了服務(wù)部署壓力，也解耦了業(yè)務(wù)的耦合，避免了應(yīng)用逐漸變成一個龐然怪物，從而可以輕松擴展，...
摘要：最終一致性一簡介是由支付寶架構(gòu)師提供的一種柔性解決分布式事務(wù)解決方案主要包括三個步驟流程的關(guān)鍵流程如下圖以下單和扣減庫存為例子預(yù)生成訂單失敗了為什么要通過執(zhí)行預(yù)處理數(shù)據(jù)回滾可能預(yù)生成訂單成功但是接口返回失敗超時失敗所以預(yù)處理在某些情況下是有 最終一致性(一) TCC 簡介 TCC是由支付寶架構(gòu)師提供的一種柔性解決分布式事務(wù)解決方案,主要包括三個步驟:showImg(/img/bVzc6...
閱讀 1879·2019-08-30 15:53
閱讀 3204·2019-08-30 15:44
閱讀 2813·2019-08-26 13:31
閱讀 1957·2019-08-26 12:10
閱讀 802·2019-08-26 11:01
閱讀 2133·2019-08-23 15:32
閱讀 1590·2019-08-23 13:43
閱讀 2545·2019-08-23 11:58
