還記得剛?cè)胄虚_始寫Java時(shí)，接觸的第一個(gè)項(xiàng)目是國家電網(wǎng)的一個(gè)業(yè)務(wù)系統(tǒng)，這個(gè)系統(tǒng)據(jù)說投資了5億人民幣進(jìn)行研發(fā)，鼎盛時(shí)期研發(fā)人員一度達(dá)到過500人。項(xiàng)目采用當(dāng)時(shí)最流行的ssh（Struts+Spring+Hibernate）框架，典型的三層架構(gòu)（controller - > service -> dao）簡單又粗暴，所有人寫的代碼都放在一個(gè)大工程里，項(xiàng)目文件大小達(dá)到幾百M(fèi)，解決代碼沖突是當(dāng)時(shí)最大的工作量。

然而戲劇性的是，交測當(dāng)天五人同時(shí)上線，項(xiàng)目崩 崩 崩潰了。。。哎！你永遠(yuǎn)想象不到甲方憤怒的樣子，項(xiàng)目組每個(gè)人的祖宗都被問候到了。

背景

前兩天有個(gè)學(xué)弟公眾號留言，說讓講講分布式事務(wù)，面試就掛在這個(gè)問題上。時(shí)下隨著微服務(wù)架構(gòu)體系的流行，面試的題目也都慢慢開始升級，不再是早些年單純的問點(diǎn)SSH框架知識、數(shù)據(jù)結(jié)構(gòu)了。高并發(fā)、高可用、分布式服務(wù)治理、分布式文件系統(tǒng)、分布式xxx，反正和分布式沾邊的都會問點(diǎn)， 項(xiàng)目實(shí)際用不用不要緊，關(guān)鍵你得了解，是不是總有一種學(xué)不動了的感覺？

什么是分布式事務(wù)？

我們看看百度上對于分布式事務(wù)的定義：分布式事務(wù)是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點(diǎn)之上。

額~ 看了反而更懵逼了，簡單的畫個(gè)圖好讓大家理解一下，拿下單減庫存來說舉例：當(dāng)系統(tǒng)的業(yè)務(wù)量很小時(shí)，“一站式”的系統(tǒng)完全可以滿足現(xiàn)有業(yè)務(wù)需求，所有的業(yè)務(wù)都共用一個(gè)數(shù)據(jù)庫，整個(gè)下單流程或許只用在一個(gè)方法里同一個(gè)事務(wù)下操作數(shù)據(jù)庫即可。

此時(shí)所有操作都在一個(gè)事務(wù)里，要么全部提交，要么全部回滾 。

但隨著業(yè)務(wù)量不斷增長，“一站式”系統(tǒng)漸漸扛不住巨大的流量，就需要對數(shù)據(jù)庫進(jìn)行分庫分表，將業(yè)務(wù)服務(wù)化拆分（SOA），就會分離出了訂單中心、用戶中心、庫存中心。而這樣就造成業(yè)務(wù)間相互隔離，每個(gè)業(yè)務(wù)都維護(hù)著自己的數(shù)據(jù)庫，數(shù)據(jù)的交換只能進(jìn)行RPC調(diào)用。

用戶再下單時(shí)，創(chuàng)建訂單和扣減庫存，需要同時(shí)對訂單DB和庫存DB進(jìn)行操作。兩步操作必須同時(shí)成功，否則就會造成業(yè)務(wù)混亂，可此時(shí)我們只能保證自己服務(wù)的數(shù)據(jù)一致性，無法保證調(diào)用其他服務(wù)的操作是否成功，所以為了保證整個(gè)下單流程的數(shù)據(jù)一致性，就需要分布式事務(wù)介入。

圖糙理不糙

在說分布式事務(wù)之前，先回憶一下事務(wù)的基本概念：事務(wù)是一個(gè)程序執(zhí)行單元，里面的所有操作要么全部執(zhí)行成功，要么全部執(zhí)行失敗。

一個(gè)事務(wù)有四個(gè)基本特性，也就是我們常說的（ACID）。

Atomicity（原子性） ：事務(wù)是一個(gè)不可分割的整體，事務(wù)內(nèi)所有操作要么全做成功，要么全失敗。

Consistency（一致性） ：務(wù)執(zhí)行前后，數(shù)據(jù)從一個(gè)狀態(tài)到另一個(gè)狀態(tài)必須是一致的（A向B轉(zhuǎn)賬，不能出現(xiàn)A扣了錢，B卻沒收到）。

Isolation（隔離性）：多個(gè)并發(fā)事務(wù)之間相互隔離，不能互相干擾。

Durablity（持久性） ：事務(wù)完成后，對數(shù)據(jù)庫的更改是永久保存的，不能回滾。

上面這些知識點(diǎn)都是反反復(fù)復(fù)念叨的概念，面試必背的東西。

分布式事務(wù)解決方案

有困難就一定會有解決問題的辦法，什么都難不倒聰明的程序員。

XA協(xié)議是一個(gè)基于數(shù)據(jù)庫的分布式事務(wù)協(xié)議，其分為兩部分：事務(wù)管理器和本地資源管理器。事務(wù)管理器作為一個(gè)全局的調(diào)度者，負(fù)責(zé)對各個(gè)本地資源管理器統(tǒng)一號令提交或者回滾。二階提交協(xié)議（2PC）和三階提交協(xié)議（3PC）就是根據(jù)此協(xié)議衍生出來而來。如今Oracle、Mysql等數(shù)據(jù)庫均已實(shí)現(xiàn)了XA接口。

1、兩段提交（2PC）

兩段提交顧名思義就是要進(jìn)行兩個(gè)階段的提交：第一階段，準(zhǔn)備階段(投票階段) ；第二階段，提交階段（執(zhí)行階段）。

上邊圖片源自網(wǎng)絡(luò)，如有侵權(quán)聯(lián)系刪除

下面還拿下單扣庫存舉例子，簡單描述一下兩段提交（2PC）的原理：

之前說過業(yè)務(wù)服務(wù)化（SOA）以后，一個(gè)下單流程就會用到多個(gè)服務(wù)，各個(gè)服務(wù)都無法保證調(diào)用的其他服務(wù)的成功與否，這個(gè)時(shí)候就需要一個(gè)全局的角色（協(xié)調(diào)者）對各個(gè)服務(wù)（參與者）進(jìn)行協(xié)調(diào)。

如果協(xié)調(diào)者收到了參與者的失敗消息或者超時(shí)，直接給每個(gè)參與者發(fā)送回滾(Rollback)消息；否則，發(fā)送提交(Commit)消息；參與者根據(jù)協(xié)調(diào)者的指令執(zhí)行提交或者回滾操作，釋放所有事務(wù)處理過程中被占用的資源，顯然2PC做到了所有操作要么全部成功、要么全部失敗。

兩段提交（2PC）的缺點(diǎn)

二階段提交看似能夠提供原子性的操作，但它存在著嚴(yán)重的缺陷

• 網(wǎng)絡(luò)抖動導(dǎo)致的數(shù)據(jù)不一致： 第二階段中協(xié)調(diào)者向參與者發(fā)送commit命令之后，一旦此時(shí)發(fā)生網(wǎng)絡(luò)抖動，導(dǎo)致一部分參與者接收到了commit請求并執(zhí)行，可其他未接到commit請求的參與者無法執(zhí)行事務(wù)提交。進(jìn)而導(dǎo)致整個(gè)分布式系統(tǒng)出現(xiàn)了數(shù)據(jù)不一致。

• 超時(shí)導(dǎo)致的同步阻塞問題： 2PC中的所有的參與者節(jié)點(diǎn)都為事務(wù)阻塞型，當(dāng)某一個(gè)參與者節(jié)點(diǎn)出現(xiàn)通信超時(shí)，其余參與者都會被動阻塞占用資源不能釋放。

• 單點(diǎn)故障的風(fēng)險(xiǎn)： 由于嚴(yán)重的依賴協(xié)調(diào)者，一旦協(xié)調(diào)者發(fā)生故障，而此時(shí)參與者還都處于鎖定資源的狀態(tài)，無法完成事務(wù)commit操作。雖然協(xié)調(diào)者出現(xiàn)故障后，會重新選舉一個(gè)協(xié)調(diào)者，可無法解決因前一個(gè)協(xié)調(diào)者宕機(jī)導(dǎo)致的參與者處于阻塞狀態(tài)的問題。

2、三段提交（3PC）

三段提交（3PC）是對兩段提交（2PC）的一種升級優(yōu)化，3PC在2PC的第一階段和第二階段中插入一個(gè)準(zhǔn)備階段。保證了在最后提交階段之前，各參與者節(jié)點(diǎn)的狀態(tài)都一致。同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制，當(dāng)參與者各種原因未收到協(xié)調(diào)者的commit請求后，會對本地事務(wù)進(jìn)行commit，不會一直阻塞等待，解決了2PC的單點(diǎn)故障問題，但3PC 還是沒能從根本上解決數(shù)據(jù)一致性的問題。

上邊圖片源自網(wǎng)絡(luò)，如有侵權(quán)聯(lián)系刪除

3PC 的三個(gè)階段分別是CanCommit、PreCommit、DoCommit

CanCommit：協(xié)調(diào)者向所有參與者發(fā)送CanCommit命令，詢問是否可以執(zhí)行事務(wù)提交操作。如果全部響應(yīng)YES則進(jìn)入下一個(gè)階段。

PreCommit：協(xié)調(diào)者向所有參與者發(fā)送PreCommit命令，詢問是否可以進(jìn)行事務(wù)的預(yù)提交操作，參與者接收到PreCommit請求后，如參與者成功的執(zhí)行了事務(wù)操作，則返回Yes響應(yīng)，進(jìn)入最終commit階段。一旦參與者中有向協(xié)調(diào)者發(fā)送了No響應(yīng)，或因網(wǎng)絡(luò)造成超時(shí)，協(xié)調(diào)者沒有接到參與者的響應(yīng)，協(xié)調(diào)者向所有參與者發(fā)送abort請求，參與者接受abort命令執(zhí)行事務(wù)的中斷。

DoCommit：在前兩個(gè)階段中所有參與者的響應(yīng)反饋均是YES后，協(xié)調(diào)者向參與者發(fā)送DoCommit命令正式提交事務(wù)，如協(xié)調(diào)者沒有接收到參與者發(fā)送的ACK響應(yīng)，會向所有參與者發(fā)送abort請求命令，執(zhí)行事務(wù)的中斷。

3、補(bǔ)償事務(wù)（TCC）

很多初學(xué)者總是被TCC、2PC、3PC這幾個(gè)概念搞混淆，傻傻分不清，實(shí)際上 TCC與 2PC、3PC一樣，都只是實(shí)現(xiàn)分布式事務(wù)的一種方案而已。

TCC（Try-Confirm-Cancel）又被稱補(bǔ)償事務(wù)，TCC與2PC的思想很相似，事務(wù)處理流程也很相似，但2PC 是應(yīng)用于在DB層面，TCC則可以理解為在應(yīng)用層面的2PC，是需要我們編寫業(yè)務(wù)邏輯來實(shí)現(xiàn)。

TCC它的核心思想是："針對每個(gè)操作都要注冊一個(gè)與其對應(yīng)的確認(rèn)（Try）和補(bǔ)償（Cancel）"。

還拿下單扣庫存解釋下它的三個(gè)操作：

Try階段：

下單時(shí)通過Try操作去扣除庫存預(yù)留資源。

Confirm階段：

確認(rèn)執(zhí)行業(yè)務(wù)操作，在只預(yù)留的資源基礎(chǔ)上，發(fā)起購買請求。

Cancel階段：

只要涉及到的相關(guān)業(yè)務(wù)中，有一個(gè)業(yè)務(wù)方預(yù)留資源未成功，則取消所有業(yè)務(wù)資源的預(yù)留請求。

TCC的缺點(diǎn)：

• 應(yīng)用侵入性強(qiáng)：TCC由于基于在業(yè)務(wù)層面，至使每個(gè)操作都需要有 try、confirm、cancel三個(gè)接口。

• 開發(fā)難度大：代碼開發(fā)量很大，要保證數(shù)據(jù)一致性 confirm 和 cancel 接口還必須實(shí)現(xiàn)冪等性。

總結(jié)

很淺顯的介紹了一下2PC、3PC、TCC的概念，如有錯(cuò)誤還望溫柔指正，分布式事務(wù)一直都是面試中比較熱點(diǎn)的問題，也是進(jìn)階高級Java工程師必備的知識點(diǎn)。

長按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠摯感謝