title: 分布式事務(wù)TCC機(jī)制
publish_date: 2019-05-12
tags: #分布式, #TCC, #事務(wù), #Dubbo, 最新發(fā)布, 熱門(mén)推薦
source: CSDN博客
original_url: https://blog.csdn.net/xuri24/article/details/90142430
?? 本文首發(fā)于CSDN：分布式事務(wù)TCC機(jī)制
前言
分布式事務(wù)是幾乎所有分布式微服務(wù)系統(tǒng)中，最棘手也是最重要的一個(gè)點(diǎn)了。在講解分布式事務(wù)前，先了解下數(shù)據(jù)庫(kù)事務(wù)的特性；數(shù)據(jù)庫(kù)事務(wù)的幾個(gè)特性：原子性(Atomicity )、一致性( Consistency )、隔離性或獨(dú)立性( Isolation)和持久性(Durabilily)，簡(jiǎn)稱(chēng)就是ACID。
CAP定理
CAP定理是由加州大學(xué)伯克利分校Eric Brewer教授提出來(lái)的，他指出WEB服務(wù)無(wú)法同時(shí)滿(mǎn)足一下3個(gè)屬性：
- 一致性(Consistency) ： 客戶(hù)端知道一系列的操作都會(huì)同時(shí)發(fā)生(生效)
- 可用性(Availability) ： 每個(gè)操作都必須以可預(yù)期的響應(yīng)結(jié)束
- 分區(qū)容錯(cuò)性(Partition tolerance) ： 即使出現(xiàn)單個(gè)組件無(wú)法可用,操作依然可以完成
具體地講在分布式系統(tǒng)中，在任何數(shù)據(jù)庫(kù)設(shè)計(jì)中，一個(gè)Web應(yīng)用至多只能同時(shí)支持上面的兩個(gè)屬性。顯然，任何橫向擴(kuò)展策略都要依賴(lài)于數(shù)據(jù)分區(qū)。因此，設(shè)計(jì)人員必須在一致性與可用性之間做出選擇。
BASE理論
在分布式系統(tǒng)中，我們往往追求的是可用性，它的重要程序比一致性要高，那么如何實(shí)現(xiàn)高可用性呢？ 前人已經(jīng)給我們提出來(lái)了另外一個(gè)理論，就是BASE理論，它是用來(lái)對(duì)CAP定理進(jìn)行進(jìn)一步擴(kuò)充的。BASE理論指的是：
- Basically Available（基本可用）
- Soft state（軟狀態(tài)）
- Eventually consistent（最終一致性）
BASE理論是對(duì)CAP中的一致性和可用性進(jìn)行一個(gè)權(quán)衡的結(jié)果，理論的核心思想就是：我們無(wú)法做到強(qiáng)一致，但每個(gè)應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹?lái)使系統(tǒng)達(dá)到最終一致性（Eventual consistency）。
分布式事務(wù)TCC
TCC 其實(shí)就是采用的補(bǔ)償機(jī)制，其核心思想是：針對(duì)每個(gè)操作，都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)和補(bǔ)償（撤銷(xiāo)）操作。它分為三個(gè)階段：
- Try 階段主要是對(duì)業(yè)務(wù)系統(tǒng)做檢測(cè)及資源預(yù)留
- Confirm 階段主要是對(duì)業(yè)務(wù)系統(tǒng)做確認(rèn)提交，Try階段執(zhí)行成功并開(kāi)始執(zhí)行 Confirm階段時(shí)，默認(rèn) Confirm階段是不會(huì)出錯(cuò)的。即：只要Try成功，Confirm一定成功。
- Cancel 階段主要是在業(yè)務(wù)執(zhí)行錯(cuò)誤，需要回滾的狀態(tài)下執(zhí)行的業(yè)務(wù)取消，預(yù)留資源釋放。
舉個(gè)例子，假入 Bob 要向 Smith 轉(zhuǎn)賬，思路大概是：
我們有一個(gè)本地方法，里面依次調(diào)用
1、首先在 Try 階段，要先調(diào)用遠(yuǎn)程接口把 Smith 和 Bob 的錢(qián)給凍結(jié)起來(lái)。
2、在 Confirm 階段，執(zhí)行遠(yuǎn)程調(diào)用的轉(zhuǎn)賬的操作，轉(zhuǎn)賬成功進(jìn)行解凍。
3、如果第2步執(zhí)行成功，那么轉(zhuǎn)賬成功，如果第二步執(zhí)行失敗，則調(diào)用遠(yuǎn)程凍結(jié)接口對(duì)應(yīng)的解凍方法 (Cancel)。
Try部分完成業(yè)務(wù)的準(zhǔn)備工作，confirm部分完成業(yè)務(wù)的提交，cancel部分完成事務(wù)的回滾。基本原理如下圖所示。
事務(wù)開(kāi)始時(shí)，業(yè)務(wù)應(yīng)用會(huì)向事務(wù)協(xié)調(diào)器注冊(cè)啟動(dòng)事務(wù)。之后業(yè)務(wù)應(yīng)用會(huì)調(diào)用所有服務(wù)的try接口，完成一階段準(zhǔn)備。之后事務(wù)協(xié)調(diào)器會(huì)根據(jù)try接口返回情況，決定調(diào)用confirm接口或者cancel接口。如果接口調(diào)用失敗，會(huì)進(jìn)行重試。
TCC方案讓?xiě)?yīng)用自己定義數(shù)據(jù)庫(kù)操作的粒度，使得降低鎖沖突、提高吞吐量成為可能。 當(dāng)然TCC方案也有不足之處，集中表現(xiàn)在以下兩個(gè)方面：
對(duì)應(yīng)用的侵入性強(qiáng)。業(yè)務(wù)邏輯的每個(gè)分支都需要實(shí)現(xiàn)try、confirm、cancel三個(gè)操作，應(yīng)用侵入性較強(qiáng)，改造成本高。
實(shí)現(xiàn)難度較大。需要按照網(wǎng)絡(luò)狀態(tài)、系統(tǒng)故障等不同的失敗原因?qū)崿F(xiàn)不同的回滾策略。為了滿(mǎn)足一致性的要求，confirm和cancel接口必須實(shí)現(xiàn)冪等。
免費(fèi)開(kāi)源tcc-transaction
github上有個(gè)Java實(shí)現(xiàn)的tcc解決方案的中間件，源碼如下：
gihub倉(cāng)庫(kù)鏈接： https://github.com/changmingxie/tcc-transaction
