摘要：?jiǎn)l(fā)從事務(wù)消息談分布式事務(wù)事務(wù)消息本質(zhì)上解決的問(wèn)題是業(yè)務(wù)系統(tǒng)與消息系統(tǒng)之間的事務(wù)問(wèn)題跨系統(tǒng)分布式事務(wù)，其基本原理即兩階段提交以及最終一致性保障。準(zhǔn)備工作創(chuàng)建兩個(gè)隊(duì)列事務(wù)消息隊(duì)列消息的有效期小于消息延遲時(shí)間。消息延遲時(shí)間為事務(wù)操作超時(shí)時(shí)間。

事務(wù)消息本質(zhì)上解決的問(wèn)題是業(yè)務(wù)系統(tǒng)與消息系統(tǒng)之間的事務(wù)問(wèn)題（跨系統(tǒng)分布式事務(wù)），其基本原理即兩階段提交以及最終一致性保障。最近看了下阿里云mns事務(wù)消息的實(shí)現(xiàn)原理，介紹的蠻簡(jiǎn)潔透徹的，對(duì)了解分布式事務(wù)實(shí)現(xiàn)原理挺有幫助，在閱讀本文前推薦大家先仔細(xì)閱讀下阿里云"mns事務(wù)消息"一文。

事務(wù)消息

背景描述
有時(shí)候我們需要實(shí)現(xiàn)本地操作和消息發(fā)送的事務(wù)一致性功能。即：消息發(fā)送成功，則本地操作成功；反之，如果消息發(fā)送失敗，本地操作失敗（成功也需要rollback）。保證不出現(xiàn)操作成功但消息發(fā)送失??；或者操作失敗但消息發(fā)送成功的情況；
另外，消費(fèi)端，我們也希望消息一定被成功處理一次，不會(huì)因?yàn)橄⒍顺绦虮罎⒍鴮?dǎo)致消息沒(méi)有成功處理，進(jìn)而需要人工重置消費(fèi)進(jìn)度。
解決方案
利用消息服務(wù)MNS的延遲消息功能來(lái)實(shí)現(xiàn)。
準(zhǔn)備工作
創(chuàng)建兩個(gè)隊(duì)列：


1.事務(wù)消息隊(duì)列
消息的有效期小于消息延遲時(shí)間。即如果生產(chǎn)者不主動(dòng)修改（提交）消息可見(jiàn)時(shí)間，消息對(duì)消費(fèi)者不可見(jiàn)；


2.操作日志隊(duì)列
記錄事務(wù)消息的操作記錄信息。消息延遲時(shí)間為事務(wù)操作超時(shí)時(shí)間。日志隊(duì)列中的消息確認(rèn)（刪除）后將對(duì)消費(fèi)者不可見(jiàn)。



具體步驟

1.發(fā)送一條事務(wù)準(zhǔn)備消息到事務(wù)消息隊(duì)列；
2.寫(xiě)操作日志信息到操作日志隊(duì)列，日志中包含步驟1消息的消息句柄；
3.執(zhí)行本地事務(wù)操作；
4.如果步驟3成功，提交消息（消息對(duì)消費(fèi)者可見(jiàn)）；反之，回滾消息；
5.確認(rèn)步驟2中的操作日志（刪除該日志消息）；
6.步驟4后，消費(fèi)者可以接收到事務(wù)消息；
7.消費(fèi)者處理消息；
8.消費(fèi)者確認(rèn)刪除消息；
如下圖：

異常分析：
生產(chǎn)者異常(例如：進(jìn)程重啟):
A.讀取操作日志隊(duì)列超時(shí)未確認(rèn)日志
B.檢查事務(wù)結(jié)果
C.如果檢查得到事務(wù)已經(jīng)成功，則提交消息（重復(fù)提交無(wú)副作用，同一句柄的消息只能成功提交一次）
D.確認(rèn)操作日志
消費(fèi)者異常（例如：進(jìn)程重啟）：
消息服務(wù)提供至少保證消費(fèi)一次的特性，只要步驟8不成功，消息在一段時(shí)間后可以繼續(xù)可見(jiàn)，被當(dāng)前消費(fèi)者或者其他消費(fèi)者處理。
消息服務(wù)不可達(dá)（例如：斷網(wǎng)）
消息發(fā)送和接收處理狀態(tài)以及操作日志都在消息服務(wù)端，消息服務(wù)本身具備高可靠和高可用的特點(diǎn)，所以只要網(wǎng)絡(luò)恢復(fù)，事務(wù)可以繼續(xù)，能保證只要生產(chǎn)者：操作成功，則消費(fèi)者一定能夠拿到消息并處理成功；或操作失敗, 則消費(fèi)者收不到消息的最終一致性。

原文地址

1.在執(zhí)行事務(wù)前先preSendMessage：其背后的原理是創(chuàng)建一個(gè)delay message，但是這個(gè)delay message的delaytime > lifetime, 基于這個(gè)前提在得到確切的commit/rollback操作前，這個(gè)消息對(duì)于接受者是永遠(yuǎn)不可見(jiàn)的；

2.本地事務(wù)結(jié)束后commit/rollback message：如果本地事務(wù)提交成功，需要將之前提交的delay message設(shè)置為消費(fèi)者可見(jiàn)（底層實(shí)現(xiàn)應(yīng)該與將delay變?yōu)?類(lèi)似）；對(duì)應(yīng)的如果本地事務(wù)提交失敗，需要將之前的delay message刪除；

這個(gè)過(guò)程需要注意到，我們務(wù)必保證在preSendMessage沒(méi)得到最終確認(rèn)之前不被消費(fèi)者獲取到，因此需要將發(fā)送的lifetime小于delaytime。

看到這里也許你有疑問(wèn)，為什么要將過(guò)程切分成兩階段提交？我們先假設(shè)如果采用一次提交的策略，很顯然這次提交的切入點(diǎn)只能存在于①本地事務(wù)開(kāi)始之前②本地事務(wù)中③本地事務(wù)結(jié)束之后，那么先看這三個(gè)切入點(diǎn)各自存在什么問(wèn)題。

①本地事務(wù)開(kāi)始之前提交消息：在本地事務(wù)未完成之前，消息的消費(fèi)者讀取到了message，如果消費(fèi)者后續(xù)的服務(wù)調(diào)用中存在對(duì)該次本地事務(wù)提交有依賴(lài)，那必然導(dǎo)致數(shù)據(jù)不一致問(wèn)題；如果本地事務(wù)的執(zhí)行結(jié)果是失敗的，卻通知了消費(fèi)者，很顯然會(huì)導(dǎo)致不可預(yù)期的數(shù)據(jù)錯(cuò)誤。

②本地事務(wù)中：在本地事務(wù)中提交消息同樣會(huì)存在①中的問(wèn)題，即便sendmessage是在本地事務(wù)的最后執(zhí)行，因?yàn)槭聞?wù)的提交和消息被接受到的時(shí)序是無(wú)法保證的；

③本地事務(wù)結(jié)束之后：不同于①②兩個(gè)提交點(diǎn)，本地事務(wù)完成之后我們能夠明確的知道本地事務(wù)的執(zhí)行結(jié)果，因此能夠確保事務(wù)提交(回滾)與消息被接受是有序的；然而如果消息沒(méi)有被成功發(fā)送消費(fèi)者接受不到消息，而本地事務(wù)卻得到了正確執(zhí)行，這就導(dǎo)致了數(shù)據(jù)不一致問(wèn)題，并且如果沒(méi)有操作日志，這個(gè)問(wèn)題將變得難以追溯；

”單次提交“遇到的主要問(wèn)題是：無(wú)法保障本地事務(wù)與消息被接受到的時(shí)序問(wèn)題（或者說(shuō)兩個(gè)分布式事務(wù)的時(shí)序）以及數(shù)據(jù)的一致性問(wèn)題。再回到”兩階段提交“，兩階段提交能解決這兩個(gè)問(wèn)題嗎？?jī)呻A段提交的確認(rèn)操作是在本地事務(wù)完成之后（這個(gè)類(lèi)似于③），因此其能夠解決時(shí)序問(wèn)題，但是如果這個(gè)確認(rèn)操作執(zhí)行的過(guò)程中發(fā)生了宕機(jī)等情況導(dǎo)致確認(rèn)操作失敗，依然會(huì)導(dǎo)致數(shù)據(jù)不一致問(wèn)題。

mns通過(guò)延遲消息機(jī)制實(shí)現(xiàn)了兩階段提交，其如何保證數(shù)據(jù)一致性問(wèn)題呢？一般我們的策略都是通過(guò)操作流水來(lái)進(jìn)行補(bǔ)償以達(dá)到數(shù)據(jù)的最終一致性，同樣的mns也是基于這個(gè)原理實(shí)現(xiàn)。

在preSendMessage之后，mns會(huì)在日志隊(duì)列中記錄一條opLog(opLog通過(guò)記錄preSendMessage的receipthandle來(lái)進(jìn)行關(guān)聯(lián))，并且將這個(gè)opLog的delayTime設(shè)置為事務(wù)的超時(shí)時(shí)間；

當(dāng)本地事務(wù)執(zhí)行結(jié)束，并且preSendMessage被commit/rollback之后，再將這條opLog刪除；

同時(shí)存在一個(gè)任務(wù)監(jiān)聽(tīng)日志隊(duì)列，當(dāng)接收到opLog的消息，檢查對(duì)應(yīng)的preSendMessage相關(guān)聯(lián)的本地事務(wù)是否執(zhí)行成功。如果本地事務(wù)執(zhí)行成功，則通過(guò)opLog中保存的receipthandle補(bǔ)償一次對(duì)preSendMessage的commit操作，如果checker發(fā)現(xiàn)本地事務(wù)執(zhí)行失敗，那對(duì)應(yīng)的補(bǔ)償一次rollback操作；

通過(guò)建立對(duì)opLog的監(jiān)聽(tīng)，我們能夠確保事務(wù)的最終一致性嗎？回答這個(gè)問(wèn)題前，我們先看這個(gè)問(wèn)題的本質(zhì)：最終、一致性。
最終一致性問(wèn)題的產(chǎn)生是由于發(fā)生了一些不可預(yù)期的問(wèn)題，導(dǎo)致一個(gè)事務(wù)被提交（回滾），但消息沒(méi)被commit（rollback）。我們通過(guò)opLog來(lái)追溯那些沒(méi)有得到最終確認(rèn)的消息并進(jìn)行補(bǔ)償（最終），并且通過(guò)檢查本地事務(wù)的狀態(tài)來(lái)確認(rèn)這次補(bǔ)償是commit或者是rollback（一致性）。正是基于這個(gè)補(bǔ)償?shù)牟呗?，mns事務(wù)消息解決了"兩階段提交"所遺留的一致性問(wèn)題，但這個(gè)過(guò)程中我們需要注意幾個(gè)細(xì)節(jié)：

補(bǔ)償策略執(zhí)行的時(shí)候需要明確知道本地事務(wù)的執(zhí)行結(jié)果，因此我們的本地事務(wù)中需要記錄preSendMessage所關(guān)聯(lián)的本地事務(wù)操作結(jié)果。我們的做法是本地事務(wù)中同時(shí)記錄下preSendMessage的receipthandle, 當(dāng)補(bǔ)償任務(wù)執(zhí)行的時(shí)候，會(huì)通過(guò)opLog關(guān)聯(lián)的receipthandle來(lái)檢查，如果沒(méi)有找到相關(guān)記錄，那認(rèn)為之前的本地事務(wù)被rollback了，否則commit;

MNS如何建立了preSendMessage<=>Local Transaction<=>opLog之間的關(guān)聯(lián)關(guān)系？最簡(jiǎn)單的實(shí)現(xiàn)肯定是通過(guò)preSendMessage的MessageId來(lái)實(shí)現(xiàn)，不過(guò)mns通過(guò)preSendMessage的receipthandle來(lái)建立了這個(gè)關(guān)聯(lián)（ReceiptHandle含義）同時(shí)避免了額外的存儲(chǔ)；

mns的補(bǔ)償機(jī)制建立在對(duì)opLog的監(jiān)聽(tīng)，那么我們?cè)趺创_定一個(gè)補(bǔ)償?shù)膱?zhí)行時(shí)機(jī)是合適的呢？補(bǔ)償一定要在事務(wù)有明確結(jié)果之后執(zhí)行才有意義，那么什么時(shí)候能得到明確的事務(wù)執(zhí)行結(jié)果？其實(shí)我們是無(wú)法確切的知道這個(gè)時(shí)間點(diǎn)的，但我們能夠有一個(gè)最低期望時(shí)間：不管一個(gè)事務(wù)成功或者失敗，它的周期都不能超過(guò)事務(wù)的超時(shí)時(shí)間。因此我們?cè)诎l(fā)送opLog時(shí)需要設(shè)置opLog的delayTime>TransactionTimeout(如何確認(rèn)transactionTimeout)來(lái)保證補(bǔ)償任務(wù)執(zhí)行的時(shí)候本地事務(wù)一定執(zhí)行完成。

上面啰嗦的寫(xiě)了一堆，看到這我們不妨對(duì)思考下mns事務(wù)消息解決的是業(yè)務(wù)系統(tǒng)(本地事務(wù))與消息中間件之間的事務(wù)協(xié)同問(wèn)題，如果是兩個(gè)業(yè)務(wù)系統(tǒng)之間的分布式事務(wù)如何實(shí)現(xiàn)？
好吧，如果堅(jiān)持看到這，你可能覺(jué)得我標(biāo)題黨了...那么我建議你再讀一下”mns事務(wù)消息“一文。

更多文章請(qǐng)?jiān)L問(wèn)我的博客
轉(zhuǎn)載請(qǐng)注明出處