面試被問分布式事務（2PC、3PC、TCC），這樣解釋沒毛?。?/h1>

作者：程序員內點事 2020-05-06 10:19:14

后端
分布式 還記得剛入行開始寫Java時，接觸的第一個項目是國家電網的一個業(yè)務系統(tǒng)，這個系統(tǒng)據(jù)說投資了5億人民幣進行研發(fā)，鼎盛時期研發(fā)人員一度達到過500人。

成都創(chuàng)新互聯(lián)是一家集網站建設,互助企業(yè)網站建設,互助品牌網站建設,網站定制,互助網站建設報價,網絡營銷,網絡優(yōu)化,互助網站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網站。

絮絮叨叨

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

然而戲劇性的是，交測當天五人同時上線，項目崩 崩 崩潰了。。。哎!你永遠想象不到甲方憤怒的樣子，項目組每個人的祖宗都被問候到了。

說了一些沒用的，腦子里總想起這個事，不說不痛快，大家姑且就當笑話聽吧，下邊我們進入正題

背景

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

什么是分布式事務?

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

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

此時所有操作都在一個事務里，要么全部提交，要么全部回滾 。

圖糙理不糙

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

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

圖糙理不糙

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

一個事務有四個基本特性，也就是我們常說的(ACID)。

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

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

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

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

上面這些知識點都是反反復復念叨的概念，面試必背的東西。

分布式事務解決方案

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

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

1、兩段提交(2PC)

兩段提交顧名思義就是要進行兩個階段的提交：第一階段，準備階段(投票階段) ;第二階段，提交階段(執(zhí)行階段)。

上邊圖片源自網絡，如有侵權聯(lián)系刪除

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

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

一個下單請求過來通過協(xié)調者，給每一個參與者發(fā)送Prepare消息，執(zhí)行本地數(shù)據(jù)腳本但不提交事務。

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

兩段提交(2PC)的缺點

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

• 網絡抖動導致的數(shù)據(jù)不一致： 第二階段中協(xié)調者向參與者發(fā)送commit命令之后，一旦此時發(fā)生網絡抖動，導致一部分參與者接收到了commit請求并執(zhí)行，可其他未接到commit請求的參與者無法執(zhí)行事務提交。進而導致整個分布式系統(tǒng)出現(xiàn)了數(shù)據(jù)不一致。
• 超時導致的同步阻塞問題： 2PC中的所有的參與者節(jié)點都為事務阻塞型，當某一個參與者節(jié)點出現(xiàn)通信超時，其余參與者都會被動阻塞占用資源不能釋放。
• 單點故障的風險： 由于嚴重的依賴協(xié)調者，一旦協(xié)調者發(fā)生故障，而此時參與者還都處于鎖定資源的狀態(tài)，無法完成事務commit操作。雖然協(xié)調者出現(xiàn)故障后，會重新選舉一個協(xié)調者，可無法解決因前一個協(xié)調者宕機導致的參與者處于阻塞狀態(tài)的問題。

2、三段提交(3PC)

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

上邊圖片源自網絡，如有侵權聯(lián)系刪除

3PC 的三個階段分別是CanCommit、PreCommit、DoCommit

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

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

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

3、補償事務(TCC)

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

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

TCC它的核心思想是："針對每個操作都要注冊一個與其對應的確認(Try)和補償(Cancel)"。

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

Try階段：

下單時通過Try操作去扣除庫存預留資源。

Confirm階段：

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

Cancel階段：

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

上邊圖片源自網絡，如有侵權聯(lián)系刪除

TCC的缺點：

• 應用侵入性強：TCC由于基于在業(yè)務層面，至使每個操作都需要有 try、confirm、cancel三個接口。
• 開發(fā)難度大：代碼開發(fā)量很大，要保證數(shù)據(jù)一致性 confirm 和 cancel 接口還必須實現(xiàn)冪等性。

總結

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

分享標題：面試被問分布式事務（2PC、3PC、TCC），這樣解釋沒毛?。?
鏈接地址：http://www.5511xx.com/article/cojsjhp.html