這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)碛嘘P(guān)怎么分析分布式事務(wù)常用解決方法，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
創(chuàng)新互聯(lián)是專業(yè)的公主嶺網(wǎng)站建設(shè)公司，公主嶺接單;提供成都做網(wǎng)站、成都網(wǎng)站制作,網(wǎng)頁(yè)設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行公主嶺網(wǎng)站開發(fā)網(wǎng)頁(yè)制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!
全局事務(wù)基于DTP模型實(shí)現(xiàn)。DTP是由X/Open組織提出的一種分布式事務(wù)模型——X/Open Distributed Transaction Processing Reference Model。它規(guī)定了要實(shí)現(xiàn)分布式事務(wù)，需要三種角色：
AP：Application 應(yīng)用系統(tǒng)它就是我們開發(fā)的業(yè)務(wù)系統(tǒng)，在我們開發(fā)的過程中，可以使用資源管理器提供的事務(wù)接口來實(shí)現(xiàn)分布式事務(wù)。
TM：Transaction Manager 事務(wù)管理器
分布式事務(wù)的實(shí)現(xiàn)由事務(wù)管理器來完成，它會(huì)提供分布式事務(wù)的操作接口供我們的業(yè)務(wù)系統(tǒng)調(diào)用。這些接口稱為TX接口。
事務(wù)管理器還管理著所有的資源管理器，通過它們提供的XA接口來同一調(diào)度這些資源管理器，以實(shí)現(xiàn)分布式事務(wù)。
DTP只是一套實(shí)現(xiàn)分布式事務(wù)的規(guī)范，并沒有定義具體如何實(shí)現(xiàn)分布式事務(wù)，TM可以采用2PC、3PC、Paxos等協(xié)議實(shí)現(xiàn)分布式事務(wù)。
RM：Resource Manager 資源管理器
能夠提供數(shù)據(jù)服務(wù)的對(duì)象都可以是資源管理器，比如：數(shù)據(jù)庫(kù)、消息中間件、緩存等。大部分場(chǎng)景下，數(shù)據(jù)庫(kù)即為分布式事務(wù)中的資源管理器。
資源管理器能夠提供單數(shù)據(jù)庫(kù)的事務(wù)能力，它們通過XA接口，將本數(shù)據(jù)庫(kù)的提交、回滾等能力提供給事務(wù)管理器調(diào)用，以幫助事務(wù)管理器實(shí)現(xiàn)分布式的事務(wù)管理。
XA是DTP模型定義的接口，用于向事務(wù)管理器提供該資源管理器(該數(shù)據(jù)庫(kù))的提交、回滾等能力。
DTP只是一套實(shí)現(xiàn)分布式事務(wù)的規(guī)范，RM具體的實(shí)現(xiàn)是由數(shù)據(jù)庫(kù)廠商來完成的。
XA是一個(gè)分布式事務(wù)協(xié)議，由Tuxedo提出。XA中大致分為兩部分：事務(wù)管理器和本地資源管理器。其中本地資源管理器往往由數(shù)據(jù)庫(kù)實(shí)現(xiàn)，比如Oracle、DB2這些商業(yè)數(shù)據(jù)庫(kù)都實(shí)現(xiàn)了XA接口，而事務(wù)管理器作為全局的調(diào)度者，負(fù)責(zé)各個(gè)本地資源的提交和回滾。XA實(shí)現(xiàn)分布式事務(wù)的原理如下：
總的來說，XA協(xié)議比較簡(jiǎn)單，而且一旦商業(yè)數(shù)據(jù)庫(kù)實(shí)現(xiàn)了XA協(xié)議，使用分布式事務(wù)的成本也比較低。但是，XA也有致命的缺點(diǎn)，那就是性能不理想，特別是在交易下單鏈路，往往并發(fā)量很高，XA無法滿足高并發(fā)場(chǎng)景。XA目前在商業(yè)數(shù)據(jù)庫(kù)支持的比較理想，在MySQL數(shù)據(jù)庫(kù)中支持的不太理想，mysql的XA實(shí)現(xiàn)，沒有記錄prepare階段日志，主備切換回導(dǎo)致主庫(kù)與備庫(kù)數(shù)據(jù)不一致。許多NOSQL也沒有支持XA，這讓XA的應(yīng)用場(chǎng)景變得非常狹隘。
這種實(shí)現(xiàn)分布式事務(wù)的方式需要通過消息中間件來實(shí)現(xiàn)。假設(shè)有A和B兩個(gè)系統(tǒng)，分別可以處理任務(wù)A和任務(wù)B。此時(shí)系統(tǒng)A中存在一個(gè)業(yè)務(wù)流程，需要將任務(wù)A和任務(wù)B在同一個(gè)事務(wù)中處理。下面來介紹基于消息中間件來實(shí)現(xiàn)這種分布式事務(wù)。
在系統(tǒng)A處理任務(wù)A前，首先向消息中間件發(fā)送一條消息
消息中間件收到后將該條消息持久化，但并不投遞。此時(shí)下游系統(tǒng)B仍然不知道該條消息的存在。
消息中間件持久化成功后，便向系統(tǒng)A返回一個(gè)確認(rèn)應(yīng)答；
系統(tǒng)A收到確認(rèn)應(yīng)答后，則可以開始處理任務(wù)A；
任務(wù)A處理完成后，向消息中間件發(fā)送Commit請(qǐng)求。該請(qǐng)求發(fā)送完成后，對(duì)系統(tǒng)A而言，該事務(wù)的處理過程就結(jié)束了，此時(shí)它可以處理別的任務(wù)了。但commit消息可能會(huì)在傳輸途中丟失，從而消息中間件并不會(huì)向系統(tǒng)B投遞這條消息，從而系統(tǒng)就會(huì)出現(xiàn)不一致性。這個(gè)問題由消息中間件的事務(wù)回查機(jī)制完成，下文會(huì)介紹。
消息中間件收到Commit指令后，便向系統(tǒng)B投遞該消息，從而觸發(fā)任務(wù)B的執(zhí)行；
當(dāng)任務(wù)B執(zhí)行完成后，系統(tǒng)B向消息中間件返回一個(gè)確認(rèn)應(yīng)答，告訴消息中間件該消息已經(jīng)成功消費(fèi)，此時(shí)，這個(gè)分布式事務(wù)完成。
上述過程可以得出如下幾個(gè)結(jié)論：
消息中間件扮演者分布式事務(wù)協(xié)調(diào)者的角色。
系統(tǒng)A完成任務(wù)A后，到任務(wù)B執(zhí)行完成之間，會(huì)存在一定的時(shí)間差。在這個(gè)時(shí)間差內(nèi)，整個(gè)系統(tǒng)處于數(shù)據(jù)不一致的狀態(tài)，但這短暫的不一致性是可以接受的，因?yàn)榻?jīng)過短暫的時(shí)間后，系統(tǒng)又可以保持?jǐn)?shù)據(jù)一致性，滿足BASE理論。
上述過程中，如果任務(wù)A處理失敗，那么需要進(jìn)入回滾流程。
若系統(tǒng)A在處理任務(wù)A時(shí)失敗，那么就會(huì)向消息中間件發(fā)送Rollback請(qǐng)求。和發(fā)送Commit請(qǐng)求一樣，系統(tǒng)A發(fā)完之后便可以認(rèn)為回滾已經(jīng)完成，它便可以去做其他的事情。
消息中間件收到回滾請(qǐng)求后，直接將該消息丟棄，而不投遞給系統(tǒng)B，從而不會(huì)觸發(fā)系統(tǒng)B的任務(wù)B。
此時(shí)系統(tǒng)又處于一致性狀態(tài)，因?yàn)槿蝿?wù)A和任務(wù)B都沒有執(zhí)行。
上面所介紹的Commit和Rollback都屬于理想情況，但在實(shí)際系統(tǒng)中，Commit和Rollback指令都有可能在傳輸途中丟失。那么當(dāng)出現(xiàn)這種情況的時(shí)候，消息中間件是如何保證數(shù)據(jù)一致性呢？——答案就是超時(shí)詢問機(jī)制。
系統(tǒng)A除了實(shí)現(xiàn)正常的業(yè)務(wù)流程外，還需提供一個(gè)事務(wù)詢問的接口，供消息中間件調(diào)用。當(dāng)消息中間件收到一條事務(wù)型消息后便開始計(jì)時(shí)，如果到了超時(shí)時(shí)間也沒收到系統(tǒng)A發(fā)來的Commit或Rollback指令的話，就會(huì)主動(dòng)調(diào)用系統(tǒng)A提供的事務(wù)詢問接口詢問該系統(tǒng)目前的狀態(tài)。該接口會(huì)返回三種結(jié)果：
提交若獲得的狀態(tài)是“提交”，則將該消息投遞給系統(tǒng)B。
回滾若獲得的狀態(tài)是“回滾”，則直接將條消息丟棄。
處理中若獲得的狀態(tài)是“處理中”，則繼續(xù)等待。
消息中間件的超時(shí)詢問機(jī)制能夠防止上游系統(tǒng)因在傳輸過程中丟失Commit/Rollback指令而導(dǎo)致的系統(tǒng)不一致情況，而且能降低上游系統(tǒng)的阻塞時(shí)間，上游系統(tǒng)只要發(fā)出Commit/Rollback指令后便可以處理其他任務(wù)，無需等待確認(rèn)應(yīng)答。而Commit/Rollback指令丟失的情況通過超時(shí)詢問機(jī)制來彌補(bǔ)，這樣大大降低上游系統(tǒng)的阻塞時(shí)間，提升系統(tǒng)的并發(fā)度。
下面來說一說消息投遞過程的可靠性保證。當(dāng)上游系統(tǒng)執(zhí)行完任務(wù)并向消息中間件提交了Commit指令后，便可以處理其他任務(wù)了，此時(shí)它可以認(rèn)為事務(wù)已經(jīng)完成，接下來消息中間件一定會(huì)保證消息被下游系統(tǒng)成功消費(fèi)掉！那么這是怎么做到的呢？這由消息中間件的投遞流程來保證。
消息中間件向下游系統(tǒng)投遞完消息后便進(jìn)入阻塞等待狀態(tài)，下游系統(tǒng)便立即進(jìn)行任務(wù)的處理，任務(wù)處理完成后便向消息中間件返回應(yīng)答。消息中間件收到確認(rèn)應(yīng)答后便認(rèn)為該事務(wù)處理完畢！
如果消息在投遞過程中丟失，或消息的確認(rèn)應(yīng)答在返回途中丟失，那么消息中間件在等待確認(rèn)應(yīng)答超時(shí)之后就會(huì)重新投遞，直到下游消費(fèi)者返回消費(fèi)成功響應(yīng)為止。當(dāng)然，一般消息中間件可以設(shè)置消息重試的次數(shù)和時(shí)間間隔，比如：當(dāng)?shù)谝淮瓮哆f失敗后，每隔五分鐘重試一次，一共重試3次。如果重試3次之后仍然投遞失敗，那么這條消息就需要人工干預(yù)。
有的同學(xué)可能要問：消息投遞失敗后為什么不回滾消息，而是不斷嘗試重新投遞？
這就涉及到整套分布式事務(wù)系統(tǒng)的實(shí)現(xiàn)成本問題。我們知道，當(dāng)系統(tǒng)A將向消息中間件發(fā)送Commit指令后，它便去做別的事情了。如果此時(shí)消息投遞失敗，需要回滾的話，就需要讓系統(tǒng)A事先提供回滾接口，這無疑增加了額外的開發(fā)成本，業(yè)務(wù)系統(tǒng)的復(fù)雜度也將提高。對(duì)于一個(gè)業(yè)務(wù)系統(tǒng)的設(shè)計(jì)目標(biāo)是，在保證性能的前提下，最大限度地降低系統(tǒng)復(fù)雜度，從而能夠降低系統(tǒng)的運(yùn)維成本。
不知大家是否發(fā)現(xiàn)，上游系統(tǒng)A向消息中間件提交Commit/Rollback消息采用的是異步方式，也就是當(dāng)上游系統(tǒng)提交完消息后便可以去做別的事情，接下來提交、回滾就完全交給消息中間件來完成，并且完全信任消息中間件，認(rèn)為它一定能正確地完成事務(wù)的提交或回滾。然而，消息中間件向下游系統(tǒng)投遞消息的過程是同步的。也就是消息中間件將消息投遞給下游系統(tǒng)后，它會(huì)阻塞等待，等下游系統(tǒng)成功處理完任務(wù)返回確認(rèn)應(yīng)答后才取消阻塞等待。為什么這兩者在設(shè)計(jì)上是不一致的呢？
首先，上游系統(tǒng)和消息中間件之間采用異步通信是為了提高系統(tǒng)并發(fā)度。業(yè)務(wù)系統(tǒng)直接和用戶打交道，用戶體驗(yàn)尤為重要，因此這種異步通信方式能夠極大程度地降低用戶等待時(shí)間。此外，異步通信相對(duì)于同步通信而言，沒有了長(zhǎng)時(shí)間的阻塞等待，因此系統(tǒng)的并發(fā)性也大大增加。但異步通信可能會(huì)引起Commit/Rollback指令丟失的問題，這就由消息中間件的超時(shí)詢問機(jī)制來彌補(bǔ)。
那么，消息中間件和下游系統(tǒng)之間為什么要采用同步通信呢？
異步能提升系統(tǒng)性能，但隨之會(huì)增加系統(tǒng)復(fù)雜度；而同步雖然降低系統(tǒng)并發(fā)度，但實(shí)現(xiàn)成本較低。因此，在對(duì)并發(fā)度要求不是很高的情況下，或者服務(wù)器資源較為充裕的情況下，我們可以選擇同步來降低系統(tǒng)的復(fù)雜度。我們知道，消息中間件是一個(gè)獨(dú)立于業(yè)務(wù)系統(tǒng)的第三方中間件，它不和任何業(yè)務(wù)系統(tǒng)產(chǎn)生直接的耦合，它也不和用戶產(chǎn)生直接的關(guān)聯(lián)，它一般部署在獨(dú)立的服務(wù)器集群上，具有良好的可擴(kuò)展性，所以不必太過于擔(dān)心它的性能，如果處理速度無法滿足我們的要求，可以增加機(jī)器來解決。而且，即使消息中間件處理速度有一定的延遲那也是可以接受的，因?yàn)榍懊嫠榻B的BASE理論就告訴我們了，我們追求的是最終一致性，而非實(shí)時(shí)一致性，因此消息中間件產(chǎn)生的時(shí)延導(dǎo)致事務(wù)短暫的不一致是可以接受的。
最大努力通知也被稱為定期校對(duì)，其實(shí)在方案二中已經(jīng)包含，這里再單獨(dú)介紹，主要是為了知識(shí)體系的完整性。這種方案也需要消息中間件的參與。
上游系統(tǒng)在完成任務(wù)后，向消息中間件同步地發(fā)送一條消息，確保消息中間件成功持久化這條消息，然后上游系統(tǒng)可以去做別的事情了；
消息中間件收到消息后負(fù)責(zé)將該消息同步投遞給相應(yīng)的下游系統(tǒng)，并觸發(fā)下游系統(tǒng)的任務(wù)執(zhí)行；
當(dāng)下游系統(tǒng)處理成功后，向消息中間件反饋確認(rèn)應(yīng)答，消息中間件便可以將該條消息刪除，從而該事務(wù)完成。
上面是一個(gè)理想化的過程，但在實(shí)際場(chǎng)景中，往往會(huì)出現(xiàn)如下幾種意外情況：
消息中間件向下游系統(tǒng)投遞消息失敗
上游系統(tǒng)向消息中間件發(fā)送消息失敗
對(duì)于第一種情況，消息中間件具有重試機(jī)制，我們可以在消息中間件中設(shè)置消息的重試次數(shù)和重試時(shí)間間隔，對(duì)于網(wǎng)絡(luò)不穩(wěn)定導(dǎo)致的消息投遞失敗的情況，往往重試幾次后消息便可以成功投遞，如果超過了重試的上限仍然投遞失敗，那么消息中間件不再投遞該消息，而是記錄在失敗消息表中，消息中間件需要提供失敗消息的查詢接口，下游系統(tǒng)會(huì)定期查詢失敗消息，并將其消費(fèi)，這就是所謂的“定期校對(duì)”。
如果重復(fù)投遞和定期校對(duì)都不能解決問題，往往是因?yàn)橄掠蜗到y(tǒng)出現(xiàn)了嚴(yán)重的錯(cuò)誤，此時(shí)就需要人工干預(yù)。
對(duì)于第二種情況，需要在上游系統(tǒng)中建立消息重發(fā)機(jī)制?？梢栽谏嫌蜗到y(tǒng)建立一張本地消息表，并將 任務(wù)處理過程和 向本地消息表中插入消息這兩個(gè)步驟放在一個(gè)本地事務(wù)中完成。如果向本地消息表插入消息失敗，那么就會(huì)觸發(fā)回滾，之前的任務(wù)處理結(jié)果就會(huì)被取消。如果這量步都執(zhí)行成功，那么該本地事務(wù)就完成了。接下來會(huì)有一個(gè)專門的消息發(fā)送者不斷地發(fā)送本地消息表中的消息，如果發(fā)送失敗它會(huì)返回重試。當(dāng)然，也要給消息發(fā)送者設(shè)置重試的上限，一般而言，達(dá)到重試上限仍然發(fā)送失敗，那就意味著消息中間件出現(xiàn)嚴(yán)重的問題，此時(shí)也只有人工干預(yù)才能解決問題。
對(duì)于不支持事務(wù)型消息的消息中間件，如果要實(shí)現(xiàn)分布式事務(wù)的話，就可以采用這種方式。它能夠通過重試機(jī)制+定期校對(duì)實(shí)現(xiàn)分布式事務(wù)，但相比于第二種方案，它達(dá)到數(shù)據(jù)一致性的周期較長(zhǎng)，而且還需要在上游系統(tǒng)中實(shí)現(xiàn)消息重試發(fā)布機(jī)制，以確保消息成功發(fā)布給消息中間件，這無疑增加了業(yè)務(wù)系統(tǒng)的開發(fā)成本，使得業(yè)務(wù)系統(tǒng)不夠純粹，并且這些額外的業(yè)務(wù)邏輯無疑會(huì)占用業(yè)務(wù)系統(tǒng)的硬件資源，從而影響性能。
因此，盡量選擇支持事務(wù)型消息的消息中間件來實(shí)現(xiàn)分布式事務(wù)，如RocketMQ。
跨應(yīng)用的業(yè)務(wù)操作原子性要求，其實(shí)是比較常見的。比如在第三方支付場(chǎng)景中的組合支付，用戶在電商網(wǎng)站購(gòu)物后，要同時(shí)使用余額和
紅包支付該筆訂單，而余額系統(tǒng)和紅包系統(tǒng)分別是不同的應(yīng)用系統(tǒng)，支付系統(tǒng)在調(diào)用這兩個(gè)系統(tǒng)進(jìn)行支付時(shí)，就需要保證余額扣減和紅
包使用要么同時(shí)成功，要么同時(shí)失敗。
TCC事務(wù)的出現(xiàn)正是為了解決應(yīng)用拆分帶來的跨應(yīng)用業(yè)務(wù)操作原子性的問題。當(dāng)然，由于常規(guī)的XA事務(wù)(2PC，2 Phase Commit, 兩階段提交)
性能上不盡如人意，也有通過TCC事務(wù)來解決數(shù)據(jù)庫(kù)拆分的使用場(chǎng)景(如賬務(wù)拆分)，這個(gè)本文后續(xù)部分再詳述。
故從整個(gè)系統(tǒng)架構(gòu)的角度來看，分布式事務(wù)的不同方案是存在層次結(jié)構(gòu)的。
明眼一看就知道，TCC應(yīng)該是三個(gè)英文單詞的首字母縮寫而來。沒錯(cuò)，TCC分別對(duì)應(yīng)Try、Confirm和Cancel三種操作，
這三種操作的業(yè)務(wù)含義如下：
Try：預(yù)留業(yè)務(wù)資源Confirm：確認(rèn)執(zhí)行業(yè)務(wù)操作Cancel：取消執(zhí)行業(yè)務(wù)操作
稍稍對(duì)照下關(guān)系型數(shù)據(jù)庫(kù)事務(wù)的三種操作：DML、Commit和Rollback，會(huì)發(fā)現(xiàn)和TCC有異曲同工之妙。在一個(gè)跨應(yīng)用的業(yè)務(wù)操作中，
Try操作是先把多個(gè)應(yīng)用中的業(yè)務(wù)資源預(yù)留和鎖定住，為后續(xù)的確認(rèn)打下基礎(chǔ)，類似的，DML操作要鎖定數(shù)據(jù)庫(kù)記錄行，持有數(shù)據(jù)庫(kù)資源；
Confirm操作是在Try操作中涉及的所有應(yīng)用均成功之后進(jìn)行確認(rèn)，使用預(yù)留的業(yè)務(wù)資源，和Commit類似；
而Cancel則是當(dāng)Try操作中涉及的所有應(yīng)用沒有全部成功，需要將已成功的應(yīng)用進(jìn)行取消(即Rollback回滾)。
其中Confirm和Cancel操作是一對(duì)反向業(yè)務(wù)操作。
簡(jiǎn)而言之，TCC是應(yīng)用層的2PC(2 Phase Commit, 兩階段提交)，如果你將應(yīng)用看做資源管理器的話。
詳細(xì)來說，TCC每項(xiàng)操作需要做的事情如下：
1、Try：嘗試執(zhí)行業(yè)務(wù)。
完成所有業(yè)務(wù)檢查(一致性)
預(yù)留必須業(yè)務(wù)資源(準(zhǔn)隔離性)
2、Confirm：確認(rèn)執(zhí)行業(yè)務(wù)。
真正執(zhí)行業(yè)務(wù)
不做任何業(yè)務(wù)檢查
只使用Try階段預(yù)留的業(yè)務(wù)資源
3、Cancel：取消執(zhí)行業(yè)務(wù)
釋放Try階段預(yù)留的業(yè)務(wù)資源
主業(yè)務(wù)服務(wù)：主業(yè)務(wù)服務(wù)為整個(gè)業(yè)務(wù)活動(dòng)的發(fā)起方，如前面提到的組合支付場(chǎng)景，支付系統(tǒng)即是主業(yè)務(wù)服務(wù)。
從業(yè)務(wù)服務(wù)：從業(yè)務(wù)服務(wù)負(fù)責(zé)提供TCC業(yè)務(wù)操作，是整個(gè)業(yè)務(wù)活動(dòng)的操作方。從業(yè)務(wù)服務(wù)必須實(shí)現(xiàn)Try、Confirm和Cancel三個(gè)接口，
供主業(yè)務(wù)服務(wù)調(diào)用。
由于Confirm和Cancel操作可能被重復(fù)調(diào)用，故要求Confirm和Cancel兩個(gè)接口必須是冪等的。前面的組合支付場(chǎng)景中的余額系統(tǒng)和
紅包系統(tǒng)即為從業(yè)務(wù)服務(wù)。
業(yè)務(wù)活動(dòng)管理器：業(yè)務(wù)活動(dòng)管理器管理控制整個(gè)業(yè)務(wù)活動(dòng)，包括記錄維護(hù)TCC全局事務(wù)的事務(wù)狀態(tài)和每個(gè)從業(yè)務(wù)服務(wù)的子事務(wù)狀態(tài)，并在業(yè)務(wù)活動(dòng)提交時(shí)確認(rèn)所有的TCC型操作的confirm操作，在業(yè)務(wù)活動(dòng)取消時(shí)調(diào)用所有TCC型操作的cancel操作。
可見整個(gè)TCC事務(wù)對(duì)于主業(yè)務(wù)服務(wù)來說是透明的，其中業(yè)務(wù)活動(dòng)管理器和從業(yè)務(wù)服務(wù)各自干了一部分工作。
TCC事務(wù)的優(yōu)點(diǎn)如下：
解決了跨應(yīng)用業(yè)務(wù)操作的原子性問題，在諸如組合支付、賬務(wù)拆分場(chǎng)景非常實(shí)用。
TCC實(shí)際上把數(shù)據(jù)庫(kù)層的二階段提交上提到了應(yīng)用層來實(shí)現(xiàn)，對(duì)于數(shù)據(jù)庫(kù)來說是一階段提交，規(guī)避了數(shù)據(jù)庫(kù)層的2PC性能低下問題。
TCC事務(wù)的缺點(diǎn)，主要就一個(gè)：
TCC的Try、Confirm和Cancel操作功能需業(yè)務(wù)提供，開發(fā)成本高。
當(dāng)然，對(duì)TCC事務(wù)的這個(gè)缺點(diǎn)是否是缺點(diǎn)，是一個(gè)見仁見智的事情。
TCC說實(shí)話，TCC的理論有點(diǎn)讓人費(fèi)解。故接下來將以賬務(wù)拆分為例，對(duì)TCC事務(wù)的流程做一個(gè)描述，希望對(duì)理解TCC有所幫助。
賬務(wù)拆分的業(yè)務(wù)場(chǎng)景如下，分別位于三個(gè)不同分庫(kù)的帳戶A、B、C，A和B一起向C轉(zhuǎn)帳共80元：分布式事務(wù)之說說TCC事務(wù)
1、Try：嘗試執(zhí)行業(yè)務(wù)。
完成所有業(yè)務(wù)檢查(一致性)：檢查A、B、C的帳戶狀態(tài)是否正常，帳戶A的余額是否不少于30元，帳戶B的余額是否不少于50元。
預(yù)留必須業(yè)務(wù)資源(準(zhǔn)隔離性)：帳戶A的凍結(jié)金額增加30元，帳戶B的凍結(jié)金額增加50元，這樣就保證不會(huì)出現(xiàn)其他并發(fā)進(jìn)程扣減
了這兩個(gè)帳戶的余額而導(dǎo)致在后續(xù)的真正轉(zhuǎn)帳操作過程中，帳戶A和B的可用余額不夠的情況。
2、Confirm：確認(rèn)執(zhí)行業(yè)務(wù)。
真正執(zhí)行業(yè)務(wù)：如果Try階段帳戶A、B、C狀態(tài)正常，且?guī)鬉、B余額夠用，則執(zhí)行帳戶A給賬戶C轉(zhuǎn)賬30元、帳戶B給賬戶C轉(zhuǎn)賬50元的
轉(zhuǎn)帳操作。
不做任何業(yè)務(wù)檢查：這時(shí)已經(jīng)不需要做業(yè)務(wù)檢查，Try階段已經(jīng)完成了業(yè)務(wù)檢查。
只使用Try階段預(yù)留的業(yè)務(wù)資源：只需要使用Try階段帳戶A和帳戶B凍結(jié)的金額即可。
3、Cancel：取消執(zhí)行業(yè)務(wù)
釋放Try階段預(yù)留的業(yè)務(wù)資源：如果Try階段部分成功，比如帳戶A的余額夠用，且凍結(jié)相應(yīng)金額成功，帳戶B的余額不夠而凍結(jié)失敗，則需要對(duì)帳戶A做Cancel操作，將帳戶A被凍結(jié)的金額解凍掉。
上述就是小編為大家分享的怎么分析分布式事務(wù)常用解決方法了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
重慶分公司
重慶分公司
