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