mq解決分布式事務(wù) 如何使用消息隊(duì)列解決分布式事務(wù)?
如何使用消息隊(duì)列解決分布式事務(wù)?有兩種選擇。Scheme 1 Local message transaction table生產(chǎn)者需要添加一個(gè)事務(wù)消息表。具體步驟如下:[1。生產(chǎn)者執(zhí)行業(yè)務(wù)邏輯并將事務(wù)
如何使用消息隊(duì)列解決分布式事務(wù)?
有兩種選擇。
Scheme 1 Local message transaction table
生產(chǎn)者需要添加一個(gè)事務(wù)消息表。具體步驟如下:[1。生產(chǎn)者執(zhí)行業(yè)務(wù)邏輯并將事務(wù)記錄插入到消息表中。這兩個(gè)操作在一個(gè)本地事務(wù)中
2。啟動(dòng)后臺(tái)線程定期輪詢消息表并將消息發(fā)送到消息隊(duì)列
3。刪除消息表中的消息,直到發(fā)送成功。
方案2需要消息隊(duì)列支持,業(yè)務(wù)端提供回溯接口
1。生產(chǎn)端將準(zhǔn)備好的消息發(fā)送到消息隊(duì)列
2。在本地事務(wù)中,業(yè)務(wù)邏輯
3。根據(jù)執(zhí)行結(jié)果確認(rèn)或取消準(zhǔn)備好的消息
4。消息隊(duì)列將確保準(zhǔn)備好的消息被確認(rèn)或取消,并且消息隊(duì)列將不斷地向生產(chǎn)端請(qǐng)求執(zhí)行結(jié)果,這要求生產(chǎn)端提供類似的回調(diào)函數(shù)。
在方案2中,消息隊(duì)列取代了方案1中的消息表和后臺(tái)線程輪詢功能,但并非所有消息隊(duì)列都支持此功能。支持Rocketmq。
方案1的開發(fā)工作量大,外部依賴性小
方案2的開發(fā)工作量小,但依賴于特定的消息隊(duì)列。
傳統(tǒng)事務(wù)為什么解決不了分布式事務(wù)?
其根本原因是傳統(tǒng)事務(wù)只能解決單個(gè)事務(wù)資源的問題,而分布式事務(wù)則考慮了多個(gè)事務(wù)資源的問題。這兩種場(chǎng)景是不同的,傳統(tǒng)的事務(wù)無法解決分布式事務(wù)的問題。
1. 傳統(tǒng)的事務(wù)通常指數(shù)據(jù)庫事務(wù),事務(wù)資源的強(qiáng)一致性保證了事務(wù)的一致性。在傳統(tǒng)的單一應(yīng)用中,由于事務(wù)資源在同一個(gè)應(yīng)用中,無法跨多個(gè)事務(wù)資源調(diào)用,因此可以高效工作;
,只需要保證數(shù)據(jù)的“最終一致性”,但最終時(shí)間需要在用戶可接受的范圍內(nèi);但在金融關(guān)聯(lián)交易領(lǐng)域,仍然需要采用強(qiáng)一致性的方法來保證交易的準(zhǔn)確性和可靠性。
3. 目前,分布式事務(wù)常用的解決方案有:兩階段提交、三階段提交、sagas長(zhǎng)事務(wù)、補(bǔ)償模式、可靠事件模式(本地事件表、外部事件表)、可靠事件模式(非事務(wù)消息、事務(wù)消息),TCC等
不同實(shí)現(xiàn)的優(yōu)缺點(diǎn)如下圖所示:
科普知識(shí)@大象聊天技術(shù)