這篇文章將為大家詳細(xì)講解有關(guān)TCC事務(wù)的解決方案是怎樣的，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

成都創(chuàng)新互聯(lián)基于成都重慶香港及美國(guó)等地區(qū)分布式IDC機(jī)房數(shù)據(jù)中心構(gòu)建的電信大帶寬，聯(lián)通大帶寬，移動(dòng)大帶寬，多線BGP大帶寬租用,是為眾多客戶提供專業(yè)服務(wù)器托管報(bào)價(jià)，主機(jī)托管價(jià)格性價(jià)比高，為金融證券行業(yè)眉山服務(wù)器托管，ai人工智能服務(wù)器托管提供bgp線路100M獨(dú)享，G口帶寬及機(jī)柜租用的專業(yè)成都idc公司。

前言

在開始之前先聊一聊什么是微服務(wù)，顧名思義，微服務(wù)得從兩個(gè)方面去理解，什么是"微"、什么是"服務(wù)"， 微 狹義來(lái)講就是體積小、著名的"2 pizza 團(tuán)隊(duì)"很好的詮釋了這一解釋（2 pizza 團(tuán)隊(duì)最早是亞馬遜 CEO Bezos提出來(lái)的，意思是說(shuō)單個(gè)服務(wù)的設(shè)計(jì)，所有參與人從設(shè)計(jì)、開發(fā)、測(cè)試、運(yùn)維所有人加起來(lái) 只需要2個(gè)披薩就夠了 ）。而所謂服務(wù)，一定要區(qū)別于系統(tǒng)，服務(wù)一個(gè)或者一組相對(duì)較小且獨(dú)立的功能單元，是用戶可以感知最小功能集。

場(chǎng)景

這里就不啰嗦哪些東西了，百度一大堆，咱們用代碼看問題~ ~。

在傳統(tǒng)的單體架構(gòu)的業(yè)務(wù)中可以使MySQL事務(wù)來(lái)保持?jǐn)?shù)據(jù)的一致性，如果跨系統(tǒng)、跨服務(wù)、跨數(shù)據(jù)庫(kù)，應(yīng)該如何保持?jǐn)?shù)據(jù)一致性呢？

概念引入

在了解分布式事務(wù)之前要先了解這兩個(gè)概念：BASE理論及CAP定理。

BASE理論

BASE是Basically Available（基本可用）、Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）三個(gè)短語(yǔ)的簡(jiǎn)寫，BASE是對(duì)CAP中一致性和可用性權(quán)衡的結(jié)果，其來(lái)源于對(duì)大規(guī)?；ヂ?lián)網(wǎng)系統(tǒng)分布式實(shí)踐的結(jié)論，是基于CAP定理逐步演化而來(lái)的，其核心思想是即使無(wú)法做到強(qiáng)一致性（Strong consistency），但每個(gè)應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹?lái)使系統(tǒng)達(dá)到最終一致性（Eventual consistency）。

• BA: Basic Availability 基本業(yè)務(wù)可用性（支持分區(qū)失敗）

• S: Soft state 柔性狀態(tài)（狀態(tài)允許有短時(shí)間不同步，異步）

• E: Eventual consistency 最終一致性（最終數(shù)據(jù)是一致的，但不是實(shí)時(shí)一致）

CAP定理

對(duì)于共享數(shù)據(jù)系統(tǒng)，最多只能同時(shí)擁有CAP其中的兩個(gè)，沒法三者兼顧，任兩者的組合都有其適用場(chǎng)景，真實(shí)系統(tǒng)應(yīng)當(dāng)是ACID與BASE的混合體，不同類型的業(yè)務(wù)可以也應(yīng)當(dāng)區(qū)別對(duì)待

柔性事務(wù)解決方案之TCC

進(jìn)入主題，介紹下分布式事務(wù)TCC的技術(shù)方案，先上一張圖。

實(shí)現(xiàn)

這里講述下，我在代碼中的實(shí)現(xiàn)思路以及方法，供大家參考，方法不一定是最好的，主要講的是實(shí)現(xiàn)的一個(gè)基本思路，可能有很多內(nèi)容沒考慮到，需要大家的指正。

業(yè)務(wù)中設(shè)計(jì)階段有：
try嘗試階段：預(yù)留扣除（增加）資源
confirm提交階段：確認(rèn)扣除（增加）資源
cancel回滾階段：回滾預(yù)留資源
也就是說(shuō)每個(gè)服務(wù)提供者必須要實(shí)現(xiàn)這三個(gè)階段的方法

1. 一個(gè)完整的業(yè)務(wù)活動(dòng)由一個(gè)主業(yè)務(wù)服務(wù)與若干從業(yè)務(wù)服務(wù)組成；

2. 主業(yè)務(wù)服務(wù)負(fù)責(zé)發(fā)起并完成整個(gè)業(yè)務(wù)活動(dòng)；

3. 從業(yè)務(wù)服務(wù)提供TCC型業(yè)務(wù)操作；

4. 業(yè)務(wù)活動(dòng)管理器控制業(yè)務(wù)活動(dòng)的一致性，它登記業(yè)務(wù)活動(dòng)中的操作， 并在業(yè)務(wù)活動(dòng)提交時(shí)確認(rèn)所有的TCC型操作的confirm操作，在業(yè)務(wù)活動(dòng)取消時(shí)調(diào)用所有TCC型操作的cancel操作

TCC事務(wù)注意事項(xiàng)

并發(fā)控制

用戶在實(shí)現(xiàn) TCC 時(shí)，應(yīng)當(dāng)考慮并發(fā)性問題，將鎖的粒度降到最低，以最大限度提高分布式事務(wù)的并發(fā)性。

在一階段 Try 操作中，分布式事務(wù) T1 和分布式事務(wù) T2 分別預(yù)留的那一部分資源，相互之間無(wú)干擾。這樣在分布式事務(wù)的二階段，無(wú)論 T1 是提交還是回滾，都不會(huì)對(duì) T2 產(chǎn)生影響，這樣 T1 和 T2 可以在同一筆業(yè)務(wù)數(shù)據(jù)上并行執(zhí)行。

允許空回滾

如下圖所示，事務(wù)協(xié)調(diào)器在調(diào)用 TCC 服務(wù)的一階段 Try 操作時(shí)，可能會(huì)出現(xiàn)因?yàn)閬G包而導(dǎo)致的網(wǎng)絡(luò)超時(shí)。此時(shí)事務(wù)管理器會(huì)觸發(fā)二階段回滾，調(diào)用 TCC 服務(wù)的 Cancel 操作，而 Cancel 操作調(diào)用未出現(xiàn)超時(shí)。

TCC 服務(wù)在未收到 Try 請(qǐng)求的情況下收到 Cancel 請(qǐng)求，這種場(chǎng)景被稱為空回滾?？栈貪L在生產(chǎn)環(huán)境經(jīng)常出現(xiàn)，用戶在實(shí)現(xiàn) TCC 服務(wù)時(shí)，應(yīng)允許空回滾的執(zhí)行，即收到空回滾時(shí)返回成功。

防懸掛控制

如下圖所示，事務(wù)協(xié)調(diào)器在調(diào)用 TCC 服務(wù)的一階段 Try 操作時(shí)，可能會(huì)出現(xiàn)因網(wǎng)絡(luò)擁堵而導(dǎo)致的超時(shí)。此時(shí)事務(wù)管理器會(huì)觸發(fā)二階段回滾，調(diào)用 TCC 服務(wù)的 Cancel 操作，Cancel 調(diào)用未超時(shí)。在此之后，擁堵在網(wǎng)絡(luò)上的一階段 Try 數(shù)據(jù)包被 TCC 服務(wù)收到，出現(xiàn)二階段 Cancel 請(qǐng)求比一階段 Try 請(qǐng)求先執(zhí)行的情況，此 TCC 服務(wù)在執(zhí)行晚到的Try 之后，將永遠(yuǎn)不會(huì)再收到二階段的 Confirm 或者 Cancel，造成 TCC 服務(wù)懸掛。

用戶在實(shí)現(xiàn) TCC 服務(wù)時(shí)，要允許空回滾，但是要拒絕執(zhí)行空回滾之后 Try 請(qǐng)求，要避免出現(xiàn)懸掛。

冪等控制

無(wú)論是網(wǎng)絡(luò)數(shù)據(jù)包重傳，還是異常事務(wù)的補(bǔ)償執(zhí)行，都會(huì)導(dǎo)致 TCC 服務(wù)的 Try、Confirm 或者 Cancel 操作被重復(fù)執(zhí)行；用戶在實(shí)現(xiàn) TCC 服務(wù)時(shí)，需要考慮冪等控制，即 Try、Confirm、Cancel 執(zhí)行一次和執(zhí)行多次的業(yè)務(wù)結(jié)果是一樣的。

關(guān)于TCC事務(wù)的解決方案是怎樣的就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。